Недавно по необходимости пришлось столкнуться с такой системой управления сайта, как DynamiX. Движок идентифицирован в файлах следующим образом:

define( "CMS_NAME", "DynamixCMS" ); define( "CMS_VERS", "3.0.4" );.

Соответственно рассматриваться будет версия 3.0.4 , выпущенная еще в 2008 году. Как ни странно, сайт разработчиков движка недоступен, вернее он весит в стадии "реконструкции", причем судя по всему довольно длительное время. Тем не менее, вещь сама по себе интересная, а потому начнем. Первое, что бросается в глаза  при анализе движка, так это то, что его код был подвергнут обфускации.

Иными словами все вразумительное имена и переменные были заменены на неприглядные длинные имена, состоящие из букв и цифр. Ну что-ж, уже интересно - похоже что разработчики все-таки очень дорожат своим кодом, и сделали все возможное, чтобы постигать этот код было максимально сложно. Организация базы данных тоже не вызвала вдохновения - все текстовые поля спрятаны под blob-ы, и чтобы увидеть сам по себе текст - приходится делать конвертации в читаемый вид. Вместе с тем, нельзя не заметить тот факт, что вцелом движок проработан хорошо, и логично - так что любой разработчик аналогичных систем вряд ли  испытает сложности с разбором логики работы. Все просто. Есть общий индексный файл, который в зависимости от передаваемых на сайт ссылок формирует обращения к соответствующим скриптам сайта, которые и выполняют определенные логикой действия. Разумеется в этом движке есть выделенный шаблон, отличный от основных действий и отвечающий исключительно за отображение контента. Отдельно следует отметить, что движок работает довольно шустро. Но, как ни странно есть и откровенно странные вещи, возможно связаные с тем, что рассматриваемый мной движок уже был подвержен изменениям со стороны третьих лиц - все дело в том что в скриптах-обработчиках AJAX событий присутствует элемент отдельного от движка подключения к базе данных, причем передаваемые параметры не сильно проверяются на соответствие, и как есть вливаются в SQL запросы, что ставит под серьезный риск работу сайта, поскольку методом SQL-injection все содержимое сайта может быть попросту снесено одним махом. Но останавливаться на этом не будем, что есть то есть - и уже заштопано мной. Остановимся немного на самой методике формирования страниц сайта. Она, конечно не нова - но может быть кому-то будет интересна. Итак, когда посетитель переходит на какую-либо страницу по ссылке вида *.html он на самом деле перенаправляется на обработку индексным файлом index.php  в корне сайта, который и отвечает за то, что собственно говоря отображать. Ну что  ж, с точки зрения SEO это более чем оправданно и типично. Далее, по своей встроенной таблице соответствий ссылок и действий, которые необходимо совершить производится запуск обработчика в каталоге /page, но... только в том случае, если ссылке не сопоставлен какой-либо материал в базе данных. Если в базе данных в таблице smk_page сопоставлен материал, то дальнейшая обработка не выполняется, а выводится сама по себе страница. Вернее таким образом формируется контент сайта, а обрамление полностью соответствует /root/default.php - там же в /root лежат и все служебные элементы шаблона.  Интересно то, что страницы контента в базе данных представлены в трех ипостасях: на русском, английском языке и транслитерации - что не было задействовано на сайте. Для формирование контента на сайте так же используются перенаправления ввода-вывода скрипта и использование "служебных" символов в теле контента. Например {menu:stat}{menu:main} -полностью соответствуют своим названиям - сюда попадает код меню. Интересным является использование содержимого базы данных в качестве переменного контента. Так, например логика проверки почты, доступа и отображение календаря организовано через таблицу smk_arrs - где в виде параметр-значение оная и хранится.

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