rPman

после 5.6 версии php можно использовать variadic functions

function test(...$params){var_dump($params);}
test(1,2,3);

работает для всех мест использования - функций, методов, замыканий.

Код ужасен, не разбираюсь в нем да и не охота.
Вы фактически загружаете все данные в php память, но не одним запросом а огромным количеством (на каждого человека по несколько да?) что абсурдно.

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

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

Необходимо в документ добавить макросы, которые будут запрашивать необходимую информацию и обновлять документ.

Если надо для каждого файла какие то условия проверять и glob с масками * и ? не подходит то используйте pathinfo, разбирает путь в виде строки и возвращает полезную информацию:
print_r(pathinfo('/path/file.ext.jpg'));

Array
(
    [dirname] => /path
    [basename] => file.ext.jpg
    [extension] => jpg
    [filename] => file.ext
)

С точки зрения нейминга пакетов в OS, php бывает php-cli и просто php. Первый - для запуска из коммандной строки или службы, т.е. просто как скриптовый язык (кстати жутко удобный, имхо удобнее bash, и самый быстрый из существующих в принципе, рядом с ним идет node js но он не такой удобный), второй - для работы web бакэнда.

По факту это один и тот же бинарник но когда запускаешь приложение из командной строки, настройки php.ini берутся из другого каталога (смотреть /etc/php/...).

Можно внутри php файла не указывать <?php но в начале указать по стандарту #!/usr/bin/php и тогда скрипт будет запускаться как любое другое приложение (нужен флаг x на файле) либо использовать <?php и запускать
php файл.php
Второй вариант мне нравится больше, потому что редакторы ide для php чаще ожидают второй вариант а при первом не включают подсветку синтаксиса.

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

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

В терминах базы данных это называется sequence, в каких то это специальный объект с этим именем, значение которого можно запросить и получить следующее, в каких то используется стратегия autoincrement, когда это значение вычисляется автоматически при добавлении в таблицу (например primary key) в каких то, а значит следующее значение можно получить только добавив запись, ну а в совсем уж слабых, пользователи заводят специальную таблицу, где одна запись - сиквенс, значение которого можно прочитать и увеличить на нужное число простым update (и использовать блокировки).

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

При попытке реализовать подобное на базе файлов возникнет необходимость реализовывать контроль за подобными коллизиями уже самому.

p.s. Внимательно подумайте, вам нужен счетчик или нужно уникальное значение? Можно чтобы каждое следующее значение было ровно на единицы больше? может быть оно меньше предыдущего?

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

Самый простой алгоритм - который по правде говоря не дает гарантий, но значительно понижает вероятность коллизий - взять текущее время, в милли-/микро-/пико-секундах, при наличии кучи машин - добавить номер этой машины, можно добавить еще случайное число (чем больше его разрядность тем ниже вероятность коллизий)
sprintf("%u",microtime(true)*1000000);
еще есть метод uniqid, он делает примерно то же самое но возвращает hex строку.

p.s. время на машинах должно быть синхронизировано с точным, чтобы не было такого что в какой то момент оно откатится назад на достаточное значение чтобы метод дал сбой

Хотя бы для отладки вывел что возвращает тебе ftp_mlsd, 100% все проблемы бы решились сразу.

Пальцем в небо - в linux каждый каталог содержит два элемента '.' и '..', соответственно текущий и предыдущий каталог, вдруг ftp их возвращает а ты их в файлы записываешь? но тип по уму у них должен быть dir, плюс зациклилось бы все.

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

Фатальные ошибки возникают, когда допущена ошибка в коде, например синтаксическая, или необработанные исключения, или неожиданная комбинация данных... в общем произошло то, чего не ждёшь.

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

Наиболее легко получает народ ошибки такого рода, когда заканчивается место на диске или ram.

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

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

Очень сложный вопрос м в конце концов упирается в объем ресурсов, которые вы готовы в это вложить.

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

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

Так же возможно сочетание обоих подходов, для оптимизации ресурсов.

для этого из $code удаляю по 1 символу

так заведи еще одну переменную для этого и скопируй туда $code

https://habr.com/ru/post/132554/

не надо в value ничего умножать

несколько input на странице с name="sub_section[]" автоматически будут проанализированы веб сервером и превращены в массив из их value

p.s. объясните, почему вы в 2021 году используете веб стандарт, который на клиенте работает без javascript? я конечно могу придумать пару применений такому но что то мне подсказывает что это не ваш случай.

пользуйтесь XMLHttpRequest, он давно уже стандартизирован во всех браузерах, сериализуйте красиво в javascript свои данные и не заморачивайтесь