FanatPHP

Да, можно.

Про текстовый файл - это сказки.

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

Второе. Текстовый формат.
Разумеется, у многих файловых форматов имеется возможность сохранять мета-информацию. Это картинки, офисные файлы, пдф и так далее.
У текстовых файлов в общепринятом понимании хранить мета-информацию просто негде. Так что о текстовых файлах речь не может идти.

Если де речь о других форматах, то надо просто читать спецификацию на конкретный формат и смотреть какие там есть поля для мета-данных.

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

Если не хочется передавать текущую дату в запрос, то в mysql есть функция NOW().

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

По поводу того, что сюда добавить:

В ужасе стереть все что что тут написано.
Прочитать раз в жизни документацию и забыть про mysql_real_escape_string как про страшный сон.
Включить голову, и сообразить, что mysql не подвержена XSS. То есть при записи в базу данных от этой атаки защищаться не нужно.
Освоить PDO, и использовать подготовленные выражения для работы с базой данных.

Потому что если атрибут action у формы пустой, то используется текущий урл.

Избавляться от гет параметров в данном случае не нужно.
От чего нужно избавиться - это от чудовищного учебника (или, скорее, видеокурса, поскольку снежинки же у нас умеют только в видео), в котором написана вся эта чудовищная муть.

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

<?php
session_start();
$_SESSION['counter'] = $_SESSION['counter'] ?? 0;
echo "Вы обновили эту страницу ".$_SESSION['counter']++." раз. ";
echo '<br><a href="">обновить</a>';

Все прекрасно обновляется с первого раза

gulp не имеет отношения к PHP.
РНР исполняется на сервере
никакой "оптимизации скорости загрузки" сборка РНР в единый файл не даст.
php include надо оставить в покое

Учимся искать ошибки в своем коде самостоятельно

Чтобы исправить ошибку синтаксиса, надо научиться считать и выучить синтаксис РНР.

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

Используй базу данных.

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

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

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

SELECT user, sum(km) FROM results WHERE date BETWEEN начало AND конец GROUP BY user

Вместо начало и конец подставить нужные даты - хоть неделя, хоть месяц, хоть год.

Разница небольшая на самом деле, главное не использовать mod_php

Так никто никогда не делает. Данные передавать не надо, они и так есть на сервере.

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

Все очень плохо.

Самое главное - черный список никогда не является надёжной защитой. Защищает только белый список.

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

Во-первых, зачем вообще запрещать "прямой вызов"?
Это какие-то страхи из 90-х.

Во-вторых, если уж этот мусор в файле имеется, то почему в коде не определена константа TEST?

Что будет быстрее обрабатываться,

Одинаково
К "серверной оптимизации" такая ерунда не имеет ни малейшего отношения.

что правильнее

Зависит от конкретной задачи

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