FanatPHP

Нет, неправильно.

- get_functions.php ужасное название, винегрет внутри. все эти функции разложить по своим модулям.
- inc/main_tpl.php подключается слишком рано. сначала надо закончить работу с данными, а только потом начинать вывод. Это азбука.
- 'modules/' . $_GET['section'] . '/index.php' инклюдится слишком поздно. модуль надо инклюдить ДО начала вывода. При этом основной шаблон должен вызываться не в индексе, а в модуле. модуль решает, бует ли он что-то выводить, если да - то присваивает переменной имя своего шаблона и вызывает основной шаблон, который в себе инклюдит шаблон модуля. Подробнее: phpfaq.ru/tech/tpl
- в include 'modules/' . $_GET['section'] . '/index.php' тебе напихают такого, что на ежика станешь похож. имя модуля надо обязательно валидировать. в идеале по белому списку.

В остальном нормально, только обычно все кроме индекса кладут выше корня.

Очень смешное предложение про md5 и длину.
Направление в принципе верное, но вот что делать с полученным результатом - вот тут мысль наших добестных похапешников останавливается.

А теперь внимание - правильный ответ
urlencode() - самая удобная отладчная функция. Читаемые символыв она оставит как есть, а непечатные - закодирует в удобный формат.

Мужчина в соседнем ответе не совсем в теме.

Хотя, конечно, вопрос и сам по себе дурацкий.
Phpmailer - это не почтовый сервер. Это всего лишь mail()-переросток. Доставкой писем не знаимается. И "поставить через композер" проблему доставки писем не решит - все равно нужен будет сервер.
То есть выбор не между "phpmaier" vs transactional email service, а "мой аккаунт на гмейле" vs mailgun.

И тут уже надо думать - какой исходящий емейл мы хотим использовать, как гмейл будет правляться с нашими объемами, как быть с попаданием в спамоловки и пр. И нормальное "стороннее АПИ" (чтобы это выражение не значило) окажется в разы предпочтительнее

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

Я так понимаю, о технических комментариях АКА phpdoc (о которых говорит тов. куратор) речь сейчас не идет. Если идет, то автор приглашается объяснить, чем они его не устраивают.

Если же автор говорит о пояснениях к коду, то позиция совершенно правильная, такой подход называется самодокументируемый код, впервые упомянутый великим Фредериком Бруксом еще в 60-х годах прошлого века.

Очень хороший вопрос и тема, в которой самое чудовищное количество самых дремучих северий на единицу кода.

В общем случае, по умолчанию, никаких проверок и траев с кетчами быть не должно.

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

Пример: В обоих приведенных выше случаях мы имеем масло масляное: попытка подменить пхп в выборосе ошибки. Вопрос - зачем? Если файл не найден, то РНР сам прекрасно сообщит нам об ошибке, причем в подробностях, и скажет в чем конкретно заключается проблема. А по строчке "file not found" иди гадай - путь ли кривой или в имени файла опечатка, или вообще пустоту передали.

Любые проверки надо делать только тогда, когда есть осмысленный сценарий их обработки.

И обсуждать выше приведенные примеры имеет смысл только если автор вопроса предоставит такой сценарий. тупое error: file not found таким сценарием не является. Так что в общем случае оставляем код в покое и не устраиваем никакого карго культа из перехвата ошибок.

Если чисто выбирать между двумя действиями (проверка и чтение) и одним (сразу читаем, потом ловим исключение),

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

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

Сессию надо закрывать в долгих скриптах.

$last = pathinfo ('web.pages.page', PATHINFO_EXTENSION);