D3lphi

Потому что куки устанавливаются по средствам отправки заголовков ответа. Заголовки отправляются перед тем, как вы выводить что-то (через echo, например). $_COOKIE же в свою очередь заполняется при получении заголовков запроса. То есть, до начала выполнения кода. Таким образом, получается, что этот массив во время выполнения скрипта первый раз пуст.

Получается такая схема:

Первое выполнение скрипта:
1) Приходят заголовки запроса (Куки отсутствуют)
2) куки отсутствуют -> массив $_COOKIE пуст
3) Устанавливаем куки (массив $_COOKIE все еще пуст)
4) Отправляем заголовки ответа (массив $_COOKIE пуст), устанавливаем куки на клиенте

Второе выполнение скрипта:
1) Приходят заголовки запроса -> в них уже есть куки.
2) $_COOKIE теперь содержат то, что мы установили во время выполнения предыдущего скрипта.
...

Само SPA приложение делится на 2 основные части:

1. Frontend - верстка, логика на vuejs, роутинг (vue-router).
   
2. Backend - по сути, API к которому Frontend делает асинхронные запросы, получает данные и меняет представление соответствующим образом.
   

Эти 2 составляющие пишутся отдельно (От слова "вообще").

Например, так:

class Test
{
    private $tableName;

    public function __construct($tableName)
    {
        $this->tableName = $tableName;
    }

    public static function table($tableName)
    {
        return new self($tableName);
    }

    public function delete()
    {
        // do something
    }
}

Она идёт с phpstorm по-умолчанию. Зажмите ctrl и щёлкните ЛКМ по названию(вызову) встроенной функции/метода/класса и тд. В phpstorm откроется документация об этом элементе.

echo strlen('example'); // Щелкаем ЛКМ с зажатым ctrl по strlen и попадаем на страницу с информацией о данной функции.

Поэкспериментируйте с этими значениями, чтобы вам было удобно.

Очевидно, что вы используете новую версию PHP, в которой удалено устаревшее расширение mysql_*.

Да, по реализации все верно вы себе представляете.

Как все это смотрится с AR?

Откровенно скажу, с AR это смотрится хреново. В том смысле, что вы не используете основные "преимущества" (Да, да, в кавычках, потому что эти самые преимущества облегчают и ускоряют разработку, но никак не способствуют улучшению качества кода и его поддержке) этого паттерна.

В каждом из таких репозиторий будут повторяющиеся методы: all, find и прочие. Как быть в таком случае? Как вынести подобные методы в общий класс?

Создать базовый интерфейс для всех репозиториев и в нем описать эти методы, затем расширить интерфейс каждого конкретного репозитория. Можете плюсом ко всему написать абстрактный класс репозиторий и в нем написать универсальную реализацию этих самых общих методов (Для каждого типа репозиториев, разумеется). Но лично я бы так делать не стал.

Правильно ли я размышляю вообще?

Да, по реализации все верно вы себе представляете.

Здесь плохо всё, к сожалению.

Начнем с того, что вы неверно наследуете классы. Почему у вас класс, отвечающий за подключение к базе данных является родителем класса, работающим с заказами? Наследование применяется, если можно сказать, что что-то является чем-то. Например, разработчик является работником; компьютер является устройством и тд. Здесь же у вас вообще близко такой логике не получится следовать. Вы должны передавать хотя бы объект для работы с бд через инъекцию, например, в конструктор. В идеале, нужно использовать паттерн репозиторий для работы с базой данных.

Класс SearchOrder у вас не только выполняет запросы, но еще и работает с данными, хранит состояние этих самых данных, фильтрует данные (strip_tags()). Непорядок. Это все нужно разделять. У вас вообще получаются какие-то богообъекты, которые умеют во все.

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

$result = $wrapper->select("SELECT * FROM `tablename` WHERE `id` = :id", ['id' => 5]);

?

Вы вызываете connect() в методах. То есть, каждый вызов этого метода будет приводить к установке нового соединения с базой данных, даже если оно уже было установлено. Соединение с базой данных это достаточно дорогостоящая операция.

Зачем вы используете свойства, если можно обойтись обычными локальными переменными:

$this->orderID = (int) strip_tags($orderID);
$this->column = (string) strip_tags($column);
$this->value = (string) strip_tags($value);

?

Почему вы стриппите тэги у идентификатора? вы настолько не уверены в том, что влетает в функцию:
strip_tags($orderID);
?

Если вы не используете php 7 и, как следствие, скалярный тайпхинтинг, то должны делать проверки на тип входящего аргумента. Если что-то не так с типом, бросаем исключение (А не приводим его к нужному)! Например:

if (!is_string($arg)) {
    throw new InvalidArgumentTypeException('string', $arg);
}

Это в идеале. Вы не обязаны это делать, конечно же. Но вот такие проверки делают приложение безопаснее. Хотя, опять же, повторюсь, в 2017 нужно начинать новые проекты на php 7.1+.

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

Кроме всего прочего, почитайте про стандарты оформления кода. Вы им не следуете.

Вам пока рано писать такие велосипеды. Судя по всему, у вас нет опыта вообще. Посмотрите готовые решения: фреймворки, ORM, изучите их, хотя бы поверхностно разберитесь, как оно работает и уже потом пробуйте что-то сделать, исходя из полученных знаний.

Желаю успехов!

Стесняюсь спросить, json_decode() вас чем не устраивает?
У меня на ПК обработка json-файла размером в 130 мб занимает чуть больше секунды.

$auto = Auto::create([
    // ...
    'key1' => 'val1',
    'key2' => 'val2',
    // ...
]);

User::create([
    // ...
    'auto_id' => $auto->id, // Ох уж это магия... Создайте лучше геттер.
    // ...
]);

Или

$id= Auto::insertGetId([
    // ...
    'key1' => 'val1',
    'key2' => 'val2',
    // ...
]);

User::insert([
    // ...
    'auto_id' => $id,
    // ...
]);

Можно связать "модели" отношениями и делать так:
$user->auto()->attach($auto);

Если я вас правильно понял:

$flag = true;
foreach($items as $item) {
    if ($item <= $val) { // $val - число, больше которого должны быть элементы массива.
        $flag = false;
        break;
    }
}

if ($flag) {
    // Делаем что-то
}

$str = '23 сентября';
$result = preg_replace('/([0-9]+)/', '<strong>$1</strong>', $str);

Не понятно, в какой именно тэг вам нужно обернуть число, поэтому, для пример, я использовал strong.