Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 209
«Нет никакой возможности поддерживать существующего кошмарного монстра с недоделанным функционалом» — пора бросать его и переходить на Joomla!
Рекомендую обратить внимание на движок Wiki Media. У него есть очень важное преимущество — справляется с огромными нагрузками и быстро генерит страницы. А далее нанимаете программиста и он из этого делает конфетку по вашим требованиям. :)
Проще написать свой движок, нежели сделать из вики что-то удобное в использовании :-)
И кстати это правильно. Потому что открытые движки атакуются постоянно. Просматривая логи, каждый день натыкаюсь на атаки, которые выискивают известные файлы, известных cms на предмет дырок и багов. Я думаю, если бы использовали для своих клиентов известные cms — уже давно бы поломали клиентов, отсюда и репутацию. Я не думаю, что у нашей студийной cms нет дырок, но так как она закрытая — найти их очень тяжело.
Старый добрый миф о надёжности closed source.
Ну почему сразу миф? Факты говорят о противоположном.
Хотя, можно допилить и известные os cms и их использовать, но надо большие ресурсы и провести хороший рефакторинг кода.
Например допилиленный Drupal используют в органах власти США (например яркий пример whitehouse.gov)
Но я думаю там от друпала осталась только задумка архитектуры :)
А обычные студии, используют os cms и в особенности их дополнения без каких либо проверок кода. Поэтому таким студиям лучше использовать cs
Кстати по логам я заметил, что drupal на взлом ищут меньше всего.
И кстати баги и дырки — разные вещи, не всегда можно воспользоваться багом как дыркой в обороне.
Хотя, можно допилить и известные os cms и их использовать, но надо большие ресурсы и провести хороший рефакторинг кода.
Например допилиленный Drupal используют в органах власти США (например яркий пример whitehouse.gov)
Но я думаю там от друпала осталась только задумка архитектуры :)
А обычные студии, используют os cms и в особенности их дополнения без каких либо проверок кода. Поэтому таким студиям лучше использовать cs
Кстати по логам я заметил, что drupal на взлом ищут меньше всего.
И кстати баги и дырки — разные вещи, не всегда можно воспользоваться багом как дыркой в обороне.
Это не миф, на то есть объективные причины:
1. Огромная популярность кода фреймворка по сравнению с конкретным проектом. Т.е. привлекает намного больше внимания, больше людей занимается поиском уязвимостей и выпускает эксплоиты, которыми уже может воспользоваться даже школьник, если ему не понравится конкретный сайт.
2. Поиск багов в коде все-же гораздо проще поиска их с помощью проверок «черного ящика». Есть, конечно, стандартные косяки, но их пропускают только неопытные разработчики, чтобы найти то, что пропустит опытный, очень желательно иметь перед глазами сырцы. С ними будет существенно проще.
1. Огромная популярность кода фреймворка по сравнению с конкретным проектом. Т.е. привлекает намного больше внимания, больше людей занимается поиском уязвимостей и выпускает эксплоиты, которыми уже может воспользоваться даже школьник, если ему не понравится конкретный сайт.
2. Поиск багов в коде все-же гораздо проще поиска их с помощью проверок «черного ящика». Есть, конечно, стандартные косяки, но их пропускают только неопытные разработчики, чтобы найти то, что пропустит опытный, очень желательно иметь перед глазами сырцы. С ними будет существенно проще.
То есть вы вот просто пришли, и сказали что Security through Obscurity рулит?
А мужики-то не знают.
Сообщество Drupal, состоит не только из кодеров, там есть и QA-энтузиасты.
А половина шарашек со своими наколенным CMS, либо не представляют себе необходимость полноценного QA, либо просто не могут его себе позволить.
Закрытый код никогда не будет безопаснее открытого за счёт закрытости.
Но это и не значит, что открытый — априори безопасней.
PS Drupal не юзаю.
А мужики-то не знают.
Сообщество Drupal, состоит не только из кодеров, там есть и QA-энтузиасты.
А половина шарашек со своими наколенным CMS, либо не представляют себе необходимость полноценного QA, либо просто не могут его себе позволить.
Закрытый код никогда не будет безопаснее открытого за счёт закрытости.
Но это и не значит, что открытый — априори безопасней.
PS Drupal не юзаю.
Код может и будет, это логично. Не априори, но в целом, что больше ломают, то лучше и латают, как минимум, известные дырки проще латать.
Но вот конкретный проект не масштабов вконтакте, будет взломан с гораздо меньшей вероятностью, если он сделан толковыми специалистами без использования стороннего кода. В итоге, из идеологических соображений, проект на основе опенсорсного фреймворка/цмс будет безопаснее, а из практических — безопаснее свой код.
Но вот конкретный проект не масштабов вконтакте, будет взломан с гораздо меньшей вероятностью, если он сделан толковыми специалистами без использования стороннего кода. В итоге, из идеологических соображений, проект на основе опенсорсного фреймворка/цмс будет безопаснее, а из практических — безопаснее свой код.
Где эта грань, когда вы «неуловимый джо» с закрытым кодом?
Любой проект хочет расти. И проекты с StO — просто оттягивают свои проблемы на более поздний срок.
Вот мы сейчас с вами возьмем, и just for lulz поломаем maxic его сайты.
Или это сделают его конкуренты. А может и не поломаем, ибо лень.
Нужна методика оценки рисков, в том числе будущих, чтобы быть уверенным в своейненужности безопасности.
Любой проект хочет расти. И проекты с StO — просто оттягивают свои проблемы на более поздний срок.
Вот мы сейчас с вами возьмем, и just for lulz поломаем maxic его сайты.
Или это сделают его конкуренты. А может и не поломаем, ибо лень.
Нужна методика оценки рисков, в том числе будущих, чтобы быть уверенным в своей
По сравнению с аудиторией всех сайтов на том-же Друпале и количеством людей, что хотят их сломать, имея перед глазами сырцы фреймворка, почти все проекты являются такими Джо. Вопрос в другом. Вероятность перейти дорогу кому-то на столько, чтобы для взлома привлекались высококлассные специалисты, очень небольшая. А вот прозевать апдейт и нарваться на школьника, что скачал свежий экплоит, гораздо реальнее.
Взломы крупных проектов чаще идут через открытый софт. Например, сервера украинского партнера icq взломали через phpbb, в котором не накатили какой-то небольшой апдейт и перебор экплоитов привел к обнаружению уязвимости. Тогда как через самописный код в Украине я не слышал, чтобы что-то крупное ломали.
Взломы крупных проектов чаще идут через открытый софт. Например, сервера украинского партнера icq взломали через phpbb, в котором не накатили какой-то небольшой апдейт и перебор экплоитов привел к обнаружению уязвимости. Тогда как через самописный код в Украине я не слышал, чтобы что-то крупное ломали.
Уж лучше Друпал. Джумла для меня — страшный сон. Конечно, может быть всё в корне поменялось в Джумле со времён 1 версии, но «неприятный осадок остался».
Конечно, поменялось. Я друпалом не пользовался, и ничего не имею против него, но, судя по описанному выше, это ужас какой-то. В жумле ничего подобного нет.
Может вы просто не ныряли достаточно глубоко?
«я не знаю как надо — но у вас точно не так...»
Ничего, что Drupal — это CMF и дает гораздо большие возможности? Joomla как бы даже не на одной полке с Drupal.
en.wikipedia.org/wiki/Content_Management_Framework
А составители таблицы и не знали про «гораздо большие возможности». Пичальки-то какие :-(
А составители таблицы и не знали про «гораздо большие возможности». Пичальки-то какие :-(
Туда даже WordPress впихнули, так что составители таблицы местами перегнули палку.
И чем это WordPress не CMF? Вполне себе.
А чем микроскоп не молоток? Вполне себе можно гвозди вбивать.
Не знаю как там в друпале, но в WP если нужно сделать что-то большее чем блог или сайт визитку, например магазин, то нужно нехило все поковырять.
Не знаю как там в друпале, но в WP если нужно сделать что-то большее чем блог или сайт визитку, например магазин, то нужно нехило все поковырять.
Framework он на то и framework чтобы давать инструменты для «ковыряния». Инструментов в WordPress хватает.
Составители таблицы написали «это список систем, утверждающих, что они CMF», хотя на официальном сайте Joomla они честно пишут
en.wikipedia.org/wiki/Drupal
en.wikipedia.org/wiki/Joomla
en.wikipedia.org/wiki/Drupal
Type: Content management framework and Content management system
en.wikipedia.org/wiki/Joomla
Type: Content management system
Давайте реально без фанатства и joomla и drupal — это cms прошлого века.
Они давно не отвечают реалиям. Монстрообразны и неповоротливы.
Нужно действительно отбросить баласт и переходить на новую архитектуру.
Они давно не отвечают реалиям. Монстрообразны и неповоротливы.
Нужно действительно отбросить баласт и переходить на новую архитектуру.
На какую?
Боже, не когда не было такого желания минуснуть…
Вы разработчик? Тогда не надо громких заявлений.
Посмотрите код, архитектуру и всё поймете.
Неужели вы думаете, что я просто так написал коммент.
Я за друпал слежу с самого его рождения, и еще тогда говорил, что некоторые «изыски» архитектуры приведут к не контроллируемым последствиям
Вообще на хабре в последнее время развелось много демагогов, а не действительно IT-шников и разработчиков.
Посмотрите код, архитектуру и всё поймете.
Неужели вы думаете, что я просто так написал коммент.
Я за друпал слежу с самого его рождения, и еще тогда говорил, что некоторые «изыски» архитектуры приведут к не контроллируемым последствиям
Вообще на хабре в последнее время развелось много демагогов, а не действительно IT-шников и разработчиков.
Пастернака не читал, но осуждаю. (с)
joomla — папка с файлами, не более того.
Ну в корне или нет, но поменялось. Joomla, на мой взгляд, особых восторгов не вызывает, но инструмент вполне себе рабочий. И порог вхождения невысокий.
Разрабатывая модули для Joomla все время ловил себя на мысли, что все то же самое можно было бы и более изящно спроектировать. А с другой стороны понятно, что CMS уже в возрасте и в угоду совместимости со старыми расширениями радикально менять архитектуру никто не будет.
Разрабатывая модули для Joomla все время ловил себя на мысли, что все то же самое можно было бы и более изящно спроектировать. А с другой стороны понятно, что CMS уже в возрасте и в угоду совместимости со старыми расширениями радикально менять архитектуру никто не будет.
Лучше бы отечественную разработку поддержали, cogear.ru
В последнее время наметились довольно очевидные признаки того, что можно назвать критическим этапом в развитии Drupal.
Эти самые признаки были явно видны ещё года 3 назад.
Основными на мой взгляд минусами ещё тогда были: архисложный код и весьма непонятный шаблонизатор. (про дыры и баги молчу)
p.s. Да и проектов, базирующихся да на данной CMS по сей день, могу припомнить лишь 1 (cwer.ру).
А как же флибуста\либрусек?
а как же whitehouse.gov?
Я о том, что проектов ооочень мало на данной cms.
Почти полмиллиона сайтов это мало?
Если быть более точным, то ~1% сайтов работает под этой CMS.
По популярности его превосходит только WP (с ~8% сайтов).
У топик стартера как то каша в переводе и подаче материала, в стиле Валерии Ильиничны — «мы все умрем» ;)
Баги — багам рознь. Есть проблемы. В основном, проблемы роста и выбора путей дальнейшего развития. На DrupalCon London об этом был разговор.
— впечатление о DrupalCon London, от участника: drupaler.ru/2011/08/vstrecha_v_chitalkafe
— london2011.drupal.org оф.сайт конференции
так что не нужно тут разводить на пустом месте…
По популярности его превосходит только WP (с ~8% сайтов).
У топик стартера как то каша в переводе и подаче материала, в стиле Валерии Ильиничны — «мы все умрем» ;)
Баги — багам рознь. Есть проблемы. В основном, проблемы роста и выбора путей дальнейшего развития. На DrupalCon London об этом был разговор.
— впечатление о DrupalCon London, от участника: drupaler.ru/2011/08/vstrecha_v_chitalkafe
— london2011.drupal.org оф.сайт конференции
так что не нужно тут разводить на пустом месте…
Ник автора топика заметили?
А что с ним(с ником)?
/me грешным делом подумал, что что-то пропустил и тут самого Buytaert-а перевели :)
/me грешным делом подумал, что что-то пропустил и тут самого Buytaert-а перевели :)
Я о переводчике, он знаменитый «желтушник», есть даже chrome.google.com/webstore/detail/khmmlhdncbdfignflcjnaloehhammcji :)
Я рискую нарваться на минуса, но у Joomla 2.7%
Это ваше личное мнение или есть подтверждающие ссылки?
Ну товарищи пишут на своем сайте и на других сайтах, прямого пруфа не нашел, но видимо основываются на данных по скачиваниям (27 миллионов) и собирают данные по мета-тегам, аналогично по друпалу и вордпресу — прям отдельной статьи с описанием методов подсчета так и не увидел, но будем надеяться что все они нам не врут.
какую подобную по мощности CMS можете посоветовать?
BolgenCMS
Это сравнение автомобиля универсала с автомобилем для гонок.
WP очень хорош для своего круга задач, так же как есть более узко-специализированные CMS/CMF Drupal, по отдельным параметрам.
Из универсальных — Drupal пока один из лучших.
Ну или изобретение своего велика (оно всегда лучше) и быстрее, и надёжнее, и…
My CMS Can Kick Your CMS's Ass © :)
WP очень хорош для своего круга задач, так же как есть более узко-специализированные CMS/CMF Drupal, по отдельным параметрам.
Из универсальных — Drupal пока один из лучших.
Ну или изобретение своего велика (оно всегда лучше) и быстрее, и надёжнее, и…
My CMS Can Kick Your CMS's Ass © :)
Я либо чего-то не понимаю, либо написанное вами вообще никак не вписывается в контекст
— Если друпал так плох, на что перейти?
— Попробуйте WordPress
— (ваш коммент)
— Если друпал так плох, на что перейти?
— Попробуйте WordPress
— (ваш коммент)
Symphony (не путать с фреймворком Symphony)
Symfony же!
В этой прекрасной cms «входной порог» выше. И это тоже по-своему прекрасно.
Можно поинтересоваться с чем возникают основные сложности? (заинтриговали)
Лично у меня сложностей нет. Они могут возникнуть у «веб-мастера», который привык разрабатывать сайт не вылезая за пределы админки CMS.
C Symphony так не получится. Там почти нет готовых решений, но взамен дается почти неограниченная свобода и гибкость. Ну и для того, чтобы хоть как-то начать работать с Symphony, нужно хоть немного знать XSLT :)
C Symphony так не получится. Там почти нет готовых решений, но взамен дается почти неограниченная свобода и гибкость. Ну и для того, чтобы хоть как-то начать работать с Symphony, нужно хоть немного знать XSLT :)
Окей, спрошу по другому: шаблонизатор там сложнее чем в Мадженто?
Я не знаю какой шаблонизатор в Мадженто. Тут система отдает данные в XML, а вы в XSLT шаблонах делаете с ними что хотите. То есть XSLT и есть шаблонизатор. Это сложнее чем в Мадженто?
Ну в Мадженто что-то похожее, тоже на XML базируется, мне кажется у них там какое-то адаптированное решение используется, я не стал разбираться.
Мне там дико нравится шаблонизатор, хотя организован он в ранних версия (<1.4) был довольно запутанно, много логики было захардкожено, но интеграция со своим дизайном была всё-равно крайне не сложной.
Мне там дико нравится шаблонизатор, хотя организован он в ранних версия (<1.4) был довольно запутанно, много логики было захардкожено, но интеграция со своим дизайном была всё-равно крайне не сложной.
XML/XSLT там шаблонизатор, в Magento вроде native PHP и XML для логической разметки. Что сложнее, имхо, сложно сказать — первое чисто декларативное, второе гибридное. Наверное от предыдущего опыта зависит.
MODx
Я думаю, MODx или TYPO3. Как и Drupal, следуют философии «CMF с CMS надстройкой».
Возможно удивитесь — www.whitehouse.gov, я лично удивлен был.
Вот вам, и это некоторые русско-язычные www.drupal.ru/node/66640
а как же dev.twitter.com?
А зачем распыляться и начинать делать drupal 8, если 7 ещё не готов?
Это грустно. Мне очень нравится Drupal.
RIP?
Fork
а смысл говнокод форкать?
шестая версия мне нравилась и даже очень
Не всегда то, что красиво обладает достаточной гибкостью и изящностью внутри. Имхо, это бич многих коммюнити-проектов. В погоне за новыми плюшками и свистелками проект трещит по швам и громко плачет о рефакторинге, а мышки продолжают есть кактус.
До сих пор пользуюсь для своего сайта — пробовал семерку — не то…
А на что сваливать то?
WordPress совсем неплох. И, вопреки пропаганде, не так уж прожорлив. И баги в нем находят не часто.
Поддерживаю Wordpress, За всю его историю он так не печалил, как та же Joomla. Думал изучить Drupal но теперь понимаю, что лучше дальше работать с WP и не разбегаться. А на счет прожорливости, может так оно и есть в стоковом состоянии, но тут уже вопрос оптимизации, лучше потратить время и усилия на оптимизацию WP чем латать дыры в других системах.
Развитие Joomla радует в последнее время
Вордпресс не сравнится с Друпалом по функциональности, да и сравнивать их не корректно.
Вордпресс — это ветка на дереве.
Друпал — это дерево со множеством веток.
Вордпресс — это ветка на дереве.
Друпал — это дерево со множеством веток.
Хм… возможно. Но не могли бы вы для наглядности привести пример того, что можно сделать на Drupal и чего нельзя сделать на WordPress? Подсказка — форум, галерею и интернет-магазин сделать можно.
Пример:
1. Личные профили пользователей с возможность указания различной информации о себе (ник, аськи и тд). Все это без доступа к админке. Личные сообщения.
2. Разграничение доступа пользователей к различным функциями, разделам, страницам.
3. Возможность создания своих типов материалов со своими полями.
4. Визуальное составление запросов к бд (модуль Views).
5. Автоматизация всего что можно. Начиная от автоматической переименовании файлов (для изображений — генерация alt, title и т.д.) и заканчивая автоматическим обновлением переводов.
6. Нет никаких ограничений (категорий — какая угодна вложенность, урл страницы — какой угодно и меняться очень просто и т.д.)
Я два года работал с ВП и ушел с него из-за низкой функциональности. С Друпалом я ни в чем не ограничен.
1. Личные профили пользователей с возможность указания различной информации о себе (ник, аськи и тд). Все это без доступа к админке. Личные сообщения.
2. Разграничение доступа пользователей к различным функциями, разделам, страницам.
3. Возможность создания своих типов материалов со своими полями.
4. Визуальное составление запросов к бд (модуль Views).
5. Автоматизация всего что можно. Начиная от автоматической переименовании файлов (для изображений — генерация alt, title и т.д.) и заканчивая автоматическим обновлением переводов.
6. Нет никаких ограничений (категорий — какая угодна вложенность, урл страницы — какой угодно и меняться очень просто и т.д.)
Я два года работал с ВП и ушел с него из-за низкой функциональности. С Друпалом я ни в чем не ограничен.
Интересно. Ок, я готов допустить, что пункт 1 может где-то пригодиться. Но вот польза от 2-5 весьма и весьма сомнительна, а на счет 6 вы вовсе заблуждаетесь. Если бы это действительно было кому-то нужно, уже были готовые плагины. Или уже есть.
Мне кажется, большинству пользователей мало интересно, умеет движок визуально составлять запросы или не умеет. Их куда сильнее интересует легкость установки и обновления, выбора тем и плагинов, стабильность и безопасность движка. Вот почему на WordPress работают 8.5% всех сайтов в интернете, а на Drupal — лишь 1%.
Мне кажется (судя по вашим требованиям к гибкости движка), у вас отношение к Drupal, как к веб-фреймфорку, а не как к CMS. Но ведь есть много прекрасных веб-фреймворков. Например, Zend, Mojolicious, Catalyst, Django.
Мне кажется, большинству пользователей мало интересно, умеет движок визуально составлять запросы или не умеет. Их куда сильнее интересует легкость установки и обновления, выбора тем и плагинов, стабильность и безопасность движка. Вот почему на WordPress работают 8.5% всех сайтов в интернете, а на Drupal — лишь 1%.
Мне кажется (судя по вашим требованиям к гибкости движка), у вас отношение к Drupal, как к веб-фреймфорку, а не как к CMS. Но ведь есть много прекрасных веб-фреймворков. Например, Zend, Mojolicious, Catalyst, Django.
Ок, подскажите, как в WP разделить контент на части? Допустим я делаю сайт про автомобили, в котором есть общая лента новостей, из которой надо делать выборки по какой-либо марке.
Т.е. я захожу на страницу марки, в ней вижу меню по этой марке, в этом меню должен быть пункт «новости», кликнув на котором я должен видеть новости по этой марке.
Управляться все это должно из админки ворпдресса. Для меня это пока загадка, т.к. гуй управления меню не позволяет добавлять пересечения, а только все новости. А если добавлять в него типа как произвольную ссылку а-ля /category/subcategory, то он ее не подсвечивает как активную.
Т.е. я захожу на страницу марки, в ней вижу меню по этой марке, в этом меню должен быть пункт «новости», кликнув на котором я должен видеть новости по этой марке.
Управляться все это должно из админки ворпдресса. Для меня это пока загадка, т.к. гуй управления меню не позволяет добавлять пересечения, а только все новости. А если добавлять в него типа как произвольную ссылку а-ля /category/subcategory, то он ее не подсвечивает как активную.
Не уверен, что до конца понял ваш вопрос, но по-моему с этой задачей с легкостью справятся рубрики и метки. Не подсвечивает не WordPress, а используемый вами шаблон. По шаблонам есть прекрасная документация, так что добавить подсветку любому более-менее опытному PHP программисту не должно составлять труда.
WordPress, блогодвижок, смысла затыкать им другие дырки?
Drupal CMS\CMF более широкого профиля.
У 2 движков, 2 разные цели.
Drupal CMS\CMF более широкого профиля.
У 2 движков, 2 разные цели.
Нене, вы не поняли. В меню Ворпдресса из админки нельзя добавить пересечение, например рубрики и тега. Если вставлять его как ссылку, то эта ссылка не будет подсвечиваться в меню, ей просто не назначаются нужные css классы. Поэтому приходится городить костыли.
Хочется простого, в редакторе меню вставить что-то вроде «все новости по рубрике А». Если подскажете, как это делать без костылей — буду благодарен.
Хочется простого, в редакторе меню вставить что-то вроде «все новости по рубрике А». Если подскажете, как это делать без костылей — буду благодарен.
Обычный пользователь, возможно, и не сможет самостоятельно воспользоваться всеми средствами для создания относительно сложного сайта на Drupal. Но всё что перечислено, реально используется разработчиками.
Я сделал не один десяток сайтов на drupal, еще начиная с drupal 4.x, и всё перечисленное реально используется, и многое другое, разумеется, и свои модули дописываются, чтобы достичь желаемого результата.
Я сделал не один десяток сайтов на drupal, еще начиная с drupal 4.x, и всё перечисленное реально используется, и многое другое, разумеется, и свои модули дописываются, чтобы достичь желаемого результата.
2) Разграничение прав не сомнительно, когда у вас 1(10) обычных блогера на сайте. А когда материал готовит несколько человек и каждый отвечает за свою часть…
3) Свои типы материалов со своими полями — если вам это смнительно, то возможно вы не видели проектов с функционалом больше блога/форума
По поводу Token-ов, таксономии, платёжных шлюзов практически ко всему, панелей, cpools, модуля фич, картографических, погодных сервисов, интеграции со сторонними базами и т.д.
Было бы интересно пообщаться со специалистами в WP попробовать поискать аналоги для WP. Наверняка они есть.
Drupal можно как CMS и как фреймворк использовать. Многие далеки от PHP кодинга, ставят и прекрасно работают с движком как CMS.
3) Свои типы материалов со своими полями — если вам это смнительно, то возможно вы не видели проектов с функционалом больше блога/форума
По поводу Token-ов, таксономии, платёжных шлюзов практически ко всему, панелей, cpools, модуля фич, картографических, погодных сервисов, интеграции со сторонними базами и т.д.
Было бы интересно пообщаться со специалистами в WP попробовать поискать аналоги для WP. Наверняка они есть.
Drupal можно как CMS и как фреймворк использовать. Многие далеки от PHP кодинга, ставят и прекрасно работают с движком как CMS.
Извините, я вы представляете себе хабр без 1 пункта? Без профилей пользователей?
Что же вы за сайты такие делаете, где не требуются нормальные профили пользователей? Только блоги? Даже для сайта визитки и то они требуются. Один для админа, другой для секретарши для обновления материалов (с ограничением доступа к системным настройкам).
Приведу небольшую задачку, скажите пожалуйста как это можно сделать на WP:
1. Нужны новости, в которых отдельным полем стоит Источник (для ссылки на источник новости, текст для ссылки «Источник», для ссылки автоматом прописывается rel=«nofollow». Адрес страниц для новостей: news/название_новости_транслитом. На главной новости выводится в центре страницы.
2. Статьи. Адрес для статей: articles/название_страницы_транслитом. На сайте выводится в левом сайдбаре список из 5 последних статей с датами.
3. Товар. Содержит поля Размер и Цена. Адрес страниц для товара: products/название_товара_транслитом. На сайте выводится в правом сайдбаре список из самых дорогих товаров, отсортированных по убыванию. Название товара — ссылка на страницу с описанием товара.
Как это сделать на Wordpress?
Что же вы за сайты такие делаете, где не требуются нормальные профили пользователей? Только блоги? Даже для сайта визитки и то они требуются. Один для админа, другой для секретарши для обновления материалов (с ограничением доступа к системным настройкам).
Приведу небольшую задачку, скажите пожалуйста как это можно сделать на WP:
1. Нужны новости, в которых отдельным полем стоит Источник (для ссылки на источник новости, текст для ссылки «Источник», для ссылки автоматом прописывается rel=«nofollow». Адрес страниц для новостей: news/название_новости_транслитом. На главной новости выводится в центре страницы.
2. Статьи. Адрес для статей: articles/название_страницы_транслитом. На сайте выводится в левом сайдбаре список из 5 последних статей с датами.
3. Товар. Содержит поля Размер и Цена. Адрес страниц для товара: products/название_товара_транслитом. На сайте выводится в правом сайдбаре список из самых дорогих товаров, отсортированных по убыванию. Название товара — ссылка на страницу с описанием товара.
Как это сделать на Wordpress?
Создаем 3 рубрики — Новости, Статьи, Товар. Прописываем им slug — news, articles, products. Настраиваем ЧПУ — %category%/%postname%.
Придумываем название «произвольного поля» (вспомнил, что они все-таки есть в WP) для указания источника новости. Пусть будет «Цена». Затем — для товаров. Пусть будет «Размер» и «Цена». Подробности — codex.wordpress.org/Custom_Fields
Остается поправить шаблон, чтобы в «ленте» он выводил только новости, или поставить соответствующий плагин (точно есть, сам пользовался). На счет виджетов — также можно поправить код шаблона или воспользоваться плагинами.
Наконец, правим код шаблона, чтобы при просмотре товара выводил размер и цену, а при просмотре новости — источник с rel=nofollow.
Придумываем название «произвольного поля» (вспомнил, что они все-таки есть в WP) для указания источника новости. Пусть будет «Цена». Затем — для товаров. Пусть будет «Размер» и «Цена». Подробности — codex.wordpress.org/Custom_Fields
Остается поправить шаблон, чтобы в «ленте» он выводил только новости, или поставить соответствующий плагин (точно есть, сам пользовался). На счет виджетов — также можно поправить код шаблона или воспользоваться плагинами.
Наконец, правим код шаблона, чтобы при просмотре товара выводил размер и цену, а при просмотре новости — источник с rel=nofollow.
>Мне кажется (судя по вашим требованиям к гибкости движка), у вас отношение к Drupal, как к веб-фреймфорку, а не как к CMS.
Так он и позиционируется как, грубо говоря, фреймворк с админкой — множество задач можно сделать из админки, а меньшую часть (либо оптимизацию того, что изначально в админке нарисовали) — кодом. Отчасти, я думаю, низкая (относительно) популярность друпала из-за того, что «из коробки» можно сделать очень много (одна только настройка прав пользователей чего стоит) и неопытного пользователя это отпугивает.
Так он и позиционируется как, грубо говоря, фреймворк с админкой — множество задач можно сделать из админки, а меньшую часть (либо оптимизацию того, что изначально в админке нарисовали) — кодом. Отчасти, я думаю, низкая (относительно) популярность друпала из-за того, что «из коробки» можно сделать очень много (одна только настройка прав пользователей чего стоит) и неопытного пользователя это отпугивает.
3. Возможность создания своих типов материалов со своими полями. — легко и непринужденно с помощью MagicFields либо специализированных плагинов.
Кое-что из этого можно реализовать при помощи плагина BuddyPress, хотя вроде бы и у него косяки есть.
Господа, wordpress давно перестал быть движком для блогов only)
Сейчас это такой же конструктор, как и drupal, но с гораздо более удобным интерфейсом. Так же как и в Drupal, все проблемы решаются подключением соответствующих модулей (в вордпрессе — плагинов).
А поэтому все вышеперечисленные задачи на нем решаются, да, вплоть до составления запросов к БД. Любые типы контента (с любыми типами полей) создаются визуально (см. podscms.com). и тд. и т.п.
Посему непонятны минусы на каждом комменте с упоминанием слова 'wordpress'
Сейчас это такой же конструктор, как и drupal, но с гораздо более удобным интерфейсом. Так же как и в Drupal, все проблемы решаются подключением соответствующих модулей (в вордпрессе — плагинов).
А поэтому все вышеперечисленные задачи на нем решаются, да, вплоть до составления запросов к БД. Любые типы контента (с любыми типами полей) создаются визуально (см. podscms.com). и тд. и т.п.
Посему непонятны минусы на каждом комменте с упоминанием слова 'wordpress'
WP поддерживает нормальную реализацию многопользовательности? Без доступа в админку?
Разве в WP можно создавать свои типы контента?
Разве в WP можно создавать свои типы контента?
1. Многопользовательность есть из коробки, с минимальной функциональностью. Дополнительная функциональность, а именно всякие личные кабинеты, личные сообщения, и прочее решается соответствующими модулями
2. Можно, называется Custom Post Types + Custom Taxonomy, гугл в помощь. Помимо этого есть и соотв. плагины, которые позволяют визуально конструировать контент и задавать правила для отображения.
2. Можно, называется Custom Post Types + Custom Taxonomy, гугл в помощь. Помимо этого есть и соотв. плагины, которые позволяют визуально конструировать контент и задавать правила для отображения.
В WordPress есть аналоги cck и views? Если не в теме: cck — модуль для создания новых типов документов с различными полями (например, статья, товар, сотрудник, мероприятие и т. д.), а views — модуль для создания список документов (например, таблица сотрудников с фио, телефоном и должностью, отсортированная по фио и фильтром по отделу).
В WP есть возможность делать разные cck и views. kovshenin.com/archives/custom-post-types-in-wordpress-3-0/ для начала. Второе можно делать через шаблоны страниц. Можно наделать кучу шаблонов и юзать их, привязывая шаблон к посту, списку постов или странице…
Судя по ссылке и небольшому гуглению, «custom post types» и списки на их основе создаются программистами на PHP (http://codex.wordpress.org/Post_Types). Для views есть какой-то аналог wordpress.org/extend/plugins/virtual-pages/, но судя по скринам, на нём не получится сделать даже пример который я привёл (таблица сотрудников).
Ну да, вы в теме программируете нужные типы постов, с их полями. Для любой страницы, рубрики, тега (и т.д.) вы можете назначить свой собственный шаблон, например сделать шаблон «список сотрудников» и повесить его на страницу /peoples. Это совсем не проблема.
Но делается все для конкретной темы и на жуткой смеси из php+html.
Но делается все для конкретной темы и на жуткой смеси из php+html.
Есть аналог, плагин podscms. Визуально можно конструировать любые типы контента и правила для отображения.
Еще года полтора назад делал с его помошью archtour.ru)
Еще года полтора назад делал с его помошью archtour.ru)
Банально, сделать разные меню для разных частей сайта. Что бы не фигачить стопицот отдельных шаблонов.
typo3
Если вы программист — проанализируйте архитектуры разных, и выбирите по душе ;)
В первую очередь я бы посоветовал новые простые и универсальные решения, где нет разного плана привязок к выполнению и порядку кода. Где всем заведует контроллер (который сам по себе должен быть простым до безобразия), который не обрабатывает данные и понятия не знает про вывод, где нет тупых шаблонизаторов. Где нет разделения понятия модуля на еще, дополнения, виджеты, плугинсы. Все разделения усложняют архитектуру. Поверьте все это можно сделать одним понятием модуль, если сделать все согласно MVC, но не нативным способом, которым многие грешат.
В первую очередь смотрите не на админку а на архитектуру.
Потому что в красивую обвертку могут запаковать не конфетку а г.
В первую очередь я бы посоветовал новые простые и универсальные решения, где нет разного плана привязок к выполнению и порядку кода. Где всем заведует контроллер (который сам по себе должен быть простым до безобразия), который не обрабатывает данные и понятия не знает про вывод, где нет тупых шаблонизаторов. Где нет разделения понятия модуля на еще, дополнения, виджеты, плугинсы. Все разделения усложняют архитектуру. Поверьте все это можно сделать одним понятием модуль, если сделать все согласно MVC, но не нативным способом, которым многие грешат.
В первую очередь смотрите не на админку а на архитектуру.
Потому что в красивую обвертку могут запаковать не конфетку а г.
Мда. А вот в некоторых соседних топиках почему-то при одном упоминании слова Битрикс люди оставляют комменты в духе «Зачем это говно, если есть Друпал?».
Все познается в сравнении :)
Да, меня вот любое проявление PHP-шной кухни пугает, хотя когда-то много писал на нем.
И на чем же пишете? Чем пхп не устроил?
Python. Еще пробовал Ruby, но у него по субъектиным причинам не понравился синтаксис.
Большинство современных решений для веба на Python крайне приятны и архитектурно красивы, в их исходниках копаться просто приятно.
Скорость разработки вскоре после перехода у меня увеличилась в несколько раз (речь идет о django, twisted и tornado), количество возникающих багов существенно снизилось. на основе Django есть 3-4 приличных CMS которых вполне хватит для разработки без кодинга.
PHP изначально был продвинутым шаблонизатором, и это очень болезненно отразилось на его дальнейшем развитии и архитектуре большинства приложений.
Большинство современных решений для веба на Python крайне приятны и архитектурно красивы, в их исходниках копаться просто приятно.
Скорость разработки вскоре после перехода у меня увеличилась в несколько раз (речь идет о django, twisted и tornado), количество возникающих багов существенно снизилось. на основе Django есть 3-4 приличных CMS которых вполне хватит для разработки без кодинга.
PHP изначально был продвинутым шаблонизатором, и это очень болезненно отразилось на его дальнейшем развитии и архитектуре большинства приложений.
Вы просто не видели исходников Битрикса, там нечто.
Друпал по качеству кода много кого превосходит.
Друпал по качеству кода много кого превосходит.
drupal.org/project/standard Page Not Found
На мой взгляд, одна из его проблем это то, что он лишь в последних версиях стал использовать ООП. В процедурно-ориентированной программе гораздо больше поводов для дублирования кода.
Не знал, что всё настолько печально…
Умирает основной конкурент MODx-а?
не дождетесь! :)
Да и не хотелось бы)))
Конкуренция — стимул прогресса
Конкуренция — стимул прогресса
В какой нише конкуренты?
Или вы хотите меня рассмешить социальной сетью на ModX?
Или вы хотите меня рассмешить социальной сетью на ModX?
А разве на Друпале только соц. сети делают?
Хорошо.
Давайте просто: «В какой нише конкуренты?»
Давайте просто: «В какой нише конкуренты?»
1. Обычный сайт обычной компании. Думаю самое распространенное применение CMS. Этого мало?
2. Информационный портал (статьи, комментарии, регистрация, профиль...).
3. Блог на Друпале можно сделать? Думаю да.
4. Интернет-магазин. С этим пока туговато, но есть решения и на Drupal и на MODX.
Так что я бы не сказал, что Drupal и MODX занимают какую-то нишь.
2. Информационный портал (статьи, комментарии, регистрация, профиль...).
3. Блог на Друпале можно сделать? Думаю да.
4. Интернет-магазин. С этим пока туговато, но есть решения и на Drupal и на MODX.
Так что я бы не сказал, что Drupal и MODX занимают какую-то нишь.
В нише фреймворков.
И могу точно сказать, что и социалку можно замутить на нем при желании.
И могу точно сказать, что и социалку можно замутить на нем при желании.
UPD: перечитал еще раз оба перевода. На мой взгляд, перевод от graker более близок к тексту оригинала.
а вот еще и продолжение
Советую не отвечать на комментарии WP-ников, которые не имеют понятия о том, что такое друпал и для чего его применяют. Половину того сложного, что в Drupal делается легко, в WP либо сделать вообще нельзя, либо нужно быть php-программистом с опытом.
Переходим на Битрикс.
Ха. Ха. Ха.
Ха. Ха. Ха.
пфф… много паники. Использую drupal 7 и ничего страшного не встречал.
Люди, переходите на фреймворки. Друпал довольно тормознутая вещь.
Для сайтов визиток довольно хорош MODx.
На друпале овердофига народу делают проекты, поэтому и находят там баги, под друпал в основном клепают профи, в отличии от джумлы с их школомонстрами, которые никаких багов не найдут никогда. Друпал — хорошая cms, в ней много модулей, чтобы ни понадобилось, практически всё можно найти в нем. Кататься на велосипедах можно с удовольствием.
p/s Сам делаю все сайты на cmsmadesimple, новая cms, с хорошей архитектурой, легкой в разработке, удобной в работе. Всем советую. Но модулей маловато, конечно, но в таком случае я их пилю сам за отдельную плату (если речь идет о сайтах на заказ).
p/s Сам делаю все сайты на cmsmadesimple, новая cms, с хорошей архитектурой, легкой в разработке, удобной в работе. Всем советую. Но модулей маловато, конечно, но в таком случае я их пилю сам за отдельную плату (если речь идет о сайтах на заказ).
ну вот я собирался на днях поковырять Drupal. Видать придется отговаривать заказчика)
посоветуйте CMS для разработки инет.Магазина? кроме Битрекса и hostcms цены у них не подходят.
посоветуйте CMS для разработки инет.Магазина? кроме Битрекса и hostcms цены у них не подходят.
Сейчас вам насоветую WP и ModX
ну WP не совсем подходит для инет.Магазина, а с ModX я не работал. вот нашел www.phpshop.ru/ кто что может сказать про эту систему?
Для интернет магазина я бы точно выбрал Magento
Drupal большой!
Drupal must be going ahead
Как мило, любой кто тут заикается о другой CMS попадает сразу в минуса. Видимо сильно тут сообщество друпальщиков )
Я вот скажем сейчас немного удалился от CMS в сторону фреймворков, работаю в последнее время с Yii, все конечно просто. удобно и замечательно, но тут уже и проекты другие (сайт визитку за 10 000 под ключ на фрилансе делать не будешь) и порог вхождения не такой как у CMS при работе в админке.
Я вот скажем сейчас немного удалился от CMS в сторону фреймворков, работаю в последнее время с Yii, все конечно просто. удобно и замечательно, но тут уже и проекты другие (сайт визитку за 10 000 под ключ на фрилансе делать не будешь) и порог вхождения не такой как у CMS при работе в админке.
Статистические даннный в статье приведены верно, но на практике при работе с друпалом №7 проблем нету
Аргументы:
На семерку наша команда (20 программистов) перешли с марта
Проекты — от тысячи часов (отнюдь не клепание визиток)
Разработка идет довольно линейно, нерешаемых проблем нет, на баги ядра натыкаемся редко (от чего немного скучно, так как коммитов на друпал-орг ой как хочется наколлекционировать)
Вывод:
Друпал рулит!
P.S. Всех с наступающим Днем Программиста! :)
Аргументы:
На семерку наша команда (20 программистов) перешли с марта
Проекты — от тысячи часов (отнюдь не клепание визиток)
Разработка идет довольно линейно, нерешаемых проблем нет, на баги ядра натыкаемся редко (от чего немного скучно, так как коммитов на друпал-орг ой как хочется наколлекционировать)
Вывод:
Друпал рулит!
P.S. Всех с наступающим Днем Программиста! :)
За три тысяч рублей и пару дней как раз на Друпал можно сделать. На Джумле или Вордпрессе день максимум :)
Клиенты довольны, всё что им нужно на сайте есть, в «их» админке нет ничего лишнего, оперируют в ней терминами своей предметной области (собственно больше всего времени и занимает создание материалов, соответствующих предметной области, плюс создание таксономии, плюс создание темы из вёрстки — темизация в друпале не самая удачная, имхо), а не страницами (страницы обычно тоже остаются) или, тем более, нодами.
Да уж, но самое интересное, что после этих парудней писателей сайтов, клиенты возвращаются к нам обратно и платят больше и шире сотрудничество становится. И по рекомендациям этих клиентов приходят гораздо больше новых клиентов :)
Спасибо за ваши кривосайты за 3000 товарищи парудней писатели :)
Спасибо за ваши кривосайты за 3000 товарищи парудней писатели :)
С версии Joomla 1.7 имеет свою платформу, отдельную от движка.
Описание: docs.joomla.org/Platform/11.1
Joomla Platform on Github: github.com/joomla/joomla-platform
С версии 1.0 до версии 1.7 очень много сделано.
Версия 1.5 написана с нуля, как и версия 1.6.
Обновление промежуточных версий теперь проходит каждые 6 месяцев с простім обновлением в один клик через Менеджер обновлений в административной части сайта. Эти версии называются «короткострочными» и дают возможность посмотреть какой будет функционал в «долгострочных» версиях.
«Долгострочные» версии обновляются каждые 18 месяцев.
С версии 1.6 переход на будущие «короткострочные» или «долгострочные» версии проходит без проблем, через обновление системы.
С версии 1.6 убита поддержка старой версии 1.0 в режиме совместимости, которая была в 1.6, что ускорило систему в разы.
Вообще если сравнивать сами версии (1.0, 1.5, 1.6/1.7), то ощущения того, что работаешь на разных движках — это хорошая позиция следить за развитием сегодняшнего веба и давать возможности использовать нововведения уже сейчас в самом движке.
С версии 1.7 Joomla плотно работает с поддержкой html5.
После «долгострочной» версии версии 1.5, следующая версия 1.8 (возможно, что версия будет изменена на 2.5 или 3.5 — об этом можно почитать здесь community.joomla.org/blogs/leadership/1479-the-version-votes-are-in.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+JoomlaCommunityCoreTeamBlog+%28Joomla!+Core+Team+Blog%29 и в других статьях) выйдет в начале 2012 года.
В середине 2012 года поддержка версии 1.5 прекращается, что дает системе новый виток в новом развитии. Как самой системе так и разработчикам расширений.
Описание: docs.joomla.org/Platform/11.1
Joomla Platform on Github: github.com/joomla/joomla-platform
С версии 1.0 до версии 1.7 очень много сделано.
Версия 1.5 написана с нуля, как и версия 1.6.
Обновление промежуточных версий теперь проходит каждые 6 месяцев с простім обновлением в один клик через Менеджер обновлений в административной части сайта. Эти версии называются «короткострочными» и дают возможность посмотреть какой будет функционал в «долгострочных» версиях.
«Долгострочные» версии обновляются каждые 18 месяцев.
С версии 1.6 переход на будущие «короткострочные» или «долгострочные» версии проходит без проблем, через обновление системы.
С версии 1.6 убита поддержка старой версии 1.0 в режиме совместимости, которая была в 1.6, что ускорило систему в разы.
Вообще если сравнивать сами версии (1.0, 1.5, 1.6/1.7), то ощущения того, что работаешь на разных движках — это хорошая позиция следить за развитием сегодняшнего веба и давать возможности использовать нововведения уже сейчас в самом движке.
С версии 1.7 Joomla плотно работает с поддержкой html5.
После «долгострочной» версии версии 1.5, следующая версия 1.8 (возможно, что версия будет изменена на 2.5 или 3.5 — об этом можно почитать здесь community.joomla.org/blogs/leadership/1479-the-version-votes-are-in.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+JoomlaCommunityCoreTeamBlog+%28Joomla!+Core+Team+Blog%29 и в других статьях) выйдет в начале 2012 года.
В середине 2012 года поддержка версии 1.5 прекращается, что дает системе новый виток в новом развитии. Как самой системе так и разработчикам расширений.
В 1.7 есть распределение прав пользователей ACL.
На счет категорий нет понятий как раздел и категория (версия 1.0 и 1.5), присутствует вложенность категорий.
Все компоненты, плагины, модули имеют персональные настройки ACL, которые наследуют права из общей конфигурации системы.
Очень просто реализовано построение шаблонов через MVC.
От себя: Недостаток, как по мне — использование Mootools, хотя мне по душе JQuery, который и использую в разработке интерфейса сайта (я не сторонник взять готовый шаблон и переделать его, полностью сам делаю дизайн, верстку, коддинг и не только под Joomla).
На счет категорий нет понятий как раздел и категория (версия 1.0 и 1.5), присутствует вложенность категорий.
Все компоненты, плагины, модули имеют персональные настройки ACL, которые наследуют права из общей конфигурации системы.
Очень просто реализовано построение шаблонов через MVC.
От себя: Недостаток, как по мне — использование Mootools, хотя мне по душе JQuery, который и использую в разработке интерфейса сайта (я не сторонник взять готовый шаблон и переделать его, полностью сам делаю дизайн, верстку, коддинг и не только под Joomla).
В предложении:
«С версии 1.6 убита поддержка старой версии 1.0 в режиме совместимости, которая была в 1.6, что ускорило систему в разы.»
Я сделал ошибку — не которая была в 1.6, а которая была в 1.5
«С версии 1.6 убита поддержка старой версии 1.0 в режиме совместимости, которая была в 1.6, что ускорило систему в разы.»
Я сделал ошибку — не которая была в 1.6, а которая была в 1.5
> С версии 1.7 Joomla плотно работает с поддержкой html5
Без обид joomla сообществу, я видел все версии, действительно сильно изменился код, но…
Вы извините, какая хрен разница ядру с чем работает модуль вывода (он и знать не должен об этом). Зачем переписывать ядро, если за вывод должен отвечать модуль, а?
Ну выпустите модуль вывода работающий с html5, да хоть с html100.
Это и есть основная ошибка многих cms — как я её называю «нативная поддержка MVC», а просто если сказать — нет там никакого mvc. Поэтому и переписывается ядро с нуля от подверсии к подверсии. Потому что понимают что в королевстве что-то не то, а что до сих пор понять не могуи, потому что, по честному, архитектурщики joomla очень слабые. Писать красивый код, еще не значит разрабатывать красивую архитектуру.
Без обид joomla сообществу, я видел все версии, действительно сильно изменился код, но…
Вы извините, какая хрен разница ядру с чем работает модуль вывода (он и знать не должен об этом). Зачем переписывать ядро, если за вывод должен отвечать модуль, а?
Ну выпустите модуль вывода работающий с html5, да хоть с html100.
Это и есть основная ошибка многих cms — как я её называю «нативная поддержка MVC», а просто если сказать — нет там никакого mvc. Поэтому и переписывается ядро с нуля от подверсии к подверсии. Потому что понимают что в королевстве что-то не то, а что до сих пор понять не могуи, потому что, по честному, архитектурщики joomla очень слабые. Писать красивый код, еще не значит разрабатывать красивую архитектуру.
Знаете, почитал комментарии… Здесь каждый тянет одеяло в сторону того, к чему привык, с чем знаком и что приятнее (по каким-то личным соображениям). На самом деле же, со статистикой, приведенной в топике, спорить глупо. Откройте друпал.орг и убедитесь. Друпал становится все страшнее и страшнее. Я лично в этом убеждаюсь каждый раз, когда приступаю к новому проекту, обновляя систему. Но что делать, если времени нет на написание собственного универсального движка? Куда уйти, куда податься? Да некуда, потому, как подобного в свободном доступе нет. Сам отюзал и джумлу (с дико корявым интерфейсом админки), и вордпресс (с жутко ограниченным функционалом), и кучу других «готовых универсальных решений», но вынужден был остановиться на друпал. Пользуюсь 6.22. Удовлетворен. Мне, как дизайнеру, маловажен код. Мне главное то, что я вижу. Джумла предлагает множество готовых «тем», которые симпатичны и уже предварительно протестированы, в вордпресс также многое уже «подключ», на друпале же я начинаю верстать все с нуля, что дает мне больше возможностей для фантазии. Для меня — это в приоритете, для кого-то — другое. Здесь нет «универсальной» пилюли. Каждому своё — простая, банальная истина.
Чтобы сделать дизайн не нужно привязываться к движку!
Для дизайнера — это глупо и такое писать должно быть стыдно.
В дизайне нужно руководиться композицией, колористикой, типографикой, понимать сегодняшнии тенденции, знать что было в других стилистиках, периодах, течениях…
Дизайнер понимает, что такое дизайн и чем нужно руководиться в создании своего детища и воплощения всевозможных фантазий.
Для дизайнера — это глупо и такое писать должно быть стыдно.
В дизайне нужно руководиться композицией, колористикой, типографикой, понимать сегодняшнии тенденции, знать что было в других стилистиках, периодах, течениях…
Дизайнер понимает, что такое дизайн и чем нужно руководиться в создании своего детища и воплощения всевозможных фантазий.
Веб-дизайн уже давно перестал быть только цветовой гаммой, набором графических элементов и т.д. Веб-дизайн сейчас — это идея, концепция подачи информации. А тут уж как не крути, функционал и строение системы очень важны.
Веб-дизайн сейчас — это идея, концепция подачи информации.
Ты описал, что такое дизайн, но где тут движок?
Идея и концепция — это одно и тоже.
Подача информации, если в визуальном представлении — это больше типографика + дизайн. Есть еще такое понятие как шрифтовой дизайн.
То что ты написал можно отнести к веб-дизайну, полиграфическому дизайну, книжному дизайну (очень ярко тут выражено), к ландшафтному и экстерьерному дизайну, дизайну интерьера, архитектуре…
Я бы отметил в вебе следующие направления:
1. Веб-дизайнер работает с внешним видом и может задавать концепцию — это его прямая задача в работе с маркетологами. Креативщик — это дизайнер.
2. Верстальщик должен уметь работать с инструментами дизайнера и знать о верстке все, что нужно на сегодняшний день, чтобы писать грамотный код. Верстальщик может уметь и программировать, но он должен выбрать, чем он должен заниматься.
3. Программист пишет код и для него безразлично какой будет дизайн и как дизайн должен быть сверстан. Задача программиста создать платформу, программу (думаю на Хабре нет смысла описывать задачу программиста словами дизайнер :) )
Вот самая простая схема. Я не вдаюсь в подробности о менеджменте и финансах и о копирайтерах или журналистах.
У меня складывается впечатление, что понятие слова веб-дизайн утратило свою суть в наших реалиях.
На самом деле веб-дизанер — это дизайнер который «рисует веб». Понимает какие должны быть идеальные пропорции и композиции для веб.
Полиграфический дизайнер перешедший в веб-дизайн мыслит узко в рамках заданного формата бумаги, и это очень заметно. У веб-дизайнера нет заданного размера формата, точнее эти рамки размеров плавающие и не ограничены.
Веб-дизайнер не должен мыслить функционалом движка — о должен креативить. Как реализовать идею дизайнера должны думать верстальщик и программист.
Дело в том что на определенном этапе нужно было переходить полностью на новую архитектуру (все же архитектура друпал довольна стара по современным меркам) и новую политику юзабилити (чем друпал всегда страдал).
Это относится ко многим проектам.
Да будет большая проблема. Все модули и темы для новой версии не подойдут. Но есть и выход — написать «конвертеры» и т.п.
С каждым обновлением версии cms становилась всё монстрообразней и тянула за собой ошибки архитектуры старых версий, чем повлекла за собой рождение новых багов.
Просто побоялись — и вот итог.
Это относится ко многим проектам.
Да будет большая проблема. Все модули и темы для новой версии не подойдут. Но есть и выход — написать «конвертеры» и т.п.
С каждым обновлением версии cms становилась всё монстрообразней и тянула за собой ошибки архитектуры старых версий, чем повлекла за собой рождение новых багов.
Просто побоялись — и вот итог.
На Lullabot пообсуждали, да и топ разработчики типа Sun высказались
Работа с друпалом идет. Радует, что мои инициативы/патчи в ядре )
7ка работает. Производительность возросла. Багов не встречал, но вот модули некоторые совсем сырые. Активно приходиться писать багрепорты/патчи. И замедлился выход новых релизов и модулей факт! Но я связываю это с переходом с CVS на git
8ка вообще радует инициативами — повыкидывать все лишнее.
Работа с друпалом идет. Радует, что мои инициативы/патчи в ядре )
7ка работает. Производительность возросла. Багов не встречал, но вот модули некоторые совсем сырые. Активно приходиться писать багрепорты/патчи. И замедлился выход новых релизов и модулей факт! Но я связываю это с переходом с CVS на git
8ка вообще радует инициативами — повыкидывать все лишнее.
p.s. Да и проектов, базирующихся да на данной CMS по сей день, могу припомнить лишь 1 (cwer.ру).
www.whydrupal.ru/drupal-sites
drupalogy.ru/gallery/top100
Существует устойчивое мнение, что движок Друпала более тормозной, чем Джумловский.
Я лично с этим не согласен, но не проводил ли кто тесты?
Хотя тоже вопрос, какие версии сравнивать и так далее.
Я лично с этим не согласен, но не проводил ли кто тесты?
Хотя тоже вопрос, какие версии сравнивать и так далее.
Не вижу смысла в друпале, ибо:
1) хочешь сделать веб-приложение => используй нормальный фреймворк
2) хочешь сделать сайт => используй CMS (тот же wordpress подходит для 99.9% задач)
drupal — ни туда, ни сюда.
imho
1) хочешь сделать веб-приложение => используй нормальный фреймворк
2) хочешь сделать сайт => используй CMS (тот же wordpress подходит для 99.9% задач)
drupal — ни туда, ни сюда.
imho
Ещё один разработчик ядра Друпала попросил отставку.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Кризис Drupal