Михаил Ливач

Выставить настройки кэша в заголовках ответа, отдающего файл.
Для особо упертых браузеров, которые могут класть на эти заголовки (вроде Хрома) - отдавать файл каждый раз по другой ссылке (добавив ?ver=mtime, например).

через настройки никак, только ручками программировать

По-битриксовски - положить его в sect_inc.php в той папке, которая объединяет эти 8 страниц.

Можно использовать xargs, он сам поделит список аргументов, переданных через stdin, на такие блоки, чтобы они вписывались в лимит. Чтобы не было спецэффектов от всяких особых символов, можно использовать find -print0 | xargs -0 (символ с кодом 0 будет разделять имена файлов вместо стандартного переноса строки):

find условия -print0|xargs -0 rm -rf

Однако GNU find сам умеет удалять файлы с помощью -delete:

find условия -delete

Ещё может быть проблема, что подобная операция помешает работе сайтов из-за нагрузки на диск, это можно решить с помощью приоритетов для процессов (nice) и ввода-вывода (ionice), тогда удаление будет по возможности выполняться в фоне:

nice -n19 ionice -c3 команда

(Если используется find|xargs, то это нужно передать xargs)

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

В качестве БД для логов лучше всего использовать Click House - базу от Яндекс. Она отлично для этих целей подходит и невероятно хорошо сжимает данные, т.е. помимо всего прочего, еще и на диске эти данные будут не много места занимать. Также вы можете с Click House настроить полтики хранения данных, например указать что данные в таблице лога должны храниться 5 лет, и CH будет сам их чистить.

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

См. также паттерн Transactional Outbox

HTTP Error 413 - Content Too Large

Это не у гита косяк, а у вашего вебсервера у которого лимит на размер заливаемых файлов.
Настройте параметр client_max_body_size в nginx, или LimitRequestBody если у вас apache.
(не забудьте перезапустить вебсервер или перечитать конфиг на горячую).

Либо переключите git с https на SSH, тогда вебсервер не повлияет.

Обычно UNION автоматически делает distinct для всех таблиц-участников процесса union.
Это является причиной замедления.

Используй UNION ALL.

В приципе с Apache не обязятельно, но я бы заменил его на связку nginx + php-fpm и PHPMyAdmin удалил от греха подальше

Цель - это то что ты сам, как оператор ПД, задекларировал в своём соглашении на обработку ПД.
Это то, зачем тебе вообще эти ПД нужны.

Например тебе нужны ПД клиента чтобы оказать ему какую-то услугу и больше ничего ты не написал (например банки пишут, что они продолжат хранить ПД ещё 15 лет после расторжения договора)
Как только услуга эта оказана - тебе следует удалить данные.

Вероятно open_basedir

PXE загрузка сервера
https://habr.com/ru/articles/136921/
например тут почитайте

По сути три больших направления с кучей мелких ответвлений
1. хранить текстовый лог в отдельном файле/сервисе/логохранилище
2. хранить лог действий юзеров в отдельной таблице (встречал один проект, где лог действий был в десятки раз больше, чем сами данные, ага).
3. хранить в той-же таблице предыдущие записи. То есть при редактировании INSERT, а не UPDATE, при этом автоматически проставляется время и автор, а при выборке просто берете последнюю по времени версию.

Это самый удобный путь, и самый простой для внедрения - очень простой откат, удобное сравнение изменений. Из минусов - раздуваете таблицу с данными, но это не проблема если записей не много или изменения редки.

Особняком стоит упомянуть системы с возможностью одновременного редактирования несколькики пользователями, которые автоматически разруливают коллизии. Самый знакомый всем пример - google docs. Но это довольно сложно в реализации.

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

Вы так интересно читаете список ошибок - выборочно.
Ведь выше есть другие. И если вы их исправите, например, перенесете счетчик в body, то всё с вашими мета будет в порядке.

Теги div и img нельзя вставлять в head.

Как вариант - handlingUnits[PackageType][].
Тогда индексы в PHP проставятся автоматически.