Алексей Блышко

Нет, нету. Придется писать что-то свое.

В качестве примера могу предложить посмотреть на функцию array_values_recursive из комментариев к документации php.net/manual/ru/function.array-values.php

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

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

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

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

Вопрос задан неправильно. Правильно бы вопрос звучал "как собрать статистику запросов к страницам и функциям, чтобы определить, что надо кэшировать".

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

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

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

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

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

Но есть и другие варианты. Вот небольшой чеклист:
- Не знаю особенности жумлы, но хочу уточнить - переменные $mail и $mailer в хелпере откуда берутся?
- В лог ошибок что-нибудь пишется?
- Включен ли вывод ошибок? E_ALL?