Adamos

Google Sitemap Generator - работает который год именно по этой схеме.
Только не забудьте при настройке исключить все непубличные разделы из списка и убедиться, что никакие важные данные не передаются GET-аргументами (и, соответственно, не появятся в sitemap).

А что, еще есть CMS на PHP (кроме Битрикса), не отрапортовавшие о готовности свежей версии работать на РНР7?

А что вы "пробовали перекодировать"?
Проблема только в том, что zip хранит имена файлов в однобайтовой кодировке, и на русских виндах это cp1251.
Содержимое файлов архивируется совершенно одинаково.
Так что достаточно не называть архивируемые файлы кириллицей.

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

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

Если у вас тяжелые внешние ссылки, сделайте ленивую загрузку. Хотя бы элементарно - выводите страницу со всей версткой, но без конкретики, а в конце пишите javascript, который назначает конкретным картинкам конкретные src. Это несложно, правда. Впрочем, если для этого познакомиться хотя бы и с общеизвестным JQuery, все станет еще проще...

Вам нужна та карта сайта, которая для пользователей - или sitemap.xml, которая для поисковиков?
Первая должна бы строиться самой CMS, если у нее внутри не бардак.
Вторая делается элементарно скриптом Google Sitemap Gen по логам сервера.

Архитектура измеряется не длиной функций, а их назначением. Функция, выполняющая ровно одну задачу, обычно и не будет длинной.
Подойдите к вопросу со стороны тестирования. Вас устроит тест этой функции как единого черного ящика? Или у нее есть конкретные части, которые выполняют полноценные подзадачи, под которые хорошо бы иметь отдельный тест на случай, если в функции будут изменения? Если нет и у вас просто однородная простыня - разбивать незачем. Если есть - почему нет?
Ну, а если вас смущает накопление никому больше не нужных функций - вспомните, что в РНР есть ООП и все это может быть собрано в класс, а нигде больше не используемые функции - сделаны приватными.

var t = new Date();
t.setTime(<?= strtotime('now') ?>);
write(t.toLocaleTimeString());

Вы не используете возврат ajax-запроса (в котором, собственно, тот самый pdf).
Собственно, для скачивания файла проще как раз сделать submit динамически заполненной формы - ajax здесь ни к чему.

Сделайте sitemap - автоматически, указав в настройках скрипта пропуск таких ключей.
И скормите его поисковикам.

Ну, и то, что ссылка на ту же самую страничку идет через get-параметр, а не через # - неаккуратненько...

Рекурсии сплошь и рядом можно развернуть в цикл.
Однако если она у вас уже через несколько тактов падает, вы, видимо, создаете в ней кучу новых объектов, которые ей приходится хранить до конца рекурсии?
Так с пыхом нельзя...

Завести применение нового шаблона на условие (какой-нибудь ключ в GET).
В Битриксе по умолчанию так сделан шаблон "для печати", например.
Отладить. Оттестировать.
Применить ко всему сайту.

Любая современная платежная система работает так:
- клиент на сайте хочет за что-то заплатить
- сайт формирует заказ под уникальным номером, сохраняя, кто, что и за какую сумму оплачивает
- клиент отправляется на сайт платежной системы с номером заказа и его ценой
- если клиент оплатил этот заказ, платежная система возвращает его на сайт, но это НЕВАЖНО
- потому что некоторые платежи могут час идти от клиента до платежной системы (хотя к PP это, может быть, и не относится)
- когда ПС удостоверится, что клиент оплатил заказ, она дергает скрипт на нашем сайте, сообщая ему, что заказ номер такой-то проплачен такой-то суммой. Тут может быть предварительное подтверждение, что этот заказ стоит именно столько - только при этом условии с клиента вообще что-либо снимется. Но в любом случае информацию о том, что заказ проплачен, на сайт приносит не браузер пользователя (это дырища), а сервер ПС
- когда клиент заходит после этого на сайт, сайт уже в курсе, что этот клиент проплатил этот заказ, и действует соответственно

Любые прочие "быстрые кнопки" или велосипеды - это несерьезно и, вполне возможно, уязвимо для халявщиков.

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

Я бы сделал кроме личных сообщений - оповещения (те, которые всем). Можно в той же таблице, просто с нулевым адресатом.
И к ним дополнительную таблицу - последний id оповещения, которое получил пользователь.
Все оповещения, которые еще им не были получены, выдаются ему при первом же входе, при этом в таблицу заносится id последнего выданного.
Хотя им неплохо бы и срок жизни иметь - через год-два смысла в них точно не будет...

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

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

Пароль БД не защищают от администратора сервера, его защищают от пользователей веб-сервера. Для этого шифрование не требуется.

1. Сделайте отчет не в PhpExcel, а просто в HTML.
2. Если и он делается долго - проверяйте логику, вставляя сверку microtime.
3. Когда добъетесь быстрого вывода отчета, сохраните этот HTML в файл с расширением XLS и не связывайтесь со всякими убогими форматами.

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