Сколько на эту тему переломано копий... Попробую и я внести свой вклад в это темное дело.

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

Например, некоторые CMS (система управления содержимым - сайтом) позволяют встраивать «в себя» форум. Форум это довольно сложная штука, поэтому неизбежно возникают проблемы от такой интеграции, начиная от оптимизации базы данных, авторизации пользователей, и заканчивая «подгонкой» шаблона. Поэтому иногда проще поставить форум совершенно отдельно и адаптировать шаблон сайта на него. Ну да ладно. /-Главное, что должна делать CMS - это быть расширяемой.-/ То есть CMS должна иметь такие функции, которые позволяют «на лету» подключать другие. И желательно, что бы само подключение было «одним кликом», без «хаков» и правки в файлах самой CMS.

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

Третье требование - это /-функциональность в построении шаблона-/. В подавляющем большинстве случаев разработчики CMS предусматривают специальные команды (псевдотеги, функции), которые дизайнер должен разместить в своем шаблоне. Получается, что шаблон ограничен ровно на столько, на сколько разработчики заранее предусмотрели команд CMS. Чтобы добавить свою функцию, придется добавлять ее вначале в CMS, а уже после подключать к своему шаблону. Это неудобно, поэтому идеальный вариант, это когда CMS совершенно не ограничивает дизайнера в функциональности шаблона. Самое разумное решение - это предоставить в его распоряжение всю мощь PHP.

Замечу, что «движки» различаются двумя способами обработки шаблонов. В первом случае, CMS парсит (обрабатывает) текст шаблона и встретив псевдо-тег, обрабатывает его определенным образом. Во-втором способе «движок» просто подключает шаблон как PHP-скрипт. В этом случае дизайнер должен использовать синтаксис PHP.

Вот собственно эти три требования, на которых может базироваться «идеальная» CMS: функциональная расширяемость, любая структура шаблона, функциональность равная PHP (или тому языку, на котором написана сама CMS).

Функциональная расширяемость

Рассмотрим ее на примере движка WordPress. Предположим вы написали свою функцию на PHP. Для того, чтобы подключить ее к «движку» нужно всего лишь поместить файл (файлы) в специальный каталог (plugins) и в админин-панели активировать его. С этого момента ваша функция будет доступна из/для любого шаблона.

Необходимо сказать, что разработчики WP пошли еще дальше и предложили механизм с помощью которого дизайнер имеет возможность управлять не только своими функциями, но и любыми другими. Предположим, вы хотите заменить стандартную действие на свое (например, при публикации нового сообщения). В этом случае вы можете указать удаляемую. Делается это очень просто, например: remove_filter('the_content', 'wptexturize') - в этом случае будет «удалена» функция «wptexturize», которая обрабатывает вывод блока «the_content». Вместо нее подключаете свою, например: add_filter('the_content', 'my_wptexturize').

Как видите, все просто и элегантно.

Любая структура шаблона

Бич многих CMS. Проблема заключается в том, что любая страничка состоит как минимум из заголовка (head), содержимого (content) и подвала (footer). При этом нужно еще разместить логотип, название сайта, меню, а также другие элементы дизайна. Конечно же все эти части нужно разместить в разных файлах, и тогда дизайнер смог бы манипулировать ими по своему усмотрению. Но с другой стороны, то что подходит для одного шаблона, может не подойти к другому и структура, например расположение не горизонтального, а вертикального меню, будет другая.

Большая ошибка разработчиков CMS заключается в том, что они встраивают структуру шаблона в свой «движок». В идеале же CMS должна «знать» лишь один конфигурационный файл из которого она сможет получить всю информацию о шаблоне. В итоге мы получаем абсолютно любую структуру шаблона.

Правда здесь возможны нюансы. Разные дизайнеры будут по разному компоновать страницы и использовать для этого разные файлы. Но есть некие части страницы, которые должны присутствовать всегда. В WP эту поблему решили просто: существуют несколько зарезервированных файлов, которые должны содержать структурные части страниц. Главным файлом шаблона является index.php. В нем дизайнер может подключить любые другие части страницы. Разработчики предусмотрели функции вызова зарезервированных файлов. Например, для того чтобы вывести меню можно просто указать функцию get_sidebar - в этом случае WP подключит файл sidebar.php. При этом никто не мешает дизайнеру подключить этот файл PHP-функцией require.

То есть все решается в зависимости от того, как дизайнер решит «собирать» страницу: либо через встроенные стандартные функции (в этом случае имена файлов предопределены), либо непосредственно через PHP (в этом случае никаких ограничений практически нет).

Именно «практически». Дело в том, что WordPress использует разные файлы шаблона в зависимости от действий пользователя. Вывод главной страницы - index.php; вывод просматриваемго сообщения (post) - single.php; вывод статичной страницы (page static) - page.php.

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

функциональность равная PHP

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

Ложка дегтя

Принципы заложенные в WP верные, но на данный момент несколько хромает функциональность и проявляются ошибки планирования структуры страниц.

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

Возможно, что WP изначально ориентировался только как «движок» блога (дневника), и лишь в последствии разработчики решили сделать из него нечто большее. Но вместо выпуска новой версии с новой структурой, видимо из соображений совместимости, оставили существующую структуру.

Например, зачем использовать два вида сообщений «post» и «static»? Здравый смысл подсказывает, что любое сообщение может быть каким-либо типом. Но почему в «post» можно указывать рубрику, а в «static» нет? На мой взгляд здесь разработчики несколько перемудрили, поскольку теперь используется две независимых иерархии страничек: для «post» нужно заранее предусмотреть категории (разделы), а для «static» нужно указывать другой «родительский» «static».

Самое интересное, что и «post», и «static» хранятся в одной таблице базы данных и по сути никакого различия между ним нет. Возможно, что разработчики лишь хотели разделить сообщения, которые либо будут помещаться в ленту новостей, либо нет. Но, что тогда мешало добавить дополнительную опцию «Не отображать в ленте новостей»?

В общем каждое сообщение (страница) WordPress'а может иметь статус:

• publish (опубликованно как «post»)
• draft (черновик)
• private (приват)
• static (постоянная страница «page»)
• object

При этом можно указать:

• post_parent (родительскую страницу)
• menu_order (порядковый номер в меню)
• post_category (категория)

Но разработчики ввели ограничения, которые не позволяют воспользоваться этими возможностями в полной мере. :(

Отдельно хотелось бы сказать про администрирование. Понятно, что для администрирования особых красот не требуется, но не до такой же степени? Двухуровневое меню это конечно же оригинально, но малофункционально. На мой взгляд проще было бы сделать в виде выпадающего списка или даже как фреймовую структуру как, например это реализованно в форуме Invision Board.

Внедрение в WordPress версий 1.6 и старше встроенного визуального редактора оказалось настолько неудачным, что пользоваться им нет никакого желания. Поэтому вместо него лучше использовать оффлайн-клиент (блог-клиент), например Semagic, Zempt или WP-CLIENT.

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