marsdenden

Хотелось бы дать решение если кому интересно.
Если мы хотим в Php эмулировать консоль со всеми ее ответами в Php, стоит использовать такую конструкцию.

$cmd = 'enconv /var/www/documents/xxx/\(1\)-1402322554-file -x utf8 -L russian';
$process = proc_open($cmd,
        array(0 => array('pipe', 'r'), 1 => array('pipe', 'w'), 2 => array('pipe', 'w')), $pipes, NULL, NULL)) {
            echo "<b>$cmd</b><br/>";
            echo "OUTPUT:".stream_get_contents($pipes[1])."<br/>";
            echo "ERRORS:".stream_get_contents($pipes[2])."<br/>";
            echo "<br/>";
        }

Так мы получаем всю информацию которую нам возвращает консоль. Все ошибки возвращаются так же. Очень удобно когда пишется программа которая использует внешние вызовы программ в коде.

В рамках одной БД все CONSTRAINT'ы должны иметь уникальные имена. Возможно проблема в этом.
Другой вариант -- несовпадение доменов (типа и ограничений) поля внешнего ключа с полем, на которое он ссылается.
Третий вариант -- ссылочные поля должны быть потенциальными ключами.
Четвертый вариант -- родительских таблиц не существует.
Пятый -- подсистема хранения родительских таблиц MyISAM.

В yii\rest\IndexAction есть метод 'prepareDataProvider'. Если его переопределить, можно использовать get параметры в запросе для совершения выборки. Например так:

public function actions()
    {
        return [
            'index' => [
                'class' => IndexAction::className(),
                'modelClass' => $this->modelClass,
                'checkAccess' => [$this, 'checkAccess'],
                'prepareDataProvider' => function ($action) {
                    $model = new Product();
                    $model->load(\Yii::$app->request->queryParams)
                    return $model->search();
                }
            ],
        ];
    }

model->search должен возвращать ActiveDataProvider на основе переданных параметров из запроса.

В случае не связанных иерархически (не имеющих общего родителя, например), можно использовать:
1) Общий стор (vuex)
2) Event Bus

В случа однофайловых компонентов event bus это просто js-файл с содержимым:

import Vue from 'vue';
export const EventBus = new Vue();

Например есть два компонента: карточка товара (где-то в середине страницы) и корзина (где-то в шапке):

1) В обоих компонентах импортируем bus
import { EventBus } from './event-bus.js';
2) В компоненте карточки в вызове метода, например, addToCart:

methods: {
	addToCart: function() {
    	EventBus.$emit('add-to-cart', 1);
	}
}

3) В корзине:

EventBus.$on("add-to-cart", count => {
	console.log(`Cart updated on ${count} items.`)
})

Как сделать так, чтобы эти компоненты появлялись только после взаимодействия с ними пользователя на прошлом шаге? (т.е 2 появляется после того как пользователь выбрал значение на первом и тд..)

В случае приведенной вами иерархии:

<App>
	<StepOne></StepOne>
	<StepTwo v-if="isListItemSelected"></StepTwo>
	<StepThree v-if="isRangeShowing"></StepThree>
</App>

Можно вынести в data компонента App параметры isListItemSelected (значение выбрано из списка), isRangeShowing (показан ползунок) со значениями false по умолчанию (по поводу StepOne - непонятно из вопроса показан ли он изначально).

В компоненте StepOne, как только пользователь выберет значение, можно делать $emit (без event-bus, потому что есть отношения родитель-потомок), в App ловить событие через $on и менять значение, в случае StepOne - isListItemSelected = true. То же самое и с остальными.

Если надо что-то менять при перемещении ползунков - то когда из компонента с ними делаете $emit и меняете какие-то значения в родительском App - их можно спускать через props в следующий компонент:

<StepThree v-if="isRangeShowing" :range="rangeValues"></StepThree>

и не забыть указать в StepThree параметр props: ['range'].

Насколько я понимаю, OPTIONS запросы Yii , вообще, должен разруливать самостоятельно.

если вы сами это не настроите, оно не будет ничего разруливать.

Нужно чтобы любой опшнс запрос уходил на роут одного и того же контроллера который 1) не требует авторизации 2) возвращает все нужные заголовки. Настроить это универсально с помощью роутинга yii2 мне так и не удалось, пришлось хардкодить разные уровни роутов и переадресовывать их на единый метод.

Как линукс переносит такую операцию?

Отлично переносит. Если не перепутать диск с системным

Puppeteer

var array = JSON.parse('[{"name":"user_ce820531","lvl":1,"time":"1:54"},{"name":"user_ce820531","lvl":1,"time":"1:07"}]');

Ну как-то так

let routeData = this.$router.resolve({name: 'routeName', query: {data: "someData"}});
window.open(routeData.href, '_blank');

Хотя в версии 3 уже работает и так

<router-link :to="{ name: 'routeName'}" target="_blank">
Текст
</router-link>

Во-первых: начните изучать архитектурную часть программирования, изучите паттерны проектирования, изучите SOLID, DRY, KISS и остальные модные словечки, постарайтесь всё это осознать, или, на крайняк - зазубрить. Всё придет с опытом, изначально все не понимали зачем всё так сложно, но эта сложность обусловлена неисчислимыми литрами слёз и потраченных нервов, всё не просто так.

Судя по всему это тестовое или учебное задание. От вас требовалось отоверинжинирить простую задачу. Давайте попробуем:

Суть задачи - есть файл с определенной структурой хранения данных, структура строковая. Требуется этот файл преобразовать в другую структуру данных и вывести эту структуру в json формате. Задача ясна.

Разобъем задачу на отдельные независимые этапы:
1) Преобразование одной структуры данных (текстового файла) в другую (объект, понятный PHP, к примеру)
2) Преобразование этой структуры данных в Json формат.
Первый вопрос, который может возникнуть - почему сразу не преобразовать в json? Ответ - при расширении системы в будущем - нам понадобится вывести данные в виде массива, или в виде XML, или даже в виде готового файла Excel. Нам будет сложно дополнять логику изначального класса, ничего при этом не сломав и не затронув уже существующий функционал. Также ответом на этот вопрос может являться каждая буква из SOLID принципов, подробнее отвечу дальше, когда буду пояснять за реализацию, см. ниже

Теперь рассмотрим эту задачу с точки зрения ООП, начнем думать не от конкретной реализации, а от интерфейса и абстракции (мы не парсим конкретный файл, мы парсим просто файл, мы не переводим его в конкретное представление json, мы переводим его просто в представление):
Нам понадобится 2 класса - непосредственно класс, читающий файл и преобразующий его в простейший тип данных (например PHP array). Второй класс - преобразователь простейшего типа данных парсера в какой-то определенный тип:

1. LogFileReaded implements/extends FileReaderContract(интерфейс, возможно абстрактный класс, если понадобится предустановленная логика)
   
   Непосредственно наш преобразователь (не забываем, что передавать путь к файлу и все настройки нужно из вне, к примеру, в конструктор. Нельзя, как вы - хардкодить всё внутрь файла, на крайний случай - можно использовать конфигурацию), на ввод получает файл определенного типа с определенной известной структурой, на выходе выдает информацию из файла, преобразованную в базовый тип (массив, в нашем случае). Если нам когда-то понадобится парсить другой тип данных или структура данных будет изменена - мы сможем написать отдельный класс для этой логики, а не рушить целостность уже работающего кода, добавляя туда новую логику. Запомните - нужно стремиться не менять, а дополнять.
   
   
2. JsonPresenter implements/extends DataTypePresenterContract
   
   Абстракция содержит контракт на метод output(), а в конструкторе принимются исходные данные. В конкретной реализации JsonPresenter в output() будет банальный json_encode() (да, это нормально, нет, класс не лишний и нет, json_encode() нельзя пихать в сам парсер) А теперь к вопросу - почему не следует просто запихать это всё в парсер и вместо массива отдать json: в будущем, когда система будет расширяться - нам понадобится представить данные в виде XML - что тогда будем делать - переписывать весь код парсера ради добавления switch case "json" и т.д.? А если что-то сломается во всей системе? А если вариантов представления станет настолько много, что файл будет просто не читаем? А при данном подходе достаточно будет просто написать новый класс XMLPresenter, или даже ExcelPresenter, который на выводе не строку будет выдавать, а целый файл (опустим типизацию output пока)). Также этот класс можно реализовать в виде декоратора (паттерн), да и много еще как.
   
   

В итоге у нас получается вполне сносная и, что важнее - расширяемая(в разумных пределах) архитектура, не забываем прописать класс клиента и определить конкретные реализации в одном месте - можно упороться и дописать сюда контейнер зависимостей.

К примеру: в итоге, если вас уже повысили, и вы вместо парсинга стали заниматься более высшими материями - новому программисту, чтобы дописать логику преобразования данных в Excel не нужно знать как конкретно вы преобразовывали когда-то эти данные в json, ему не нужно дебажить ваш код, ему достаточно посмотреть на интерфейс - отнаследоваться от него и написать свой собственный метод преобразования и дальше использовать его в нужном месте.

P.S. В данной реализации опускаются и упрощаются некоторые моменты для понятности

:class="{ ['cls_'+ i1]: i2 > 2 }"

Рекомендую ознакомиться.

Берем портянку if-else

if (date.getDay() == 1) {
	period = `${date.toLocaleDateString()} - {date.setHours(168).toLocaleDateString()}`; 
} else if (date.getDay() == 2) {
	period[i] = `${date.setHours(-24).toLocaleDateString()} - {date.setHours(144).toLocaleDateString()}`;
} else if (date.getDay() == 3) {
	period[i] = `${date.setHours(-48).toLocaleDateString()} - {date.setHours(120).toLocaleDateString()}`;
} else if (date.getDay() == 4) {
	period[i] = `${date.setHours(-48).toLocaleDateString()} - {date.setHours(120).toLocaleDateString()}`;
} else if (date.getDay() == 5) {
	period[i] = `${date.setHours(-72).toLocaleDateString()} - {date.setHours(96).toLocaleDateString()}`;
} else if (date.getDay() == 6) {
	period[i] = `${date.setHours(-96).toLocaleDateString()} - {date.setHours(72).toLocaleDateString()}`;
} else (date.getDay() == 0) {
	period[i] = `${date.setHours(-120).toLocaleDateString()} - {date.setHours(48).toLocaleDateString()}`; 
}

и переписываем

let arr = [[-120,48], [null,168], [-24,144], [-48,120], [-48,120], [-72,96], [-96,72]];
let day = date.getDay();
let dateString1 = arr[day][0] === null ? date.toLocaleDateString() : date.setHours(arr[day][0]).toLocaleDateString();
let dateString2 = arr[day][1] === null ? date.toLocaleDateString() : date.setHours(arr[day][1]).toLocaleDateString();
period[i] = `${dateString1} - ${dateString2}`;

Плюс, если уж вы используете es6 синтаксис (классы у вас там, шаблонные строки), то объявляйте переменные через const/let, а не var