CMS

В паре заметок (Why Blog With Joomla? и Why Blog With Joomla? Part 2) на JoomlaBlogger джумлоаддикт Kristoffer Sandven пытается всех убедить, что блог на Джумле — хороший выбор. Надо признать — получается не очень, потому что в основном он апеллирует к тому, что «не надо учить еще одну CMS, ведь эту уже используете» и «на ней можно же собрать нечто, похожее на блог».

Решив быть последовательным и не ограничиваться поверхностными наблюдениями фасада, поставил на тест (для начала) MaxSite CMS. «Убийца Wordpress», говорите?! Мне почему-то всегда казалось, что killer-app должен, по сравнению с «жертвой» предлагать всё то же (ну или большую часть), плюс еще что-то очень правильное сверху, чтобы выбор был прост и однозначен «Менять, прямо сейчас, немедленно!».

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

Быстро сделать блог на CMS общего назначения, которой является Xaraya - оказывается очень просто.

Рецепт практически без изменений должен (технически) работать и на Aruba, и на Jamaica, и на Xarigami, с небольшими уточнениями:

• Проверку на Jamaica на демосайте до конца доводить поленился - слишком много разных 404 ошибок в процессе выбрасывало ядро (и это несмотря на то, что версия вроде как по цифрам давно не альфа и не бета, 2.1.0)
• Xarigami-версии некоторых использованных модулей - "улучшенные и дополненные" по сравнению с исходными, так что там может получиться самый интересный вариант

Для решения, кроме минимального Core, будут нужны:

1. Articles,
2. Categories,
3. Keywords,
4. Comments,
5. Tinymce

Устанавливаем эти модули, настраиваем по обычному минимуму. У Articles убираем все типы публикаций, кроме News, в Categories создаем иерархию категорий для будущих блоговых записей. В настройках сайта разрешаем для редактирования использование TinyMCE.

Следующий шаг - сборка хуками всего набора в единое целое: к Articles прихучиваем Comments (ведь наши записи мы хотим дать возможность комментировать), Categories (чтобы как в "больших" блогах первым слоем шло деление по категориям) и Keywords (блог без тэгов - недоблог). Настраиваем порядок использования хуков (от этого зависит, как будет выглядеть наша итоговая форма редактирования, порядок объектов в ней)

Проверив права и убедившись, что необходимый минимум раздали (читать статьи и писать комментарии) - радуемся готовому блогу

Причин на то несколько, и вот это - демонстрация только одной из них, попавшимся под руку примером

How exactly do we re-order the tabs on user profiles?
...
To reorder all of them, you'll need a custom module to implement hook_menu_alter()

(выделение мое), и так - практически на каждом шагу, когда для обыденных повседневных задач (порядок табов поменять в профиле - разве не такая?) дается вовсе не обыденное решение

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

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

Похоже, что LifeType больше позиционируется как платформа для блогоферм (много много- или одноюзерских блогов в разных вариантах настройки на нем делаются достаточно просто и естественно - на одной инсталляции), где нужны не только блоги, но и сторонний контент, типа линкосвалок, альбомов и легкий поиск с агрегацией, а требования к блоггингу обычно-средние, чем как инструмент для привередливого блоггеромана

В Cети отмечается всплеск взломов сайтов, построенных на Wordpress. Разработчикам пока не удалось выяснить причину взлома, так как взлому подверглись не только устаревшие версии, но и сайты на базе последней версии Wordpress. С другой стороны число пораженных сайтов не так велико, чтобы можно было утверждать о наличии в коде неизвестной неисправленной уязвимости.

Официальный сайт мэрии Лондона и Лондонской ассамблеи переселился на Друпал, о чем 13 февраля городское управление рассказало в своем блоге. По словам из анонса, Drupal обеспечивает более низкую стоимость разработки в сравнении с проприетарными системами.

Немного раньше такую же миграцию прошел сайт Белого Дома

Cтало известно, что сайт Белого дома США перешел на использование популярной CMS Drupal.
В качестве одной из главных причин перехода на Drupal в Белом доме указывают на желание представить на сайте больше возможностей для совместной работы и интерактивности. Для этого в Drupal представлены такие функции, как регистрация пользователей, блоги, комментарии, опросы. Впрочем, подобные возможности легко найти и во многих других CMS-системах (в том числе — и с открытым кодом), поэтому выбор именно Drupal в качестве используемого решения не совсем ясен, но тенденция - радует

Разработчики Drupal, открытой системы управления контентом, выпустили версии своего продукта 5.20 и 6.14, устраняющие четыре выявленные уязвимости. Одна из этих уязвимостей заключалась в возможности подделки кросс-сайтового запроса, что позволяло нападающим при определенных условиях добавить свой собственный OpenID к существующей учетной записи Drupal и получить к ней доступ. Другая ошибка в реализации OpenID позволяла пользователю обращаться к учетной записи другого пользователя, если оба были подключены к одному провайдеру OpenID-2.0.

Ошибка в API Apache позволяла передать на сервер исполняемые файлы – в том случае, если сервер был сконфигурирован на игнорирование настроек в файле .htaccess в каталоге загрузки. Обновление также устраняет ошибку, позволявшую атакующему перехватить пользовательскую сессию.

Разработчики оценивают выявленные уязвимости как критические, и рекомендуют пользователям Drupal незамедлительно провести обновление, предварительно ознакомившись с рекомендациями по его проведению.

Как оказалось, последние обновления WordPress были небесполезны ("Fortunately, because of the hard work of the Wordpress open source community, the current (2.8.4) and most recent (2.8.3) versions are immune..."), ну а всем живущим на более старых версиях предстоит геморройное занятие: проверять, не заразил ли их червяк, чиститься, если не повезло, и всем - обновляться, теперь для этого есть вполне серьезная причина: червяк для (относительно) стареньких инсталляций WP не слухи, а вполне суровая реальность, о которой написал Matt Mullenweg в блоге WordPress.

Уже четвертое (за непродолжительный период) обновление 2.8 релиза WordPress - 2.8.4. На этот раз, говорят о закрытии вполне конкретной уязвимости, а не об абстрактных "безопасности плагинов" и "возможной XSS-атаке в комментариях"

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

Удаленный доступ к WordPress таким образом получить нельзя, но и в регулярном сбросе пароля админа приятного нет