Adamos

Проверьте значение $perpage_ajax. Там, похоже, 0, и цикл становится бесконечным.
Кстати, знание математики хотя бы в рамках начальной школы позволяет переписать этот кусок так, чтобы цикла не было вообще. Заодно и ошибка division by zero будет куда информативнее ;)

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

Вставьте в начало скрипта
echo getcwd() . "\n";

А что вам мешает в CLI обратиться к пыху 7.1 полной командой?
Очевидно, просто PHP вызывает /usr/bin/php, настройки update-alternatives игнорируются.

Например, делать это не на РНР, а на JS (подменяя адрес в браузере, но не переходя реально по ссылкам).

Короче нужно чтобы функция proc_open работала

Бесплатному хостеру вообще не впилось давать халявщикам такие возможности.

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

С помощью переменной, например:
www.mysql.ru/docs/man/Variables.html
Создаете нулевую и присваиваете инкрементированную в запросе с сортировкой.

Вот тоже думаю - не начать ли изучать MVC-модель.
А то пару сайтов на OctoberCMS написал, а MVC-модель все никак не сяду изучать...

Там над "фигней типа" случаем не висит заголовок с указанным Content-Transfer-Encoding?
https://www.php.net/manual/ru/function.base64-deco... попробуйте.

Если это происходит в рамках одного сайта, то вам это не нужно.
А нужно собрать функционал, выполняющийся в том и другом скрипте, в соответствующие классы, и вызывать их методы там, где они понадобились.

Весь вопрос вокруг банальной и обычной для новичков ошибки.
Я считал что-то из базы, обработал и хочу записать.
Что будет, если между этими событиями база изменится?
Правильный ответ: база не должна изменяться между этими событиями.
Либо блокировка записей, либо - и желательно - правильные запросы, которые делают получение данных и их изменение атомарным.

Таблица products (изделия):
id - title - article - прочие общие поля, которые будут у любого изделия

Таблица properties (типы свойств):
id - title - прочие поля, нужные для обработки (например, это может быть json-поле, в котором прописаны нюансы отображения. Поиска по нему все равно никогда не потребуется)

Таблица product_properties (свойства изделий):
id - product_id - property_id - property_value (строковое значение достаточной длины, чтобы его хватило на что угодно)

Если постоянно нужен поиск по значениям свойств и список возможных значений того или иного свойства - можно ввести еще таблицу property_values:
id - property_id - value c уникальным индексом по двум полям
и в таблице product_properties вместо property_id и property_value задавать property_value_id

Колхоз на коленке:
- таблица: id - слово (уникальный индекс)
- таблица: база товара (1 или 2), артикул (индекс), id слова в таблице слов.
Для каждого товара из каждой базы разбиваете название на слова, для каждого из них делаете запись в обеих таблицах. Получится несколько миллионов записей, это не так страшно и не так долго, если не косячить с запросами.
Потом по артикулам первой базы запрашиваете артикулы второй, у которых во второй таблице больше всего записей с id прописанных для первого артикула слов. Из десятка лидеров выбираете вручную сопоставление.

Регулярки пишутся не для "вообще", а для определенной цели. Например, проверки, что введенный адрес соответствует неким требованиям.
Кстати, проблемы корректности адреса никакими регулярками не покрываются.

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