Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 188
Для корпоративной визитки с новостями хорошо подходят простенькие узкофункцональные системы типа simpla.
Симпла — это отлично заточенная система под интернет-магазины. И стоит 400$.
Я в своё время провёл много тщательных поисков подходящей cms, и открыл для себя LabCMS.
Рекомендую, там и карта сайта генерируется, и система шаблонов удачная, в общем посмотрите.
Я в своё время провёл много тщательных поисков подходящей cms, и открыл для себя LabCMS.
Рекомендую, там и карта сайта генерируется, и система шаблонов удачная, в общем посмотрите.
Я как-то давно использовал Danneo CMS — достаточно простая и легковесная.
Я ещё есть новенькая Anchor CMS
А она что стала бесплатной?
Заголовок стоит изменить на «Сравнительный анализ CMS на PHP». Кроме PHP в мире есть еще множество других веб технологий и CMS на них соответственно тоже есть.
Использую ImageCMS, мне как не веб-разработчику эта cms показалась довольно простой и удобной, особенно в плане работы с шаблонами. Сейчас кстати основной вектор развития этой системы направлен на создание интернет магазинов.
Изучить за неделю семь CMS не самая простая задача. Если бы вы потратили на каждую (или бы на 3-4 из них) по неделе, было бы намного информативнее и полезнее.
Кроме того, довольно странно от CMS ждать все функций из коробки: модули сильно меняют картину.
Если вы хотите выбрать одну CMS для корпоративных сайтов, то нужны более точно выбранные критерии, нежели «создание страниц» и «добавление меню».
Кроме того, довольно странно от CMS ждать все функций из коробки: модули сильно меняют картину.
Если вы хотите выбрать одну CMS для корпоративных сайтов, то нужны более точно выбранные критерии, нежели «создание страниц» и «добавление меню».
Если возникают проблемы и/или сложности с CMS в начале создания сайта, а затем в процессе продвижения, тогда бизнес процессы могут приостанавливаться. А на исправление и совершенствование много времени тратится. 3-4 дня действительно, еще больше можно всего посмотреть и изучить логику данных CMS. Думал почитать 400 стр. Drupal Development John VanDyk, Matt Westgate. Тогда статья в 4 раза увеличиться, все-таки передумал.
Если это проблема именно CMS, то да. Но при беглом осмотре, можно максимум исключить несколько вариантов и более серьезно разобрать другие. А если дело в том, что взгляд был слишком поверхностный, то может быть обратная ситуация: легко исправляемые «недочеты» мы причисляем в, условно, минусы, а серьезных проблем обнаружить не успели.
Ниже, например, очень хорошо написали про Drupal, как видите недочетов в обзоре достаточно.
Ниже, например, очень хорошо написали про Drupal, как видите недочетов в обзоре достаточно.
ох и обзор…
это все равно что сделать обзор кукурузника и боинга, просто подергав разные ручки в течении часа
это все равно что сделать обзор кукурузника и боинга, просто подергав разные ручки в течении часа
Вывод о Typo3 надо дублировать и для Друпала. Читал и чуть ли не плакал, честное слово.
Друпал — это система для людей, которые готовы в нём поковыряться и, так сказать, «проникнуться» его логикой. После этого всё становится на порядок проще.
Друпал — это система для людей, которые готовы в нём поковыряться и, так сказать, «проникнуться» его логикой. После этого всё становится на порядок проще.
Если посчитать получится, нужно дополнительно установить более 10 модулей + для SEO 8. Все это влияет на загрузку сайта, чтобы улучшить время загрузки нужно установить еще дополнительный модуль. CMF подходит для крупных сайтов, и то ее нужно очень хорошо настроить, короче это очень большая «махина».
1) Вы не правы. Чтобы все было «пальчики оближешь» нужно поставить намного больше 10 модулей. :-) На скорость загрузки сайта влияют далеко не все — какая разница, какие у вас стоят административные модули, типа тех же WYSIWYG-редакторов? Их обычный пользователь не видит и они на скорость загрузки не влияют.
2) Вы не правы. Прелесть Друпала как раз в том, что для действительно маленьких сайтов ничего ставить не нужно: из коробки есть и система шаблонов, и меню, и лента новостей (которую вы почему-то не смогли настроить, хотя для этого достаточно добавить пару материалов типа «Заметка» или любых других, у которых в настройках типа материала указано «Выводить на главную». И все — на главной вы получаете новостную ленту.), и одна из главных радостей создателей микро-сайтов — мультисайтинг, когда одна инсталляция Друпала обслуживает сто-пицот отдельных сайтов…
3) То, что вы пишите на счет правки Друпаловских исходников — это ужасно. Любой друпальщик прочитав это — застрелится (потому их и так мало в комментах — остались только самые крепкие). Пожалуйста, никогда не изменяйте ничего в исходниках Друпала. Если вам нужно создать тему — сделайте подкаталог sites/all/themes, скопируйте туда хотя бы какую-то из комплектных и там меняйте как хотите. Если вас не устраивает форма контактов комплектного модуля Contact — поставьте Webform, но не лезьте в код самой CMS!
4) Ну и вообще — очень сказывается, что вы пытаетесь работать не почитав про тот же Друпал вообще ничего. Меню редактируются стандартным способом через соответствующий пункт в админке. Переводы обеспечиваются стандартными же модулями из комплекта — можно вообще ничего не ставить. Не знаю, куда вам потребовалось вставлять блок меню в виде кода, но готовые блоки стандартных меню тоже есть из коробки. Замена шаблона для материала определенного типа — это создание одного файла в папке темы. Да, в Друпале работа с темами/шаблонами — не визуальная. Есть различные способы сделать ее более визуальной, но это все костыли. Ну и вообще — если бы вы дошли до «визуального» создания тем в том же typo3 — вам бы Друпал раем показался. :-)
2) Вы не правы. Прелесть Друпала как раз в том, что для действительно маленьких сайтов ничего ставить не нужно: из коробки есть и система шаблонов, и меню, и лента новостей (которую вы почему-то не смогли настроить, хотя для этого достаточно добавить пару материалов типа «Заметка» или любых других, у которых в настройках типа материала указано «Выводить на главную». И все — на главной вы получаете новостную ленту.), и одна из главных радостей создателей микро-сайтов — мультисайтинг, когда одна инсталляция Друпала обслуживает сто-пицот отдельных сайтов…
3) То, что вы пишите на счет правки Друпаловских исходников — это ужасно. Любой друпальщик прочитав это — застрелится (потому их и так мало в комментах — остались только самые крепкие). Пожалуйста, никогда не изменяйте ничего в исходниках Друпала. Если вам нужно создать тему — сделайте подкаталог sites/all/themes, скопируйте туда хотя бы какую-то из комплектных и там меняйте как хотите. Если вас не устраивает форма контактов комплектного модуля Contact — поставьте Webform, но не лезьте в код самой CMS!
4) Ну и вообще — очень сказывается, что вы пытаетесь работать не почитав про тот же Друпал вообще ничего. Меню редактируются стандартным способом через соответствующий пункт в админке. Переводы обеспечиваются стандартными же модулями из комплекта — можно вообще ничего не ставить. Не знаю, куда вам потребовалось вставлять блок меню в виде кода, но готовые блоки стандартных меню тоже есть из коробки. Замена шаблона для материала определенного типа — это создание одного файла в папке темы. Да, в Друпале работа с темами/шаблонами — не визуальная. Есть различные способы сделать ее более визуальной, но это все костыли. Ну и вообще — если бы вы дошли до «визуального» создания тем в том же typo3 — вам бы Друпал раем показался. :-)
у MODx есть версия EVO, она намного проще. По дефолту с установкой идёт стандартный шаблон и набор страниц. Есть визуальный редактор и редактировать страницы можно, перемещаясь по сайту.
А где вывод о WP?
Жалко что и на MODX у автора не хватило сил и терпения, я думаю и сравнивать бы ничего не пришлось
Согласен. Отсюда, абсолютно не соответствующий системе вывод.
А потом юзеру, выбиравшему CMS поэтому топику, будет мучительно больно переходить с Joomla.
Это если еще дорастет.
Это если еще дорастет.
Ряд SEO вообще отказываются продвигать сайты на Joomla или бесплатно переносят, если сайт не большой, а клиент перспективный.
Переносят на свою платную разработку, подскаживая клиента?
Нет. На другую бесплатную систему, но которая для целей seo подходит больше. Seo в чистом виде заинтересованы в получении прибыли за продвижение, ну или рекламу (если ее туда же засовывают), но не в разработке сайта. Тем более я же сказал, что в случае простого сайта, т. е. когда сайт можно полностью перенести менее чем за один рабочий день.
В целом обзор нормальный. Поставленную задачу помогает немного прояснить.
От себя хотелось бы добавить, что если уж рассматривать WordPress, то нужно тогда включать в обзор и MaxSite CMS — max-3000.com
От себя хотелось бы добавить, что если уж рассматривать WordPress, то нужно тогда включать в обзор и MaxSite CMS — max-3000.com
Joomla — наше все. Тем более, что в ближайший месяц версия 3.0 выйдет.
Разработчики сайтов на Joomla должны доплачивать исполнителю
Недавно задался этим же вопросом. Всем кто умеет программировать и нужен просто хороший каркас для небольшого сайта, без всяких свистоперделок и 300 таблиц в БД после установки — категорически рекомендую WolfCMS.
Иногда проще написать свой маленький велосипедик, чем брать чужое. Вот и будет каркас.
Чтобы все учесть, нужно много проработать. Тоже думал над этим, но незачем делать кукурузник.
Скорее нужно иметь достаточный опыт. Изначально разработка своего движка сожрет много времени и сил, но потом это окупится простотой эксплуатации. Да и свой код читать всегда проще. Так что если есть время, желание и силы, лучшим вариантом всегда будет свой движок.
Свое — всегда приятнее… Но на мой взгляд, если вы разработчик, нужно взять перспективный framework (не CMS), где реализованы уже давно изъезженные вещи. Каждый сайт (нормальный сайт) уникален. Модули не всегда предоставляют то что именно хотелось. Изучив фреймворк — вы можете все.
Есть другая вещь, которая очень негативна для клиента (для вас она больше позитивна). Суть в том, что вы подсаживаете клиента и никто, кроме вас не сможет потом это все адекватно поддерживать и развивать.
Видел массу систем, которые вот так были написаны с нуля, но без четкой документации. Как правило через какое-то время разработчик все равно отвалится (уйдет в другую отрасль, ему будут не выгодны или не интересны доработки, еще какие-то причины — денег больше будет хотеть, поссориться с заказчиком) и потом данный проект начинают поддерживать другие люди, которые не знаю особенностей самописной системы. Видели бы вы что из этого рождается… Такая система потом начинает жить своей жизнью.
Причем, при разработке своей системы с нуля, без фреймворка одни двумя людьми есть еще одна опасность: людей профессионалов глубоких в языке и смежных областях (БД, сервер) единицы. И то, что такая-то функция на одной ОС работает так, а на другой иначе — такие вещи, узко специальные, редкие могут знать реально единицы. И популярные CMS или фреймворки тестируют сотни и тысячи людей. Баги находятся оперативно и так же правятся, что нельзя сказать о собственных разработках.
Видел массу систем, которые вот так были написаны с нуля, но без четкой документации. Как правило через какое-то время разработчик все равно отвалится (уйдет в другую отрасль, ему будут не выгодны или не интересны доработки, еще какие-то причины — денег больше будет хотеть, поссориться с заказчиком) и потом данный проект начинают поддерживать другие люди, которые не знаю особенностей самописной системы. Видели бы вы что из этого рождается… Такая система потом начинает жить своей жизнью.
Причем, при разработке своей системы с нуля, без фреймворка одни двумя людьми есть еще одна опасность: людей профессионалов глубоких в языке и смежных областях (БД, сервер) единицы. И то, что такая-то функция на одной ОС работает так, а на другой иначе — такие вещи, узко специальные, редкие могут знать реально единицы. И популярные CMS или фреймворки тестируют сотни и тысячи людей. Баги находятся оперативно и так же правятся, что нельзя сказать о собственных разработках.
В моем случае я сам себе клиент. Но когда писал для других, они получали нормально обдоксигененый код. Этот негатив обусловлен чисто качествами разработчика. Последствия ваших примеров видел и правил.
Да, фреймворк в этом плане очень полезен, но в то же время желательно ему «подрезать крылья» для исключения отстрела воробьев из крупнокалиберных орудий. А то я видел пример, когда ребята такое на фреймворке накрутили… От одного единственного скрипта нужно было выдергивание одной строки таблицы за запрос.
Они к этому делу прикрутили Yii с полной инициализацией. В итоге сервер тормозил от пары пользователей.
Поэтому один из самых важных шагов при старте подобных проектов — правильно подобрать спецов.
Да, фреймворк в этом плане очень полезен, но в то же время желательно ему «подрезать крылья» для исключения отстрела воробьев из крупнокалиберных орудий. А то я видел пример, когда ребята такое на фреймворке накрутили… От одного единственного скрипта нужно было выдергивание одной строки таблицы за запрос.
Они к этому делу прикрутили Yii с полной инициализацией. В итоге сервер тормозил от пары пользователей.
Поэтому один из самых важных шагов при старте подобных проектов — правильно подобрать спецов.
На примере статьи увидел на сколько хорошо у автора развита интуиция, по поводу drupal. Вам бы немного терпения и вы бы нашли и более легкие пути решения проблемы и выполнили все те действия о которых писали.
Интересная система Ionize CMS — www.ionizecms.com/
Очень проста и удобная админка, мультиязычность и CodeIgniter под капотом.
Так же из игниченых не плохая PyroCMS.
Очень проста и удобная админка, мультиязычность и CodeIgniter под капотом.
Так же из игниченых не плохая PyroCMS.
Еще не достает такого обзора для форумных cms. Есть только статистика распространненности.
Какой-то странный, на мой взгляд, обзор. «Тут не нашел, там не получилось». Скорее похоже просто на еще одну историю про то, как кто-то выбирал себе CMS, не особо утруждая себя изучением ни одной из них. В чем смысл, мне решительно не понятно. Тут же на хабре есть обзоры популярных модулей для некоторых систем (для Друпала точно видел, вроде бы и для ModX тоже проскакивало). Если же цель статьи — дать самое базовое представление для совсем уж не смыслящих ни в программировании, ни в CMS людей, то опять же не понятно, зачем, все равно выберут Джумлу.
Drupal: отредактировать шаблон можно в папке: \themes\bartik\templates. Там же можно просто изменить все необходимые блоки.
А вот за такое сразу по рукам. Как вы потом апдейты накатывать будете — диффы смотреть полдня?
Статья печалит.
Автор прошёлся галопом по европам и сообщил нам своё мнение.
Не буду судить за другие системы, но всё что можно было сделать неправильно в Drupal — автор сделал
Автор прошёлся галопом по европам и сообщил нам своё мнение.
Не буду судить за другие системы, но всё что можно было сделать неправильно в Drupal — автор сделал
Печалит не то слово. Это не сравнительный обзор и даже далеко не обзор. Если еще до раздела «Русская локализация администраторской части» хоть чем-то напоминает обзор, то дальше идет полный бред или тестирование не проводилось. Непонятно зачем нада было изначально заявлять Typo3 и MODX, если они «слились» (читать как автор слился) буквально на первых парах.
Вообще, адекватно написать сравнение нескольких CMS сможет только тот, кто поработал со всеми, а так — пальцем в небо.
Вообще, адекватно написать сравнение нескольких CMS сможет только тот, кто поработал со всеми, а так — пальцем в небо.
скорость разработки сайта на движке — очень субъективно,
как для меня, куда важней еще и качество, и скорость поддержки, и развития,
а то дилетанты разработают корпоративный сайт, а потом если что-то добавить — так месяц нужен, или с нуля переделывать
опять ибо на шиткодили по полной.
автор, вам бы снала обзор систем для построения «самых простых сайтов» написать или книг по разработке для новичков,
а потом уж в корпоративный серктор идти.
статья — ни о чём.
как для меня, куда важней еще и качество, и скорость поддержки, и развития,
а то дилетанты разработают корпоративный сайт, а потом если что-то добавить — так месяц нужен, или с нуля переделывать
опять ибо на шиткодили по полной.
автор, вам бы снала обзор систем для построения «самых простых сайтов» написать или книг по разработке для новичков,
а потом уж в корпоративный серктор идти.
статья — ни о чём.
Не дай бог кому то выбрать cms опираясь на данный обзор.
ИМХО, Typo3 лучшая система для больших корпоративных сайтов.
ИМХО, Typo3 лучшая система для больших корпоративных сайтов.
К сожалению, по сравнению с другими она совсем не логична. Видимо ее хотели сделать уникальной, это как искусство.
А я вот, мало того, что полностью согласен с тем, что Typo3 – лучшая (наиболее подходящая) система для среднестатистического корпоративного сайта, но я еще и не понимаю, в чем она НЕЛОГИЧНА?
С точки зрения контет-менеджера это идеальная, удобнейшая, визуальная система, которая на голову выше того же Друпала в плане UX.
С точки зрения программиста – а почему это вообще важно? Вы телефон себе выбираете по критерию, какой было легче разработать?
С точки зрения контет-менеджера это идеальная, удобнейшая, визуальная система, которая на голову выше того же Друпала в плане UX.
С точки зрения программиста – а почему это вообще важно? Вы телефон себе выбираете по критерию, какой было легче разработать?
А, простите, не заметил, кому отвечаю. Вы typo3 не посмотрели же даже, как вы можете говорить? :) прочтите мой комментарий там ниже по тексту.
Создать шаблон для typo3 — это, пожалуй, сложнее, чем для других систем. Но это не должно быть критерием для выбора системы. Сложно, да. Захотите – разберетесь, не захотите – будут ваши клиенты мучиться с друпалом или джангой. Вот мучения клиентов вас должны сильнее волновать.
Создать шаблон для typo3 — это, пожалуй, сложнее, чем для других систем. Но это не должно быть критерием для выбора системы. Сложно, да. Захотите – разберетесь, не захотите – будут ваши клиенты мучиться с друпалом или джангой. Вот мучения клиентов вас должны сильнее волновать.
А в чём по вашему, будут мучения? Учитывыая, что в Drupal можно создать очень хорошую админку на любой вкус, а про джангу-то и говорить смешно, всё в руках разработчика, это всё же фреймворк.
Мы говорим не о том, что потенциально можно приготовить из Друпала (о чистых фреймворках речи вообще нет), а о том, что представляет из себя Друпал как CMS «из коробки». И, не забудьте, применительно к корпоративным сайтам. Я так понимаю, что корпоративный сайт — это богатая контентом иерархическая структура страниц с весьма умеренной интерактивностью, и уж точно не социальная сеть или блог-платформа.
Так вот, для создания сайтов такого вида Друпал не очень подходит. А уж для управления такими сайтами — тем более.
Что есть в typo3 из коробки для этого:
Прекрасная мультиязычность
Наглядная древообразная структура страниц
Несколько различных типов контента (текстовые блоки с и без изображений, формы, таблицы, меню) – это, конечно, есть везде, но в Typo3 оно сделано особенно удобно и дуракоустойчиво
Так вот, для создания сайтов такого вида Друпал не очень подходит. А уж для управления такими сайтами — тем более.
Что есть в typo3 из коробки для этого:
Прекрасная мультиязычность
Наглядная древообразная структура страниц
Несколько различных типов контента (текстовые блоки с и без изображений, формы, таблицы, меню) – это, конечно, есть везде, но в Typo3 оно сделано особенно удобно и дуракоустойчиво
… (сорвалось, продолжаю)
Для каждой страницы – возможность автоматически включить или включить страницу в конкретный момент времени, при желании – полный контроль над ЧПУ, без желания система сделает это за вас.
Для поддержания структуры сайта — драгндропное перемещение/копирование страниц и ветвей, для повторяющихся элементов возможность вставлять ссылки на элемент, чтобы при изменении оригинала менялись его потомки сразу по всему сайту и т.д и т.п.
И все это идет сразу после установки системы. Не надо ставить и настаивать никакие CCK и Views, и в этом огромный плюс Typo3 как CMS (и, разумеется, в этом ее некоторая ограниченность или неуклюжесть для других типов сайтов).
Для каждой страницы – возможность автоматически включить или включить страницу в конкретный момент времени, при желании – полный контроль над ЧПУ, без желания система сделает это за вас.
Для поддержания структуры сайта — драгндропное перемещение/копирование страниц и ветвей, для повторяющихся элементов возможность вставлять ссылки на элемент, чтобы при изменении оригинала менялись его потомки сразу по всему сайту и т.д и т.п.
И все это идет сразу после установки системы. Не надо ставить и настаивать никакие CCK и Views, и в этом огромный плюс Typo3 как CMS (и, разумеется, в этом ее некоторая ограниченность или неуклюжесть для других типов сайтов).
А можно попросить краткий обзор возможностей данной CMS со стороны как пользователя, так и разработчика?
Вы знаете, Typo3 — это очень юзер-ориентированная система, в ней для пользователя весьма мало неочевидных и неожиданных подводных камней (типа как с созданием структуры сайта отдельно в таксономии, контента — отдельно в совершенно другом разделе бэкэнда), это самая удобная система для редактора, которую я только видел — хотя знаю, многие, кто не успел разобраться (или получил недостаточно настроенную под себя систему от программиста) с этим могут не согласиться.
Поэтому возможности этой CMS со стороны пользователя красноречивее всего объяснят скриншоты.
typo3.org/about/the-backend/
Со стороны программиста — в Typo3 довольно просто вписать любой (или любые разные) хтмл-шаблоны, никаких ограничений на их структуру система не накладывает, нет вот этого странного условного разделения на «хедер-контент-футер», которое мы, если не ошибаюсь, встречаем в джумле.
Typo3 использует довольно оригинальный, на первый взгляд неуклюжий, но, если разобраться, чрезвычайно мощный способ описания шаблонов — TypoScript. Он довольно сильно непохож на более привычные подходы типа Smarty или, прости господи, <? echo $content;?>, и является самым большим камнем преткновения для новичков. Чтобы разобраться, приходится реально сделать над собой усилие и читать документацию. Но когда придет понимание, то оказывается, что все не так сложно.
Если же мы выходим за рамки парадигмы «Сайт — это иерархический набор страниц с текстовым контентом», то все быстро начинает становиться хуже, вплоть до того, что для определенного рода проектов Typo3 вообще нет ни малейшего смысла применять, или придется городить кучу экстеншнов. Для разработки экстеншна в систему придется углубиться, конечно, гораздо глубже, и вот тут уже больше смысла будет делать на Друпале с его кастомными типами данных.
Вот, к примеру, базу данных по фильмотеке (Фильмы, жанры, режиссеры, актеры, и все это как-то там пересекается) я бы на Typo3 уже не стал делать. А сайты «О нас / Наши услуги / Партнеры / Контакты» да еще с кучей подрубрик «Наша миссия / Руководство / Забота о персональных данных / О нас пишут» — идеальная область применения Typo3.
Поэтому возможности этой CMS со стороны пользователя красноречивее всего объяснят скриншоты.
typo3.org/about/the-backend/
Со стороны программиста — в Typo3 довольно просто вписать любой (или любые разные) хтмл-шаблоны, никаких ограничений на их структуру система не накладывает, нет вот этого странного условного разделения на «хедер-контент-футер», которое мы, если не ошибаюсь, встречаем в джумле.
Typo3 использует довольно оригинальный, на первый взгляд неуклюжий, но, если разобраться, чрезвычайно мощный способ описания шаблонов — TypoScript. Он довольно сильно непохож на более привычные подходы типа Smarty или, прости господи, <? echo $content;?>, и является самым большим камнем преткновения для новичков. Чтобы разобраться, приходится реально сделать над собой усилие и читать документацию. Но когда придет понимание, то оказывается, что все не так сложно.
Если же мы выходим за рамки парадигмы «Сайт — это иерархический набор страниц с текстовым контентом», то все быстро начинает становиться хуже, вплоть до того, что для определенного рода проектов Typo3 вообще нет ни малейшего смысла применять, или придется городить кучу экстеншнов. Для разработки экстеншна в систему придется углубиться, конечно, гораздо глубже, и вот тут уже больше смысла будет делать на Друпале с его кастомными типами данных.
Вот, к примеру, базу данных по фильмотеке (Фильмы, жанры, режиссеры, актеры, и все это как-то там пересекается) я бы на Typo3 уже не стал делать. А сайты «О нас / Наши услуги / Партнеры / Контакты» да еще с кучей подрубрик «Наша миссия / Руководство / Забота о персональных данных / О нас пишут» — идеальная область применения Typo3.
Вроде выше я видел от Вас коммент что в Typo3 есть аналог CCK.
А тут — обратный. Фильмотека отлично делается на Друпале или Joomla + CCK.
Может все таки более развернутый пост?
ЗЫ. «хедер-контент-футер» встречал в нескольких CMS, но точно не в Joomla — там все таки четкое разделение вида и кода.
А тут — обратный. Фильмотека отлично делается на Друпале или Joomla + CCK.
Может все таки более развернутый пост?
ЗЫ. «хедер-контент-футер» встречал в нескольких CMS, но точно не в Joomla — там все таки четкое разделение вида и кода.
Я джумлу последний раз смотрел, когда она еще была мамбой, там это было.
В Тупо3 нет аналога CCK, для создания нестандартных сущностей (Стурктурированная информация о фильме, например) там придется писать экстеншн. В этом Друпал выигрывает у всех систем, и если нам нужны такие вещи, то Друпал будет лучшим выбором.
Но пока мы говорим о веб-странице, как основной информационной сущности, то Typo3 нам предлагает гораздо больше, чем Друпал «из коробки», и чтобы догнать Typo3, в Друпале придется задействовать CCK.
Вот смотрите, например какая информация о каждой странице может содержаться в Typo3, чего вы не увидите в Друпале, или увидите не там, где было бы логично: (там ниже длинный скриншотище есть, как иллюстрация):
Страница может иметь альтернативное название для меню — например, страница называется «Расчетные и бухгалтерские услуги предприятиям», но в меню оно для краткости будет именоваться «Бухгалтерские услуги».
Подзаголовок — мелочь, но иногда бывает нужно. Где выводится этот подзаголовок, и выводится ли вообще, будет решать программист на этапе создания шаблона.
Каждая страница или вся ветвь страниц может иметь дату, в которую она автоматически станет видна, и дату, когда она автоматически скроется. Всевозможные поздравления с Новым годом, уведомления, маркетинговые акции очень нуждаются в этой возможности.
Каждая страница или ветвь может быть показана пользователям на основе их аутентификации. Это, конечно, есть везде, но посмотрите, где это настраивается в Друпале?
Метаданные о странице — понравится сеошникам, а кроме того, краткое описание страницы может выводиться и в карте сайта.
Дата, когда страница перестанет считаться «новой» — в некоторых случаях нам может захотеться создать меню новых страниц («Новое на сайте»), и какая-то страница нам важнее, и мы хотим, чтобы она считалась новой подольше.
Мы можем в этой точке иерархии вместо контента текущей страницы выводить контент другой страницы. Это довольно редкий юзеркейс, но даже он был продуман. Представьте, к примеру, что для того, чтобы запросить некоторую информацию, пользователь должен заполнить форму, и с ним свяжутся. Ну, к примеру, в разделе «Наше портфолио» по запросу могут выдаваться списки реальных клиентов компании. У вас есть один раз созданная форма, со всеми объяснениями посетителю, с нужными полями… И вы хотите эту страницу показывать в разных местах сайта — «Наши проекты / Автопром», «Наши проекты / Нефтедобывающие компании» и т.п. Для того, чтобы не создавать дубликаты страниц, вы создаете только одну страницу с формой, а остальные страницы будут на нее ссылаться. При изменении контента одной страницы изменения коснутся всех страниц. Получается такой своеобразный шаблон, но сделанный руками контент-менеджера.
Для любой страницы мы можем установить, что она должна открываться в новом окне. Ну, к примеру, страница «Персональный кабинет пользователя».
Для мультиязычных сайтов — для каждой страницы может быть указано, что происходит, если на какой-то из языков эта страница еще не переведена — отображать ли страницу на основном языке или вообще не отображать эту страницу? Причем «не отображать страницу» автоматически означает, что и в меню этой языковой версии посетитель эту страницу не увидит. А не так, что зашел на «Our projects», а там ему 404
Конечно, все это МОЖНО сделать на Друпале. Возможно, для этого достаточно лишь нужные расширения поставить. Но их еще надо найти, они могут конфликтовать друг с другом, у нас может быть несколько разных расширений, делающих вроде бы одно и то же, и все это придется тестировать — а тут прямо из коробки. Поэтому я и говорю — там, где нужны мощные средства управления сайтом как связным набором веб-страниц, Typo3 может оказаться предпочтительнее Drupal.
В Тупо3 нет аналога CCK, для создания нестандартных сущностей (Стурктурированная информация о фильме, например) там придется писать экстеншн. В этом Друпал выигрывает у всех систем, и если нам нужны такие вещи, то Друпал будет лучшим выбором.
Но пока мы говорим о веб-странице, как основной информационной сущности, то Typo3 нам предлагает гораздо больше, чем Друпал «из коробки», и чтобы догнать Typo3, в Друпале придется задействовать CCK.
Вот смотрите, например какая информация о каждой странице может содержаться в Typo3, чего вы не увидите в Друпале, или увидите не там, где было бы логично: (там ниже длинный скриншотище есть, как иллюстрация):
Страница может иметь альтернативное название для меню — например, страница называется «Расчетные и бухгалтерские услуги предприятиям», но в меню оно для краткости будет именоваться «Бухгалтерские услуги».
Подзаголовок — мелочь, но иногда бывает нужно. Где выводится этот подзаголовок, и выводится ли вообще, будет решать программист на этапе создания шаблона.
Каждая страница или вся ветвь страниц может иметь дату, в которую она автоматически станет видна, и дату, когда она автоматически скроется. Всевозможные поздравления с Новым годом, уведомления, маркетинговые акции очень нуждаются в этой возможности.
Каждая страница или ветвь может быть показана пользователям на основе их аутентификации. Это, конечно, есть везде, но посмотрите, где это настраивается в Друпале?
Метаданные о странице — понравится сеошникам, а кроме того, краткое описание страницы может выводиться и в карте сайта.
Дата, когда страница перестанет считаться «новой» — в некоторых случаях нам может захотеться создать меню новых страниц («Новое на сайте»), и какая-то страница нам важнее, и мы хотим, чтобы она считалась новой подольше.
Мы можем в этой точке иерархии вместо контента текущей страницы выводить контент другой страницы. Это довольно редкий юзеркейс, но даже он был продуман. Представьте, к примеру, что для того, чтобы запросить некоторую информацию, пользователь должен заполнить форму, и с ним свяжутся. Ну, к примеру, в разделе «Наше портфолио» по запросу могут выдаваться списки реальных клиентов компании. У вас есть один раз созданная форма, со всеми объяснениями посетителю, с нужными полями… И вы хотите эту страницу показывать в разных местах сайта — «Наши проекты / Автопром», «Наши проекты / Нефтедобывающие компании» и т.п. Для того, чтобы не создавать дубликаты страниц, вы создаете только одну страницу с формой, а остальные страницы будут на нее ссылаться. При изменении контента одной страницы изменения коснутся всех страниц. Получается такой своеобразный шаблон, но сделанный руками контент-менеджера.
Для любой страницы мы можем установить, что она должна открываться в новом окне. Ну, к примеру, страница «Персональный кабинет пользователя».
Для мультиязычных сайтов — для каждой страницы может быть указано, что происходит, если на какой-то из языков эта страница еще не переведена — отображать ли страницу на основном языке или вообще не отображать эту страницу? Причем «не отображать страницу» автоматически означает, что и в меню этой языковой версии посетитель эту страницу не увидит. А не так, что зашел на «Our projects», а там ему 404
Конечно, все это МОЖНО сделать на Друпале. Возможно, для этого достаточно лишь нужные расширения поставить. Но их еще надо найти, они могут конфликтовать друг с другом, у нас может быть несколько разных расширений, делающих вроде бы одно и то же, и все это придется тестировать — а тут прямо из коробки. Поэтому я и говорю — там, где нужны мощные средства управления сайтом как связным набором веб-страниц, Typo3 может оказаться предпочтительнее Drupal.
В чём плюс наличия из коробки какой-то возможности и минус её реализации модулем? Имхо, совершенно надумано.
К тому же CCK с 7 версии Drupal есть из коробки, а не отдельным модулем, соответственно «из коробки» можно создавать сложные типы материалов с дополнительными полями.
Кстати, всё перечисленное вами есть и в Drupal — дерево реализуется таксономией. Типы материалов создаются в необходимом количестве и.т.п.
К тому же CCK с 7 версии Drupal есть из коробки, а не отдельным модулем, соответственно «из коробки» можно создавать сложные типы материалов с дополнительными полями.
Кстати, всё перечисленное вами есть и в Drupal — дерево реализуется таксономией. Типы материалов создаются в необходимом количестве и.т.п.
Есть-то оно есть, но вот удобно ли им пользоваться клиенту (то есть сферической девочке-контент-менеджеру), это вопрос.
Что нужно сделать, чтобы в друпале создать страницу в разделе корпоративного сайта «Наши услуги / Юридическим лицам / Бухгалтерский учет»?
а) Зайти в раздел управления таксономией (который находится в разделе «Структура». В этом же разделе, кстати, есть пункт «Меню». Вот раздел корпоративного сайта — это меню или таксономия?)
б) Выбрать из всех словарей именно тот, который отвечает за дерево сайта. А там и другие словари могут быть.
в) Добавить в словарь термин (понятия-то какие, а? Словарь, Термин, Таксономия...). Не забыть в Relations указать родителя этого термина.
г) Ура, можно переходить собственно к созданию текста — переходим в другой раздел. Создаем… страницу. Нет, статью! Ой, или все-таки страницу?
д) Ищем в таксономии, где там наш термин был?
Слушайте, ну это же не для людей сделано… Этим совершенно неудобно пользоваться ДЛЯ ЭТОЙ ЦЕЛИ.
Для привязывания тегов — да, шикарно. Этого, кстати, в Typo3 практически нет. Но для создания структуры сайта это чертовски неудобно.
Смотрите, как это сделано в Typo3:
Вот так выглядит дерево страниц и вообще интерфейс системы:
А вот тут я свел на одной картинке все табы из настроек страницы, чтобы вы оценили, что значит относиться к контенту как к веб-страницам, а не как к абстрактным универсальным нодам:
(кликабельно).
Это — полные натсройки, которые мы получаем сразу из коробки. С одной стороны, какие-то расширения могут нам принести дополнительные возможности. С другой стороны, для различных типов пользователей бэкэнда администратор может скрыть те или иные настройки так, что пользователь не будет видеть ничего лишнего.
Мне кажется, для ежедневной работы с сайтом это гораздо удобнее, как вы думаете?
Что нужно сделать, чтобы в друпале создать страницу в разделе корпоративного сайта «Наши услуги / Юридическим лицам / Бухгалтерский учет»?
а) Зайти в раздел управления таксономией (который находится в разделе «Структура». В этом же разделе, кстати, есть пункт «Меню». Вот раздел корпоративного сайта — это меню или таксономия?)
б) Выбрать из всех словарей именно тот, который отвечает за дерево сайта. А там и другие словари могут быть.
в) Добавить в словарь термин (понятия-то какие, а? Словарь, Термин, Таксономия...). Не забыть в Relations указать родителя этого термина.
г) Ура, можно переходить собственно к созданию текста — переходим в другой раздел. Создаем… страницу. Нет, статью! Ой, или все-таки страницу?
д) Ищем в таксономии, где там наш термин был?
Слушайте, ну это же не для людей сделано… Этим совершенно неудобно пользоваться ДЛЯ ЭТОЙ ЦЕЛИ.
Для привязывания тегов — да, шикарно. Этого, кстати, в Typo3 практически нет. Но для создания структуры сайта это чертовски неудобно.
Смотрите, как это сделано в Typo3:
Вот так выглядит дерево страниц и вообще интерфейс системы:
А вот тут я свел на одной картинке все табы из настроек страницы, чтобы вы оценили, что значит относиться к контенту как к веб-страницам, а не как к абстрактным универсальным нодам:
(кликабельно).
Это — полные натсройки, которые мы получаем сразу из коробки. С одной стороны, какие-то расширения могут нам принести дополнительные возможности. С другой стороны, для различных типов пользователей бэкэнда администратор может скрыть те или иные настройки так, что пользователь не будет видеть ничего лишнего.
Мне кажется, для ежедневной работы с сайтом это гораздо удобнее, как вы думаете?
в следующий раз используйте spoiler
Я очень давно не прикасался к Typo3, отсюда вопрос — как там с типами данных и запросами? Поясню на примере: у меня есть список вакансий, я хотел бы вывести на главной странице 3 из них (заголовки со ссылками на страницу), случайно выбранных. Как это делается в Type3?
У меня осталось впечатление что Typo3, это система для управления «страницами» — есть некий адрес, по которому расположена страница, собранная из разных блоков. Их можно тасовать, но в целом они принадлежат странице и использовать повторно их никак нельзя. В общем, сайт на Typo3 — это сверстанный буклет. Я сильно далек от истинного положения дел?
У меня осталось впечатление что Typo3, это система для управления «страницами» — есть некий адрес, по которому расположена страница, собранная из разных блоков. Их можно тасовать, но в целом они принадлежат странице и использовать повторно их никак нельзя. В общем, сайт на Typo3 — это сверстанный буклет. Я сильно далек от истинного положения дел?
Ну, начнем с того, что вы хотите неправильного. Если вы каждый раз на данной странице хотите выводить по-разному отсортированное меню, это означает, что вам придется отключить кеш для данной страницы, что резко снизит производительность сайта. Typo3 — система, разумеется, весьма тяжелая, страницы она генерирует нешустро, зато у нее все отлично с кешированием. Не надо заставлять сервер генерировать страницу на каждый запрос пользователя. В идеале, запрос пользователя вообще не должен доходить до PHP, если он обнаруживается в кеше обратного прокси, стоящего перед основным веб-сервером.
Поэтому я бы то, что вы хотите, сделал бы на джаваскрипте — вывел бы в скрытый див полностью меню, а несколько избранных пунктов из него выводил бы при онлоаде.
Но технически сделать это можно, хотя не вполне прямолинейно. Типо3 предоставляет контент-элемент «Карта сайта», который может быть использован контент-менеджером, но к сожалению, у него нет функциональности «показать случайные страницы», он может показать целиком все ссылки подраздела, или набор заранее отобранных ссылок, или набор ссылок на основе ключевых слов.
Поэтому, если вы хотите, чтобы список вакансий был выведен в общем потоке контента (то есть вдруг, на какой-то одной странице, вы пишете — «а вот смотрите, у нас есть такие три вакансии:» — и вот тут список трех рандомных вакансий), придется вставить скрипт на TypoScript. Это, вообще-то, выходит за рамки компетенции контент-менеджера, и ему понадобится помощь программиста (или программисту придется для этого написать простенький экстеншн, и контент-менеджер будет вставлять плагин из списка).
Если же вы хотите, чтобы на каждой странице в определенном месте выводился список этих вакансий, то это уже точно должен сделать программист на этапе создания шаблона — тот же самый TypoScript он впишет в код шаблона.
Про то, что нельзя повторно использовать контент-элементы и целые страницы — очень даже можно, можно было практически всегда, и я этим очень активно пользуюсь. Insert Record называется по-английски.
Поэтому я бы то, что вы хотите, сделал бы на джаваскрипте — вывел бы в скрытый див полностью меню, а несколько избранных пунктов из него выводил бы при онлоаде.
Но технически сделать это можно, хотя не вполне прямолинейно. Типо3 предоставляет контент-элемент «Карта сайта», который может быть использован контент-менеджером, но к сожалению, у него нет функциональности «показать случайные страницы», он может показать целиком все ссылки подраздела, или набор заранее отобранных ссылок, или набор ссылок на основе ключевых слов.
Поэтому, если вы хотите, чтобы список вакансий был выведен в общем потоке контента (то есть вдруг, на какой-то одной странице, вы пишете — «а вот смотрите, у нас есть такие три вакансии:» — и вот тут список трех рандомных вакансий), придется вставить скрипт на TypoScript. Это, вообще-то, выходит за рамки компетенции контент-менеджера, и ему понадобится помощь программиста (или программисту придется для этого написать простенький экстеншн, и контент-менеджер будет вставлять плагин из списка).
Если же вы хотите, чтобы на каждой странице в определенном месте выводился список этих вакансий, то это уже точно должен сделать программист на этапе создания шаблона — тот же самый TypoScript он впишет в код шаблона.
А организовано это так
У нас есть страница «Вакансии», которая в себе содержит подстраницы — по одной на каждую вакансию, всего, предположим, 20.
Вам нужно в каком-то месте вывести список из 3 случайных страниц, родителем которых является страница Вакансии. Для работы с меню TypoScript предоставляет объект HMENU. Вам он и нужен. Не углубляясь в детали, покажу, что нужно сделать, чтобы получить то, что вы просили:
Согласитесь, не так уж много? Да, это работа программиста, но это делается в течение одной чашечки кофе. В настройках страницы или убираем кеширование вообще (ай-яй-яй!), или ставим время жизни кеша 5 минут (это уже терпимо). Все.
Если вы решите, что вывести Х случайных пунктов — довольно частая задача, то напишите экстеншн, кода в котором будет примерно столько же, как я показал, и вооружите им контент-менеджера.
Вам нужно в каком-то месте вывести список из 3 случайных страниц, родителем которых является страница Вакансии. Для работы с меню TypoScript предоставляет объект HMENU. Вам он и нужен. Не углубляясь в детали, покажу, что нужно сделать, чтобы получить то, что вы просили:
10=HMENU
10 {
special=directory
special.value=123
maxItems = 3
}
10.1 = TMENU
10.1 {
wrap=<ul>|</ul>
alternativeSortingField = RAND()
NO {
allWrap=<li>|</li>
}
}
Согласитесь, не так уж много? Да, это работа программиста, но это делается в течение одной чашечки кофе. В настройках страницы или убираем кеширование вообще (ай-яй-яй!), или ставим время жизни кеша 5 минут (это уже терпимо). Все.
Если вы решите, что вывести Х случайных пунктов — довольно частая задача, то напишите экстеншн, кода в котором будет примерно столько же, как я показал, и вооружите им контент-менеджера.
Про то, что нельзя повторно использовать контент-элементы и целые страницы — очень даже можно, можно было практически всегда, и я этим очень активно пользуюсь. Insert Record называется по-английски.
Спасибо за обстоятельный ответ. Немного не понял вашего скепсиса по поводу моих желаний. Хочу я вполне рядовую вещь — типичная «главная страница» собирается из блоков, содержащих наличествующий контент из разных «разделов». 3 последних новости, 5 популярных товаров, 10 последних отзывов, 5 последних комментариев ,10 новых статей… См. любоу сайт на wordpress или drupal. Конечно, это не авторы делают, все это предусматривается на этапе разработки.
Очевидно, со времени моего недолгого знакомства с Typo3 ничего кардинально не изменилось. Жутко не хватает похожего конструктора страниц в Друпале. С произвольным порядком элементов, их сортировкой и т.п.
Еще раз спасибо за ответ.
Очевидно, со времени моего недолгого знакомства с Typo3 ничего кардинально не изменилось. Жутко не хватает похожего конструктора страниц в Друпале. С произвольным порядком элементов, их сортировкой и т.п.
Еще раз спасибо за ответ.
Не, смотрите, если вы хотите 5 последних новостей — то все отлично, у вас новость добавляется раз в 3 дня, стало быть блок «5 последних новостей» будет неизменным в течение этих трех дней. Ляжет в кеш и все прекрасно.
Когда вы хотите 5 случайных новостей, то этот блок нужно перегенерировать для каждой загрузки этой страницы. Все, кеширование отменяется, на каждый запрос у вас поднимается вся Typo3-шная махина.
Для нагруженных сайтов даже просто допускать HTTP-запрос до бэкенд-вебсервера — уже непозволительная роскошь, 99% всех GET-запросов должны останавливаться на frontend-прокси, который эту страницу уже имеет в кеше.
Если вы выводите случайные страницы джаваскриптом, такую страницу можно закешировать, пока не появится новая информация — новость или вакансия. Если вы хотите, чтобы лично сервер для каждого нового посещения генерировал список случайных страниц — вы чересчур расточительны.
Когда вы хотите 5 случайных новостей, то этот блок нужно перегенерировать для каждой загрузки этой страницы. Все, кеширование отменяется, на каждый запрос у вас поднимается вся Typo3-шная махина.
Для нагруженных сайтов даже просто допускать HTTP-запрос до бэкенд-вебсервера — уже непозволительная роскошь, 99% всех GET-запросов должны останавливаться на frontend-прокси, который эту страницу уже имеет в кеше.
Если вы выводите случайные страницы джаваскриптом, такую страницу можно закешировать, пока не появится новая информация — новость или вакансия. Если вы хотите, чтобы лично сервер для каждого нового посещения генерировал список случайных страниц — вы чересчур расточительны.
Меня в общем-то больше интересовала возможность и легкость реализации, а не производительность и побочные эффекты. В рамках этой статьи термин «корпоративный сайт» подразумевает нечто из того же разряда, что и «корпоративный домен». В том смысле, что «корпорация» может быть «ООО Солнышко» (бухгалтер+директор).
Если не трудно, ответьте еще на такой вопрос. Вернемся к «вакансиям» — насколько сложно добавить тип контента (я не знаю как называется это в Typo3), с произвольным набором полей? Для вакансий, к примеру, название, ЗП, требования, условия и т.п. Чтобы авторы потом могли на странице «вакансии» добавлять/удалять позиции.
Если не трудно, ответьте еще на такой вопрос. Вернемся к «вакансиям» — насколько сложно добавить тип контента (я не знаю как называется это в Typo3), с произвольным набором полей? Для вакансий, к примеру, название, ЗП, требования, условия и т.п. Чтобы авторы потом могли на странице «вакансии» добавлять/удалять позиции.
Typo3 — не самая простая система, для ООО Солнышко это наверняка будет чересчур. Кроме того, к ней нет такого количества готовых шаблонов как к вордпрессу или друпалу, typo3 для более дорогого сегмента рынка, на котором кастомну/ разработку оплатят.
С кастомными типами контента — однозначно труднее, чем в Друпале, где этим способен заняться смышленный контент-менеджер. В типо3 придется делать расширение (не с нуля, там есть мастер), но это уже нужно немножечко поизучать.
Например, для этого сайта создано два кастомных типа контента — на главной странице — фото партнера, цитата, имя и ссылка на профиль, и на странице с отраслями — для отрисовки этих шильдиков то же самое. Для каждого типа контента написано по одной функции — как его отображать. По 5 строк, но это все же уже PHP, и безусловно, работа программиста.
С кастомными типами контента — однозначно труднее, чем в Друпале, где этим способен заняться смышленный контент-менеджер. В типо3 придется делать расширение (не с нуля, там есть мастер), но это уже нужно немножечко поизучать.
Например, для этого сайта создано два кастомных типа контента — на главной странице — фото партнера, цитата, имя и ссылка на профиль, и на странице с отраслями — для отрисовки этих шильдиков то же самое. Для каждого типа контента написано по одной функции — как его отображать. По 5 строк, но это все же уже PHP, и безусловно, работа программиста.
Вот вам несколько примеров несложных сайтов, сделанных на Typo3. Куда бы вы там применили друпаловский «конструктор блоков»?
althausgroup.ru/
nebbiahotels.cz/
kraftmetal.ru/
poshivpromo.ru/
Кардинально с точки зрения пользователя в Typo3 действительно ничего не изменилось — ну разве что за исключением рабочих областей, которые позволяют организовать простеникий воркфлоу для публикации нового контента (автор/корректор/редактор/руководитель).
Именно это и удивляет — система до сих пор более чем актуальна, хотя идеологически не меняется уже лет 10.
althausgroup.ru/
nebbiahotels.cz/
kraftmetal.ru/
poshivpromo.ru/
Кардинально с точки зрения пользователя в Typo3 действительно ничего не изменилось — ну разве что за исключением рабочих областей, которые позволяют организовать простеникий воркфлоу для публикации нового контента (автор/корректор/редактор/руководитель).
Именно это и удивляет — система до сих пор более чем актуальна, хотя идеологически не меняется уже лет 10.
Не ссорьтесь, девочки, в MODx это еще удобнее )
Кстати, вы не могли бы показать пару скриншотов хороших админок для управления сайтами с иерархической структурой? Может, я не нащупал этого в друпале? Признаюсь, я к нему отношусь очень субъективно, и даже негативно. Но он первый начал!
В актуальных версиях вордпресса какой-то чудовищный подход к управлению ассетами (изображениями и прчими медиа) — загрузить, скопировать в буфер урл, вставить этот урл где-то на странице, снабдить какими-то странными дополнительными кодами.
В Typo3 вы натурально загружаете файлы к нужной странице, или, если вам нужно повторное использование, то загружаете файл в специально отведенную область, а потом к странице приаттачиваете из списка.
И не надо забывать, что все это многобразие настроек администратор может легко скрыть от контент-менеджера.
В Typo3 вы натурально загружаете файлы к нужной странице, или, если вам нужно повторное использование, то загружаете файл в специально отведенную область, а потом к странице приаттачиваете из списка.
Заголовок
В настройках контент-элемента, вы увидите вот такую картину:Затем...
И не надо забывать, что все это многобразие настроек администратор может легко скрыть от контент-менеджера.
А нахрена modx-то вообще включили?
Интересует у какой CMS наиболее адекватное API для написания расширений для сайта? MODx? Может кто-нибудь просветить?
Каждый кулик своё болото хвалит.
Сегодня только читал dev.1c-bitrix.ru/community/webdev/user/95041/blog/5841/
Могу всё написанное опровергнуть и сказать что друпал рулит
Сегодня только читал dev.1c-bitrix.ru/community/webdev/user/95041/blog/5841/
Могу всё написанное опровергнуть и сказать что друпал рулит
Особо не работал с другими, так как MODX устраивает полностью.
У меня в профиле есть посты про расширения (щас с телефона трудно искать).
У меня в профиле есть посты про расширения (щас с телефона трудно искать).
Освоил MODX за 2 недели, включая построение полностью кастомного сайта, не сложно просто надо вдуматься, если поискать в гугле есть сайтик со статьями по азам, оттуда все понятно, для плагинов есть сайт с АПИ на русском. Пока доволен, работает шустро, жеско топорная админка, но я привык, за то взамен очень, подчеркну ОЧЕНЬ гибкий инструмент. Чтобы не обвинили в том что свое болото хвалю, скажу что работал с WP, Joomla, WebAssyst, Drupal, СвояЦмс помимо Модкс.
А почему в обзоре нет dotCMS?
Нет в Рейтинге Рунета www.ratingruneta.ru/cms/2011/opensource/
Пробовал все перечисленные автором CMS.
Лучшее из них — CMS Made Simple. Гибко, легко и вполне удобный backend.
Выводы автора насчет CMS Made Simple — неправильные.
Чтобы ЧПУ заработали — нужно в конфиге прописать:
$config['url_rewriting'] = 'mod_rewrite';
$config['use_hierarchy'] = true;
$config['page_extension'] = '/';
$config['query_var'] = 'page';
Далее прописать настройки в .htaccess (смотрите на сайте движка) и будем вам счастье со слешами наконце.
Лучшее из них — CMS Made Simple. Гибко, легко и вполне удобный backend.
Выводы автора насчет CMS Made Simple — неправильные.
Чтобы ЧПУ заработали — нужно в конфиге прописать:
$config['url_rewriting'] = 'mod_rewrite';
$config['use_hierarchy'] = true;
$config['page_extension'] = '/';
$config['query_var'] = 'page';
Далее прописать настройки в .htaccess (смотрите на сайте движка) и будем вам счастье со слешами наконце.
www.loadstar.ru/ что то он меня совсем не впечатлил, пощюпав интерфейс понял что он дерьмовый
Это совсем не профессионально, а просто ляпсус. Он все же на первом месте www.ratingruneta.ru/awards/2011/services/ или Вы думаете, что это место купили? Нет обоснования.
WordPress: в базе обратной связи нет. Не нашел хорошего плагина. Но в принципе их довольно много, так что подходящий наверняка найдется.
Плохо искали. Contact Form 7
Хм. Почему-то очень много приходится ковыряться с DLE у заказчиков, а не с вышеописанными.
Вот, кстати, лично для меня еще одна интересная CMS. Интересная тем, что хотелось бы узнать чем эта CMS такая примечательная. Лично я сталкивался только с nulled версиями у заказчиков и приходил в дикий ужас от такой постановки. Ведь DLE самый дешовый движок из популярных платных.
В чем подвох? В чем преимущество этой CMS перед другими бесплатными, что ее стоит воровать?
В чем подвох? В чем преимущество этой CMS перед другими бесплатными, что ее стоит воровать?
О чем статья вообще?
Поработав в говностудии «магазин за месяц» у меня при виде фраз, типа «выбрать лучшую систему для создания корпоративных сайтов» у меня волосы выпадают и кровь из глаз идет
Поработав в говностудии «магазин за месяц» у меня при виде фраз, типа «выбрать лучшую систему для создания корпоративных сайтов» у меня волосы выпадают и кровь из глаз идет
Интересовало: простота создания и отсутствие дальнейших проблем. Также цель отсутствие проблем в бизнес процессах, поскольку: ставить модули, писать новые модули, копаться в шаблонах, много настроек!, проблемы с обновлением и др., много забирает времени. Цены у нас дорогие, а скорость создания мы хотим оптимизировать.
Как вы можете судить о «Также цель отсутствие проблем в бизнес процессах, поскольку: ставить модули, писать новые модули, копаться в шаблонах, много настроек!, проблемы с обновлением и др., много забирает времени.», когда вы не потрудились разобраться, как что и почему реализуется в той или иной системе?
Пример:
Для однотипных сайтов у того же Drupal есть механизм создания сборок, где сайт разворачивается с нужными модулями и.т.п. Есть модуль features, который позволяет упаковать куски готового функционала в модуль.
Пример:
Наличие некоторого количества своих готовых сниппетов, позволяет быстро создавать типовой сайт на modX.
Вообще, одно то, что вы рассматриваете CMS без модулей огромная ошибка — в большинстве случаев, в ядро идёт минимально необходимый и самый распространённый функционал, и средства для его расширения.
Хороший пример — отсутствие визуального редактора в Drupal. Он может быть вообще не нужен на сайте. Может быть удобен какой-либо определённый. И следовательно, он ставится модулем, если нужен, и тот, который уместнее в данном случае.
Пример:
Для однотипных сайтов у того же Drupal есть механизм создания сборок, где сайт разворачивается с нужными модулями и.т.п. Есть модуль features, который позволяет упаковать куски готового функционала в модуль.
Пример:
Наличие некоторого количества своих готовых сниппетов, позволяет быстро создавать типовой сайт на modX.
Вообще, одно то, что вы рассматриваете CMS без модулей огромная ошибка — в большинстве случаев, в ядро идёт минимально необходимый и самый распространённый функционал, и средства для его расширения.
Хороший пример — отсутствие визуального редактора в Drupal. Он может быть вообще не нужен на сайте. Может быть удобен какой-либо определённый. И следовательно, он ставится модулем, если нужен, и тот, который уместнее в данном случае.
в Joomla с SEO
у вас 404 по моему потому, что у вас файл htaccess.txt не переименован в .htaccess
joomla об этом кстати говорит
у вас 404 по моему потому, что у вас файл htaccess.txt не переименован в .htaccess
joomla об этом кстати говорит
Какая-то статья чисто инвайта ради…
Автор по-быстрому накачал CMS-ок, потыкался, написал что видит, с чем с налёту не разобрался, сразу послал на помойку. Выводы по CMS-кам так вообще с потока взяты.
В разное время «щупал» половину из этих CMS-ок и с автором в корне по многим позициям не согласен, особенно в плане Drupal'а, Typo и MODx.
Чего стоят фразы типа «Анализ CMS в контексте SEO. MODx — Тестирование не проводилось»… А чего там тестировать? Там «из коробки» отличный модуль SEO идёт, в нём даже и разбираться то не надо, всё понятно и прозрачно.
Автор по-быстрому накачал CMS-ок, потыкался, написал что видит, с чем с налёту не разобрался, сразу послал на помойку. Выводы по CMS-кам так вообще с потока взяты.
В разное время «щупал» половину из этих CMS-ок и с автором в корне по многим позициям не согласен, особенно в плане Drupal'а, Typo и MODx.
Чего стоят фразы типа «Анализ CMS в контексте SEO. MODx — Тестирование не проводилось»… А чего там тестировать? Там «из коробки» отличный модуль SEO идёт, в нём даже и разбираться то не надо, всё понятно и прозрачно.
Обзор ужасен! С самого начала озвученная задача сформулирована в другом ключе, нежели сам обзор.
Правильно было написать выбрать лучшую систему для создания корпоративных сайтов без последующей поддержки, изучения вопросов безопасности и гарантий.
Если много заказов на создание сайтов и такой подход к делу, то после первой волны критической уязвимости и поломанных сайтов будет не то чтобы до приличных разговоров.
Идет обзор PHP CMS и при этом взят во внимание CMF MODx Revo. Там даже на сайте крупно указывается, что CMS простая — это Evolution! Drupal тоже часто относят к каркасам с готовым интерфейсом и админкой.
В общем неуд.
Для тех ж, кто зашел почитать статью комментарии внесу свою лепту.
Джумла — никогда. Друпал — если есть рядом специалист. Модэкс ево — исключительно удобен во всех отношениях. Вордпресс — очень неповоротлив в неопытных руках. МейдСимпл — прост и местами нетривиален при решении нетипичных задач.
Правильно было написать выбрать лучшую систему для создания корпоративных сайтов без последующей поддержки, изучения вопросов безопасности и гарантий.
Если много заказов на создание сайтов и такой подход к делу, то после первой волны критической уязвимости и поломанных сайтов будет не то чтобы до приличных разговоров.
Идет обзор PHP CMS и при этом взят во внимание CMF MODx Revo. Там даже на сайте крупно указывается, что CMS простая — это Evolution! Drupal тоже часто относят к каркасам с готовым интерфейсом и админкой.
В общем неуд.
Для тех ж, кто зашел почитать статью комментарии внесу свою лепту.
Джумла — никогда. Друпал — если есть рядом специалист. Модэкс ево — исключительно удобен во всех отношениях. Вордпресс — очень неповоротлив в неопытных руках. МейдСимпл — прост и местами нетривиален при решении нетипичных задач.
Джумла — никогда. Чому?
На самом деле, CMS Joomla не заслуживает такой неприязни… Joomla в сочетании с одним из конструкторов контента: K2, Zoo, Cobalt 7 или Seblod (о них я писал тут), вполне подходит для большинства задач. Так же для Joomla имеется весьма интересный Widgetkit, который тесно интегрируется с Zoo, т.к. оба инструмента от одного производителя.
Выход Joomla 3, имхо, не привнесет чего то революционного, но использование Bootstrap, как единого стандарта пользовательского интерфейса, полный переход на jQuery и вектор в строну адаптивного дизайна — это несомненно шаг вперед. На сайте joomlablog.ru есть несколько статей о грядущей Joomla 3, если кому интересно.
Лично я нашел для себя более удобный инструмент… к слову, он присутствует в обзоре.
Joomla же не устроила по следующим субъективным причинам:
Очевидный вывод, использование Joomla — дело вкуса и в умелых руках, это вполне себе достойный инструмент.
Выход Joomla 3, имхо, не привнесет чего то революционного, но использование Bootstrap, как единого стандарта пользовательского интерфейса, полный переход на jQuery и вектор в строну адаптивного дизайна — это несомненно шаг вперед. На сайте joomlablog.ru есть несколько статей о грядущей Joomla 3, если кому интересно.
Лично я нашел для себя более удобный инструмент… к слову, он присутствует в обзоре.
Joomla же не устроила по следующим субъективным причинам:
- Совершенно не нравится админка — в плане юзабилити. Ах, это сладкое слово — Ajax. Админка в v3.0alpha тоже не впечатлила.
- Многие скажут, что весомым плюсом Joomla является наличие огромного количества всевозможных расширений. Но хороших расширений для Joomla гораздо меньше чем плохих. И это факт.
- Много чего не доступно из коробки, поэтому через какое то время Joomla обвешивается всевозможными «плюшка», как елка гирляндами и мишурой. Но можно подобрать себе джентльменский набор, например: Joomla + Zoo + Widgetkit + расширения от ZooLanders или другое сочетание.
- Часто сталкивался с несовместимостью модулей, плагинов и компонентов от разных веток Joomla и даже версий внутри веток.
- Не гибкая работа с шаблонами, опять же не совместимость шаблонов для разных версий. Бытует даже мнение о «политике несовместимости», которой придерживается дядя Andy Miller &Co. Miller — один из соучредителей Joomla, и генеральный директор RocketTheme — ведущая компания по разработке шаблонов для Joomla, которой естественно выгодно, чтобы у них приобретали шаблоны при переходе на новые ветки Joomla и обращались за поддержкой. Возможно мнение — надумано, но как говорится «нет дыма без огня».
- «Сайт знакомого на Joomla находится в Топ-100 самых нагружаемых хостинг сайтов при посещаемости всего в несколько сотен человек» © один человек. Но причина скорее в количестве и качестве расширений, устанавливаемых «поверх» Joomla...
- Virtuemart — самый забавный компонент Joomla. Огромное количество сайтов его используют. А он даже не кешируется Джумлой (Epic Fail). Не знаю как сейчас — не проверял. Благо есть замена — Tienda Shop, но он не так популярен.
Очевидный вывод, использование Joomla — дело вкуса и в умелых руках, это вполне себе достойный инструмент.
Очень поверхностный обзор «по впечатлениям».
Начиная от системных требований: видимо тупо покопировано. У Джумлы указана поддержка mysql. Можно подумать другие без нее работают? (а больше ни у одной не указано. Нет, еще у ворд пресса. Но что это за строчка: «MySQL 5.0 or greaterThe mod_rewrite Apache module»?). У всех систем одни и те же вещи названы по разному (почему везде gd, а у CMS Made Simple — GD library?
Начиная от системных требований: видимо тупо покопировано. У Джумлы указана поддержка mysql. Можно подумать другие без нее работают? (а больше ни у одной не указано. Нет, еще у ворд пресса. Но что это за строчка: «MySQL 5.0 or greaterThe mod_rewrite Apache module»?). У всех систем одни и те же вещи названы по разному (почему везде gd, а у CMS Made Simple — GD library?
Как-то (года 4 назад) была задача быстро сделать аналогичный сайт (горели сроки, предыдущий программист исчез в неизвестном направлении).
Были готовы макеты в PSD, надо было делать все остальное (верстка, прикручивание шаблонов к CMS и немного программирования).
Почему я тогда решил попробовать MODx — даже не знаю, я ее видел второй раз, наверное. В общем, это был самый быстросозданный мною сайт, меньше чем через сутки все сдали заказчику.
В общем, жаль, что автору не хватило времени на прочтение документации по MODx — это тот случай, когда «удобно в использовании» и «интуитивно понятно» не являются тождественными понятиями.
Были готовы макеты в PSD, надо было делать все остальное (верстка, прикручивание шаблонов к CMS и немного программирования).
Почему я тогда решил попробовать MODx — даже не знаю, я ее видел второй раз, наверное. В общем, это был самый быстросозданный мною сайт, меньше чем через сутки все сдали заказчику.
В общем, жаль, что автору не хватило времени на прочтение документации по MODx — это тот случай, когда «удобно в использовании» и «интуитивно понятно» не являются тождественными понятиями.
Вообще дело в профессиональности разработчика и его опыте работы с конкретной cms. Если человек профессионально делает сайты на одной из cms или фреймворков, имеет наработки. То создание небольшого сайта (пара лет, каталог, форма обратной связи) у него больше половины дня и не займут.
Вот и дело-то в том, что я попробовать решил MODx безо всякого опыта работы с ней. Скажем, я не уверен, что с друпалом (или, не дай бог, Typo3) у меня все так же гладко получилось бы. Я, конечно, подозреваю, что для каких-нибудь более сложных задач он, может, подошел бы и больше, но мне для них уже было бы удобнее использовать какой-нибудь фреймворк, что ли.
Такую задачу вы бы решили примерно одинаково быстро на любой CMS, обратившись к различным howto в сообществе соотвествующей CMS. Т.к. задача шаблонная и тривиальная.
Вот если понадобилось бы что-нибудь посложнее, влияние выбора инструмента могло оказаться куда критичнее…
Вот если понадобилось бы что-нибудь посложнее, влияние выбора инструмента могло оказаться куда критичнее…
Задача всегда шаблонная и тривиальная по общему описанию, только в реальности всегда какие-нибудь мелочи вылезают, которые достаточно сильно портят жизнь, и как на зло, эти мелочи не учитываются ни в одном howto =)
В общем, если бы я разбирался с нуля с друпалом, то точно сделал бы ощутимо медленнее. MODx для таких мелких сайтов подходит сильно лучше со всех сторон.
В общем, если бы я разбирался с нуля с друпалом, то точно сделал бы ощутимо медленнее. MODx для таких мелких сайтов подходит сильно лучше со всех сторон.
Вы немного невнимательны: простейшая и понятнейшая система Модэкс Эволюшн вполне устроила бы данного автора, но его взор пал на модэкс революшн, что совсем не пролетарская система. Отсюда и наше всеобщее разочарование.
На уровне этого поста они не отличаются никак.
Те же сниппеты, чанки, плагины и шаблоны. В шаблон пихается все предыдущие + системные переменные.
Различия начинаются, когда надо попрограммировать. Ну и расширения у Revo дюже богаче, из-за ExtJS в админке.
Видимо, важнейшим критерием стало отсутствие расширений и примеров в комплекте. Но ведь есть же мини how-to, и далеко ходить не нужно.
В общем, MODX он откровенно подставил.
Те же сниппеты, чанки, плагины и шаблоны. В шаблон пихается все предыдущие + системные переменные.
Различия начинаются, когда надо попрограммировать. Ну и расширения у Revo дюже богаче, из-за ExtJS в админке.
Видимо, важнейшим критерием стало отсутствие расширений и примеров в комплекте. Но ведь есть же мини how-to, и далеко ходить не нужно.
В общем, MODX он откровенно подставил.
За годы я успел поработать с самыми популярными решениями из этих и выскажу своё мнение (опять же перекошенное в одну сторону, но):
Joomla и Wordpress — это, простите, сборники нерасширяемого и неподдерживаемого говнокода. О них всерьез говорить очень не хочется.
Modx — система, которая изначально даёт очень много гибкости и позволяет всё делать из админки с помощью написания кода. Я сделал на ней в общей сложности проектов 30. Она очень неплохо подходит для небольших и средних сайтов, но со временем я понял, что некоторые проекты занимают у меня кучу времени и на выходе получается не то, что мне бы (как разработчику) хотелось бы.
Когда возникают задачи построения динамических каталогов и ещё каких-то не совсем тривиальных штук, то modx начинает… нет, сосать не начинает, он справляется с этой задачей, но зачастую приходиться делать что-то очень некрасивое и медленно работающее. Плюс половина кода в базе, половина на диске — это плодит некую энтропию. Безусловно, есть методы решения этого, а в revolution целый фреймворк написан (в отличии от switch case на 100 элементов в evolution) и всё нацелено на правильность кода и тотальный ООП, но я понял, что не хочу больше возвращаться к этой системе для повседневной работы.
В drupal сильны отголоски Joomla и Wordpress — постоянно прослеживается идея «накликать» сайт. Однако, достаточно немного поизучать систему, как становиться понятно, что это всё шелуха, а под ней есть мощная система, которую можно настраивать почти как угодно.
Из коробки в друпале можно сконфигурировать динамический каталог и бровью не повести. А если подключить double field, то можно сконфигурировать динамический каталог с динамическими продуктами (разные свойства у товаров в пределах одной категории, например). И это делается за 10 минут.
Код, на который ругается автор (который генерируется автоматически) — код регионов, он легко конфигурирется добавлением шаблонов region-. Шаблоны блоков с помощью blocktemplate, шаблоны views (кстати, новости с помощью них выводятся) — semanticviews. С помощью всего этого весь код, который генерирует система для клиента, поддается контролю.
На первый взгляд это кстати разительно отличается от того же modx в силу того, что в modx лежит в базе шаблон с плейсхолдерами, что написал — то и вывелось. Но на деле в друпале тоже самое, за исключением того, что в друпале есть иерархия шаблонов, а в modx нет. И при поточной разработке оказывается, что это минус modx, а не его плюс.
Конечно, самые идеальные шаблоны (что я видел) — в джанге. И друпалу до них плыть и плыть, но благодаря иерархии достигается достаточно гибкий подход.
Да, друпал и правда неплохая система. У него, конечно, есть большой минус — это скорость работы. 9-10 мерные хэши, которые генерируются на каждой странице, сложные sql запросы (собирающие данные из кучи кучи полей, если вы конфигурируете поля), большое количество таблиц (у меня для не очень сложного проекта в бд 380 таблиц, например) — по 2 на каждое поле, архитектура. Да, архитектура друпала одновременно гигантский плюс и гигантский минус.
Плюс потому, что засчёт системы хуков ядро системы трогать не нужно почти никогда (если только вы не обнаружите критичный баг в ядре, как я :) — все реализуется хуками. Их много и зачастую не всё ясно, но в документации можно найти почти всё.
А минус потому что все модули до единого подключаются везде (код из них точно везде выполняется) — в них могут быть хуки и поэтому друпал их включает и делает вызовы. Я плохо понимаю как друпал может работать на хайлоаде.
Ещё, конечно, можно вспомнить битрикс. Конечно он не из этого списка, но всё же, мне очень нравятся его инфоблоки (и много много чего не нравится), которые концептуально смахивают на друпаловский Field API (CCK).
Хочу сказать, что CMS без управления полями — это не CMS.
Joomla и Wordpress — это, простите, сборники нерасширяемого и неподдерживаемого говнокода. О них всерьез говорить очень не хочется.
Modx — система, которая изначально даёт очень много гибкости и позволяет всё делать из админки с помощью написания кода. Я сделал на ней в общей сложности проектов 30. Она очень неплохо подходит для небольших и средних сайтов, но со временем я понял, что некоторые проекты занимают у меня кучу времени и на выходе получается не то, что мне бы (как разработчику) хотелось бы.
Когда возникают задачи построения динамических каталогов и ещё каких-то не совсем тривиальных штук, то modx начинает… нет, сосать не начинает, он справляется с этой задачей, но зачастую приходиться делать что-то очень некрасивое и медленно работающее. Плюс половина кода в базе, половина на диске — это плодит некую энтропию. Безусловно, есть методы решения этого, а в revolution целый фреймворк написан (в отличии от switch case на 100 элементов в evolution) и всё нацелено на правильность кода и тотальный ООП, но я понял, что не хочу больше возвращаться к этой системе для повседневной работы.
В drupal сильны отголоски Joomla и Wordpress — постоянно прослеживается идея «накликать» сайт. Однако, достаточно немного поизучать систему, как становиться понятно, что это всё шелуха, а под ней есть мощная система, которую можно настраивать почти как угодно.
Из коробки в друпале можно сконфигурировать динамический каталог и бровью не повести. А если подключить double field, то можно сконфигурировать динамический каталог с динамическими продуктами (разные свойства у товаров в пределах одной категории, например). И это делается за 10 минут.
Код, на который ругается автор (который генерируется автоматически) — код регионов, он легко конфигурирется добавлением шаблонов region-. Шаблоны блоков с помощью blocktemplate, шаблоны views (кстати, новости с помощью них выводятся) — semanticviews. С помощью всего этого весь код, который генерирует система для клиента, поддается контролю.
На первый взгляд это кстати разительно отличается от того же modx в силу того, что в modx лежит в базе шаблон с плейсхолдерами, что написал — то и вывелось. Но на деле в друпале тоже самое, за исключением того, что в друпале есть иерархия шаблонов, а в modx нет. И при поточной разработке оказывается, что это минус modx, а не его плюс.
Конечно, самые идеальные шаблоны (что я видел) — в джанге. И друпалу до них плыть и плыть, но благодаря иерархии достигается достаточно гибкий подход.
Да, друпал и правда неплохая система. У него, конечно, есть большой минус — это скорость работы. 9-10 мерные хэши, которые генерируются на каждой странице, сложные sql запросы (собирающие данные из кучи кучи полей, если вы конфигурируете поля), большое количество таблиц (у меня для не очень сложного проекта в бд 380 таблиц, например) — по 2 на каждое поле, архитектура. Да, архитектура друпала одновременно гигантский плюс и гигантский минус.
Плюс потому, что засчёт системы хуков ядро системы трогать не нужно почти никогда (если только вы не обнаружите критичный баг в ядре, как я :) — все реализуется хуками. Их много и зачастую не всё ясно, но в документации можно найти почти всё.
А минус потому что все модули до единого подключаются везде (код из них точно везде выполняется) — в них могут быть хуки и поэтому друпал их включает и делает вызовы. Я плохо понимаю как друпал может работать на хайлоаде.
Ещё, конечно, можно вспомнить битрикс. Конечно он не из этого списка, но всё же, мне очень нравятся его инфоблоки (и много много чего не нравится), которые концептуально смахивают на друпаловский Field API (CCK).
Хочу сказать, что CMS без управления полями — это не CMS.
2 меню, статьи и лента новостей это корпоративный сайт теперь?..
Это Хабр, тут исторически сложилась неприязнь.
Дык она везде, кроме сообщества Joomla, видимо. Чтобы понять, откуда она, надо взять и заставить себя изучить-таки что-то ещё. =) Потом костыли, необходимые, чтобы сделать что-то достойное на Joomla будут вспоминаться, как страшный сон.
Ну лично я, кроме того что хорошо знаком с Joomla, знакомился и делал сайты на Drupal, ModX, LiveStreet, Cogear, MaxSite и еще наверно несколько забыл.
Какие то понравились, какие-то — не очень. Часть лучше под некоторые задачи, часть хуже.
Так что стараюсь смотреть объективно и сравнивать последние версии.
Костыли кстати были только в Joomla 1.0, выше уже работает концепция MVC.
А вот в той же довольно любимой LiveStreet 0.4.x MVC мягко говоря плохо реализовано.
Какие то понравились, какие-то — не очень. Часть лучше под некоторые задачи, часть хуже.
Так что стараюсь смотреть объективно и сравнивать последние версии.
Костыли кстати были только в Joomla 1.0, выше уже работает концепция MVC.
А вот в той же довольно любимой LiveStreet 0.4.x MVC мягко говоря плохо реализовано.
Joomla 1.6+ имеет встроенную поддержку мультиязычности.
Что касается ЧПУ, то title документов прописываются либо в меню, либо в документах.
Что касается ЧПУ, то title документов прописываются либо в меню, либо в документах.
Статья бестолковая, честно говоря. Методы и параметры сравнения вызывают, мягко говоря, удивление. Выводы и того хуже — я так и не понял, что же в итоге выбрано?
Вероятно, статья была рассчитана на начинающих веб-разработчиков от начинающего веб-разработчика. Надо было так и заявить в самом начале, воспринималось бы совсем иначе.
Идеальных систем не бывает, во всех есть свои плюсы и минусы, причем в каждом случае минусы и плюсы у большинства разработчиков будут разными. Поэтому все подобные анализы страшно отдают необъективностью.
Вероятно, статья была рассчитана на начинающих веб-разработчиков от начинающего веб-разработчика. Надо было так и заявить в самом начале, воспринималось бы совсем иначе.
Идеальных систем не бывает, во всех есть свои плюсы и минусы, причем в каждом случае минусы и плюсы у большинства разработчиков будут разными. Поэтому все подобные анализы страшно отдают необъективностью.
Зачем вабще упоминать в обзоре Тайпо и Модх, если тестирование не проводилось по всем пунктам ??? Из за Модекса и хотел посмотреть
Жаль, что автор не разобрался с MODx, выводы могли бы в корне измениться. Уж что что, а в MODx управление контентом сделано проще некуда. А шаблон прикрутить, так вообще дело пары минут. Да и все остальное не так уж и сложно. В программировании не особо хорошо разбираюсь, но с MODx у меня ни разу еще не было ситуации, что бы я не смог что-то сделать сам.
Хотел еще про Drupal почитать, но вижу что ничего тут интересного нету.
Хотел еще про Drupal почитать, но вижу что ничего тут интересного нету.
Статья неудовлетворительная, таких полуобзоров завлись.
Выводы и утверждения автора очень расстроили. Видно что достаточно внимания тестированию уделено не было.
А что же до WP: Он удобен во всех отношениях, на нем можно делать не типичные сайты, не шаблонные, и т.д. и т.п. В плоть до того, что можно сделать от блога, до Интернет магазина, Рубрикатора, Доски объявлений, Тикетной системы да в принципе всего на что фантазии хватит. Вся работа над системой упирается в минимальное углубление в WP Codex, где разжевано все, и верстка как таковая. Но в большей степени WP более лоялен к пользователям со стороны бэкэнда. Все красиво удобно и понятно. А структура шаблонов настолько проста, что порой просто плакать хочется, глядя на внутренности Джумлы =)
Джумла страшна как жизнь
Друпал для любителей более тонких извращений и дополнительного кодинга.
МодХ слишком прост.
Для себя считаю что WP это золотая середина, не без недостатков, но тюнинг WP оставляет лучшие впечатления от процесса нежели остальные системы.
Выводы и утверждения автора очень расстроили. Видно что достаточно внимания тестированию уделено не было.
А что же до WP: Он удобен во всех отношениях, на нем можно делать не типичные сайты, не шаблонные, и т.д. и т.п. В плоть до того, что можно сделать от блога, до Интернет магазина, Рубрикатора, Доски объявлений, Тикетной системы да в принципе всего на что фантазии хватит. Вся работа над системой упирается в минимальное углубление в WP Codex, где разжевано все, и верстка как таковая. Но в большей степени WP более лоялен к пользователям со стороны бэкэнда. Все красиво удобно и понятно. А структура шаблонов настолько проста, что порой просто плакать хочется, глядя на внутренности Джумлы =)
Джумла страшна как жизнь
Друпал для любителей более тонких извращений и дополнительного кодинга.
МодХ слишком прост.
Для себя считаю что WP это золотая середина, не без недостатков, но тюнинг WP оставляет лучшие впечатления от процесса нежели остальные системы.
Господа, а проконсультируйте меня по миру PHP. Я уже много лет занимаюсь разработкой на Python/Django, часто использую Django CMS. Те, кто использовал CMS на PHP и DjangoCMS, напишите краткое сравнение. Вне зависимости от языка, от платформы, размеров сообщества и количества плагинов, какие ваши ощущения? Насколько Django CMS (или прочие) сравнима с аналогами?
джанга не cms. джанга — фреймворк.
тут не равнины тут климат иной
тут не равнины тут климат иной
Вы в целом правы. Мы делаем сайт по большей части на Django, Django CMS используется в основном для страниц, их иерархии и меню. Вот мне и интересно, что ещё могут предоставить аналоги из PHP мира кроме плагинов на все случаи жизни.
И ещё: я часто встречал подобные вопросы в сети и везде ответ сводился к тому что «нууу, это разные вещи, их не стоит сравнивать». Я работаю с вебом много лет и я не понимаю, почему это разные вещи.
И ещё: я часто встречал подобные вопросы в сети и везде ответ сводился к тому что «нууу, это разные вещи, их не стоит сравнивать». Я работаю с вебом много лет и я не понимаю, почему это разные вещи.
Существует как минимум одна, довольно-таки веская причина — массовость php хостинга.
Есть и ещё одна — количество разработчиков php со средней квалификацией, способных недорого допилить сайт на одной из CMS до нужного клиенту вида.
Есть и ещё одна — количество разработчиков php со средней квалификацией, способных недорого допилить сайт на одной из CMS до нужного клиенту вида.
> Существует как минимум одна, довольно-таки веская причина — массовость php хостинга.
Так что же всем теперь под хостинг подстраиваться? Помоему время разработчика дороже.
Так что же всем теперь под хостинг подстраиваться? Помоему время разработчика дороже.
Это не все понимают, как ни странно.
Да, и время разработчика на Python обычно ещё дороже, если вы уж так вопрос ставите. =)
А массовость php хостинга, это большой выбор и отсутствие для клиента проблемы смены хостинга, например…
Опять же много-ли заказчиков знают о JangoCMS? О Jango? О Python?
А кто из них не слышал о PHP?
Вот тут и станет понятна проблема массовости.
Хотя я не спорю, что это весьма хорошие инструменты, с технической точки зрения, в некоторых моментах они удачнее, чем PHP, и фреймворки на нём.
А массовость php хостинга, это большой выбор и отсутствие для клиента проблемы смены хостинга, например…
Опять же много-ли заказчиков знают о JangoCMS? О Jango? О Python?
А кто из них не слышал о PHP?
Вот тут и станет понятна проблема массовости.
Хотя я не спорю, что это весьма хорошие инструменты, с технической точки зрения, в некоторых моментах они удачнее, чем PHP, и фреймворки на нём.
вот недавно cms для магазинов обсуждали на форуме yii EximusCommerce.
DjngoCMS — это впервую очередь Django(тоесть ещё и могучий фреймворк по требованию)
обычные CMS — это просто CMS
обычные CMS — это просто CMS
> Joomla: встроенной возможности для двуязычности нет
Пойду расскажу своей коробочной мультиязычности Joomla что её не существует. Плохо разобрались, нужно добавить дополнительные «языки контента» и будет мультиязычность, Joomfish устарел уже очень давно.
Пойду расскажу своей коробочной мультиязычности Joomla что её не существует. Плохо разобрались, нужно добавить дополнительные «языки контента» и будет мультиязычность, Joomfish устарел уже очень давно.
простите, но логики в друпале вобще нет. уж лучше modx
а вобще не любл cms. чтото у авторов в мозгах заклинило на 90 годы
а вобще не любл cms. чтото у авторов в мозгах заклинило на 90 годы
Как можно не имея, судя по всему, вообще никаких знаний ни в одной из выбранных для обзора CMS, да и в создании сайтов вообще, писать такой «обзор»? Это не обзор, а откровенная профанация.
Какой вам корпоративный сайт? Вам пока даже личный блог поднимать рано. Зачем так позориться?
И ведь такое ощущение, что немало таких людей, всерьёз лезут делать сайты своих фирм, а то даже за деньги предлагают свои «услуги». Не получится, какая бы не была CMS, у далёкого от сайтостроения человека вот так с ходу, сделать на ней хороший сайт. Да и у человека хоть что-то понимающего, не разобравшись с конкретным инструментом не получится.
Чтобы писать такой обзор, вам надо было сделать не один серьёзный проект на каждой описываемой CMS, тогда бы он имел бы хоть какой-то смысл.
Какой вам корпоративный сайт? Вам пока даже личный блог поднимать рано. Зачем так позориться?
И ведь такое ощущение, что немало таких людей, всерьёз лезут делать сайты своих фирм, а то даже за деньги предлагают свои «услуги». Не получится, какая бы не была CMS, у далёкого от сайтостроения человека вот так с ходу, сделать на ней хороший сайт. Да и у человека хоть что-то понимающего, не разобравшись с конкретным инструментом не получится.
Чтобы писать такой обзор, вам надо было сделать не один серьёзный проект на каждой описываемой CMS, тогда бы он имел бы хоть какой-то смысл.
Знаете что, завязывайте вы с Денвером. Он или для совсем уж примитивных вещей, или для тех, кто понимает, что делает и что там внутри происходит. Вы, к примеру, typo3 не смогли поставить именно поэтому, хотя на любой линукс он поставится влет, вы получите готовую удобную админку и Демо-сайт, который вам продемонстрирует базовые возможности Typo3, которых вы ни у одной другой CMS из коробки не найдете.
Серьезно, поставьте себе Debian или Ubuntu в северной верси, без графической оболочки, например, в виртуалбокс, и будет у вас полноценное unix-окружение. Для того, чтобы начать, много знать не понадобится, а ресурсов на тему «как это сделать?» и, особенно, «почему не работает?» для Линукса будет намного больше, чем для Денвера.
Серьезно, поставьте себе Debian или Ubuntu в северной верси, без графической оболочки, например, в виртуалбокс, и будет у вас полноценное unix-окружение. Для того, чтобы начать, много знать не понадобится, а ресурсов на тему «как это сделать?» и, особенно, «почему не работает?» для Линукса будет намного больше, чем для Денвера.
В общем, что автор выбрал не написано. Все системы изучены поверхностно. Лучшая система та, в которой умеете работать.
Плюс, что это за корпоративные сайты, где не рассматриваются платные системы, например bitrix, в России занимает более 50% корпоративного сектора.
Плюс, что это за корпоративные сайты, где не рассматриваются платные системы, например bitrix, в России занимает более 50% корпоративного сектора.
По утверждениям маркетологов Bitrix?
www.cmsmagazine.ru/catalogue/
Лидер — да, 50% и близко не пахнет.
Лидер — да, 50% и близко не пахнет.
Я конечно дико извиняюсь. Но Joomla! в России — это joomlaportal.ru
Команда Joomlaportal.ru является официальной Translation Team в русскоязычном сегменте.
Как и joomlaforum.ru является русскоязычным форумом поддержки.
Команда Joomlaportal.ru является официальной Translation Team в русскоязычном сегменте.
Как и joomlaforum.ru является русскоязычным форумом поддержки.
Бегло пробежав понял, что джумла лучше всех… Нужно ломать стереотипы свои)
По поводу CMS Made Simple.
Создание меню, его не надо создавать оно строится на основание контента.
Вставка меню производится просто {menu} в шаблоне. Это отдельный модуль который поддерживает свои шаблоны и параметры.
FormBuilder очень мощная штука, жаль что у вас не получилось. Возможно накладывается то, что 1.11 довольно свежий релиз и не успели подтянуть модуль. Хотя ошибка возможно в другом, а именно в подтягивание зависимостей. Заметил такую беду в 1.11.
Двузначность реализуется на основе самого контенкта, первый уровень это язык, второй контент. А при вставке меню указывается параметр, что показывать только со второго уровня, а первый где-то отдельно в виде выбора языков. Если интересно могу показать пример сайта, где это реализовано.
Настройка главной страницы, честно не понимаю, почему вас смущает работа с шаблонами только из базы данных? В итоге они все равно обрабатываются смарти, который их кеширует на диске. Да есть небольшое неудобство, но я честно не понимаю утверждения «пригодности к созданию уникальных нешаблонных сайтов».
ЧПУ есть, только включается оно через конфиг, как подробно расписано в /doc/, там же лежит пример .htaccess файла, правда не все модули его хорошо поддерживают, например модуль новостей, который входит в ядро, уж больно криво его поддерживает.
Создание меню, его не надо создавать оно строится на основание контента.
Вставка меню производится просто {menu} в шаблоне. Это отдельный модуль который поддерживает свои шаблоны и параметры.
FormBuilder очень мощная штука, жаль что у вас не получилось. Возможно накладывается то, что 1.11 довольно свежий релиз и не успели подтянуть модуль. Хотя ошибка возможно в другом, а именно в подтягивание зависимостей. Заметил такую беду в 1.11.
Двузначность реализуется на основе самого контенкта, первый уровень это язык, второй контент. А при вставке меню указывается параметр, что показывать только со второго уровня, а первый где-то отдельно в виде выбора языков. Если интересно могу показать пример сайта, где это реализовано.
Настройка главной страницы, честно не понимаю, почему вас смущает работа с шаблонами только из базы данных? В итоге они все равно обрабатываются смарти, который их кеширует на диске. Да есть небольшое неудобство, но я честно не понимаю утверждения «пригодности к созданию уникальных нешаблонных сайтов».
ЧПУ есть, только включается оно через конфиг, как подробно расписано в /doc/, там же лежит пример .htaccess файла, правда не все модули его хорошо поддерживают, например модуль новостей, который входит в ядро, уж больно криво его поддерживает.
Используй Силу(Джангу), Люк.
Тоже встал перед выбором какую СMS использовать. До этого писал только несколько простеньких сайтов, а тут надопортал новостной прикрутить. Нужно было сделать свой шаблон. И вот тут выбор пал на joomla по 2 причинам:
1. Простота создпния своего шаблона
2. Огромное количество информации в интернете
3. Очень много модулей.
Я не любитель использовать сторонние решения, но в данном случае модули очень сильно развязали мне руки, поскольку я все таки любитель, а не професионал.
Так же достаточно легко было докопаться до того как в джумле что-то менять, даже непосредствеено в коде (я имею ввиду внешний вид сайта)
Конечно, есть минусы в joomla (как по мне так она очень раздувает базу), но для человека, знакомого только с html и css (php я знаю только в теории, на практике работал очень мало) joomla — это очень хороший инструмент. По крайней мере у меня разработать свой шаблон под него отняло очень мало времени.
В остальном, я не знаю как в других CMS, но в джумле с модулями управляться достаточно просто (редактирование, изменение визуализации модуля).
Конечно в будущем хотелось бы сесть и написать свой движок, но на данный момент joomla мне понравилась.
По поводу drupal и в часности создания шаблонов под него: я так и не нашел толковой информации в интернете (по крайней мере по 7-рке).
1. Простота создпния своего шаблона
2. Огромное количество информации в интернете
3. Очень много модулей.
Я не любитель использовать сторонние решения, но в данном случае модули очень сильно развязали мне руки, поскольку я все таки любитель, а не професионал.
Так же достаточно легко было докопаться до того как в джумле что-то менять, даже непосредствеено в коде (я имею ввиду внешний вид сайта)
Конечно, есть минусы в joomla (как по мне так она очень раздувает базу), но для человека, знакомого только с html и css (php я знаю только в теории, на практике работал очень мало) joomla — это очень хороший инструмент. По крайней мере у меня разработать свой шаблон под него отняло очень мало времени.
В остальном, я не знаю как в других CMS, но в джумле с модулями управляться достаточно просто (редактирование, изменение визуализации модуля).
Конечно в будущем хотелось бы сесть и написать свой движок, но на данный момент joomla мне понравилась.
По поводу drupal и в часности создания шаблонов под него: я так и не нашел толковой информации в интернете (по крайней мере по 7-рке).
Автор феерически неправ. Другое название для него будет неприличным.
Готовлю к релизу свою CMS
Предлагаю в качестве хорошей альтернативы существующим для создания корпоративных сайтов и небольших статейно-новостных порталов (~ до 50.000 страниц)
1hub.ru/blog/pr/412.html
В настоящее время ищу веб-мастеров, которым будет интересная моя система (одного уже нашел), для дальнейшего создания комьюнити.
Предлагаю в качестве хорошей альтернативы существующим для создания корпоративных сайтов и небольших статейно-новостных порталов (~ до 50.000 страниц)
1hub.ru/blog/pr/412.html
В настоящее время ищу веб-мастеров, которым будет интересная моя система (одного уже нашел), для дальнейшего создания комьюнити.
картинка не нова, но все же… :)
Сделать корпоративный сайт на WordPress — не*й петь, как говорится. Идеальная CMS для этого.
Вот кстати заметка по поводу плагинов мультиязычности.
Вот кстати заметка по поводу плагинов мультиязычности.
Зацените вот эту CMS — railsguides.net/2012/09/24/the-best-content-management-system-cms/ (locomotive CMS)
Если уж задаваться выбором CMS для корпоративного сайта, то как минимум надо было задать следующие вопросы:
— Сколько страниц предполагается на сайте — сразу после запуска и через год?
— Какая тематика?
— Предполагаемая посещаемость?
— Магазин будет или только публикации?
— Предполагаемая целевая аудитория?
Все эти вопросы влияют на выбор CMS.
То есть такие вопросы возможно за кадром себе Вы задавали. Но как на них ответили — в статье ни слова, а ведь в данном случае Ваше мнение строго субъективно. Возможно не из этой семерки надо брать, и бесплатность для корпоративного сайта — не совсем удачный критерий.
— Сколько страниц предполагается на сайте — сразу после запуска и через год?
— Какая тематика?
— Предполагаемая посещаемость?
— Магазин будет или только публикации?
— Предполагаемая целевая аудитория?
Все эти вопросы влияют на выбор CMS.
То есть такие вопросы возможно за кадром себе Вы задавали. Но как на них ответили — в статье ни слова, а ведь в данном случае Ваше мнение строго субъективно. Возможно не из этой семерки надо брать, и бесплатность для корпоративного сайта — не совсем удачный критерий.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Сравнительный анализ CMS: охота на оптимальную систему для создания корпоративных сайтов