Комментарии

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

В css уже должны быть стили для всех h1/2/3… strong и т.д. а так же кастомные стили для различного рода контента и ОБЯЗАТЕЛЬНО приучить клиента ими пользоваться…
ИМХО если контент будет добавлять человек, который хоть как умеет работать в Word, то тут ничего сверхсложного не будет для него, ну а если не способен работать в Word, то и тут ему не место заниматься добавлением контента…

От себя добавлю что поддерживать проект на Друпале, где используются собственные хуки (т.е. не хуки ядра, но и не мной писанные) и workflow_ng, довольно сложно. Код получается довольно запутанным.

Вероятно, Вы просто не умеете готовить Drupal.

Вообще говоря, если не рассматривать проекты вроде яндекса или гугла (то етсь проекты действительно большие и не то, чтобы относящиеся к категории сайтов, создаваемых на CMS), все прочие проекты, фактически, маленькие. И, посему, если есть в наличии CMS (а правильнее — framework для быстрого — в течение, скажем, пары рабочих дней, как максимум — создания кастомизированной CMS), способной потянуть достаточно сложный из этих «маленьких» проектов — тогда, вероятно, нет прямого смысла заморачиваться на 2 -3 cms, которые будут уметь меньше, чем основная.
Что же до целей — первая, очень правильно обозначена как маркетинговая — на моей памяти (притом, что удобство управления подавалось нами как одно из преимуществ), реально обновляли свой сайт чуть меньше 1 % клиентов. И не потому, что такое обновление казалось им задачей трудоемкой — просто как-то с самого начала работ по поддержке, все эти работы перекладывались либо на студию, либо, что реже — на знакомых фрилансеров.
Вообще, заявленная цель установки CMS (облегчить и частично автоматизировать поддержку сайта) чаще всего маскирует цель реальную — снизить издержки студии на создание и поддержку сайта.

Только не забудьте сказать, что в комплекте для программиста должна быть валерьянка. :)
Лично изучая Drupal Form API чуть не повесился, и до сих пор нервничаю делая там формы. А уж сколько волос на голове останется у верстальщика, который рискнёт научиться писать шаблоны для Drupal (там даже Smarty всего не решает, увы) я и предположить боюсь. Но за то те, кто прошёл этот «Курс молодого бойца» конечно могут свысока смотреть на программистов UMI и Bitrix, поскольку гибкость Drupal даёт делать любую экзотическую кастомизацию достаточно небольшии затратами времени и сил.

Друпал, ИМХО, ориентирован на социальные проекты и «личные» сайты. Но никак не корпоратив. Слишком уж сложно получается для конечного пользователя. Иди пойми с ходу, что в друпале новости — это набор статей с тэгом «новости», а фотогалерея — такой же набор статей с тэгом «фотка» и что таким макаром можно сделать что угодно. Хорошо, конечно, что все это прекрасно вписывается в умолчальный дизайн и органично в нем смотрится. Но изнутри это все администрируется с тяжелым трудом и выглядит жутковато. Друпал и есть яркий пример системы от программистов для программистов.

Да, нужно сначала задуматься о целях CMS, которую хочешь приобрести. Какая CMS нужна web-студии, которая держит много проектов? Большинство делают сайты на одной и той же системе. А может быть стоит подумать в сторону «разные cms для разных целей»? То есть иметь арсенал(ну это грубо сказано, штуки 2-3) cms для проектов разных размеров?

Почему я так мыслю: чем универсальнее система, тем сложнее с ней справляться как в пользовательском отношении, так и в программном.

Называю систему: Drupal
А DST Platform это все таки уже фреймворк, сравнить с CMS не совсем объективно и честно

Студии штатов и Австралии часто используют joomla и drupal.
95% клиентов нашей студии оттуда, так что знаю на своем опыте за последние 3 года

Первоначально, до разработки какого-либо комерческого программного обеспечения разработчик должен (по идее) спросить у себя «Какую пользу принесёт покупка моего ПО?».

Для чего пишутся CMS/CMF в принципе?
На мой взгляд, есть такие основные цели:

Построение маркетинга студии («Наш сайт может обновлять любой ваш сотрудник»)
Автоматизация процесса вёрстки («Мы делаем сайты быстро»)
Автоматизация процесса программирования («Мы пишем нереально сложные вещи»)

По-сути, конечно, цель одна — увеличить прибыль. В данном случае путём сокращения времени на разработку и обновление. Только в первом случае, за счёт конечной реализации полей,
во втором, за счёт скорости внедрения популярных скриптов на оригинальный дизайн,
в третьем, ускорить процесс написание оригинальных фич, на которые и делается ставка на разрабатываемых сайтах.

И когда мы говорим, что WYSIWYG ужасный на CMS-шаблонизаторе, или ещё хлеще на CMF, это банальное нежелаение вникнуть в цели существующих CMS и в те критерии, которые к этим CMS выставляются.

CMS которая имеет все три направленности, я пока не встречал, да и не сильно пытался это сделать.
Сейчас пробую проектировать свою CMS, но это уже другая история…

Можно ещё сравнивать CMS по UI, но это не затронет технических характеристик.
Можно сравнивать по возможности кеширования, устойчивости, системе back-up'ов, шаблонов, но если не выяснен вопрос «А зачем Вам CMS?» все эти технические характеристики только загонят вас в тупик выбора.

Так что, до того, как искать CMS, подумайте, что вам от неё нужно.

Почему я не люблю российские коммерческие CMS

Я являюсь руководителем проектов одной региональной веб студии, занимаюсь этим ремеслом достаточно давно и очень люблю свою работу. До поры до времени, сидели на самописной системе управления, но расширив штат программистов и получив более, менее серьезные проекты поняли что наша система не подходит. И тут я стал изучать рынок.

Итак стал я все ковырять изучать и смотреть насколько предлагаемые рынком системы удовлетворяют моим потребностям. Изучал я российские коммерческие продукты. С каждой новой системой становилось все груснее и груснее.

А задача то стояла простая, найти готовую систему которая бы не отнимала времени у сотрудников на создание однотипного функционала. Вторая задача, найти систему с максимально быстрой настройкой шаблона под свои нужды, ну и соответственная кастомизация тех или иных модулей. Сам я то, в прошлом программист но последнее время все ближе по духу к дизайнерам (фраза грубая но суть я думаю вы уловили). К разным дизайнерским мини-фичам на сайтах отношусь достаточно трепетно, и всячески отстаиваю права фичей на существование. Былой программист посмотрит на фичу и скажет: — «Да ну, что Вы господа придумали, херня полная, никому не нужна, да и мне с ней ковыряться долго, давайте-ка сделаем как на прошлом сайте». С таким порядком дел я вообще не согласен и при выборе системы управления считал тонкую кастомизацию тех или иных частей какого либо модуля – основным параметром качества системы.

С быстрой прикруткой шаблона, некоторые системы еще справлялись, а вот с кастомизацией уже сложнее. У меня сложилось такое впечатление что некоторые разработчики создают систему под единожды спроектированный демо сайт. Например новости: заголовок, краткое содержание, подробное содержание и еще миллиард параметров. Ну нахера? Как минимум один параметр (из набора заголовок, анонс, содержание) лишний. Ну кто будет каждый раз херачить здоровенный пресс релиз, с аносами и приблудами? На самом деле кто то конечно будет, и вот из за них разработчики все это и делают (Алан Купер про концентрирование программистов на исключительных случаях). Разработчики стараются создать швейцарский армейский нож, одинаково подходящих как для сайта компании «1С», так и для ремонтной мастерской в Урюпинске. А в швейцарском армейском ноже, самим ножом пользовать то не удобно.

В этом месте, внимательный читатель, накинется на меня с критикой. Мол все можно прикрутить, открутить, забить, посадить на клей и т.п. Да я понимаю, что при хорошем знание системы из нее можно выдавить ой как много. Я же говорю о другом: лично для меня все это является само самим разумеещемся. Разработчики не ставят перед собой цель сделать гибкий и простой инструмент. Все делают системы – установил и готово.

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

А бредовость отдельных модулей вообще поражает, например: каталог ссылок. Что это и нахера?

Что касатеся архитектуры систем (не знаю что у них там внутри) они все однотипные. Ну посмотрите чем концептуально отличается Битрикс от УМИ, или Хост от Амиро? Да ничем, та же страница ориентированная структура, такие же модули. Переходя от одной системы к другой, отличия видел одни – другой интерфейс. А принципиально все одно и тоже. «Ну и что?» скажите вы, ну на самом деле ничего такого. Дело в том что мне не понятно, почему никто не хочет попробывать новые подходы и найти новые решения, а не развивать тупиковую страницо-ориентированную архитектуру.

А эти ужасные WYSIWYG. Это вообще кошмар. Сидишь делаешь стили для сайта, выверяешь межстрочные расстояния, заголовки и прочую белеберду которая делает сайт вкусным. А эти WYSIWYGи на все это плюют и генерят свой «могучий» код. А что мне на это отвечают: секретарши с ним проще работать. Ну а результат каков? Плачевен друзья мои, плачевен.
Вкраце суть: все известные мне российские коммерческие системы управления сайтом – не годятся, как базис для создания разнотипных сайтов. Разработчики навязывают свои стандарты информационной архитектуры (которые далеки от совершенства, да и далеки от народа). Хотя CMS априори должна давать гибкость.

Если кому интересно приведу примеры в комментах. Вы называете систему, а я говорю что в ней мне не нравится.

Вообщем я долго мучился с вышеописанными проблемами. Пока не нашел DST Platform. Но это уже другая история

Сей порыв связан с моим отчаяньем, ибо уже как 2 месяца выбираю CMS для студии. И о ужас! Ничего не могу найти достойного.
Суть следующая. Я среднестатистической руководитель проектов, среднестатистической российской региональной веб студии. До поры до времени сидели на своей CMS и худо бедно справлялись. А в один прекрасный день я понял, что она абсолютно не годится по ряду причин, не буду в них углубляться, но суть в том что система собрана на коленках и на что-то серьезное пускать ее – смерти подобно.
И тут настало время Ч. Время выбора достойной CMS, коммерческой или некоммерческой не важно.

Вот вкратце требования:

Система нужна для клёпки простых сайтов. Статичные страницы, новости, обратная связь ну максимум каталог. Создавать мега стартапы, порталы, интернет магазины и прочую хрень на ней не собираемся. Сайты с типовым функционалом. Каких в рунете большинство;
Быстрая натяжка шаблона. Соответственно шаблонизатор обязательно, и желательно человеко-совместимый;
Возможность кустомизации модулей;

В общем, стоит задача, чтобы типовые сайты мог собирать средней руки веб разработчик, с уверенным знанием HTML+CSS и принципов сайтостроения (про дизайнеров, проектировщиков и т.д. я не говорю, они в процессе есть).

Вот что перебрал, и ни одна не устроила:

Amiro.CMS;
Cetera CMS;
Webdirector;
Drupal;
HostCMS;
Joomla;
NetCat;
Twinlight;
S.Builder;
UMI.CMS;
Bitrix;
ABO.CMS.

Я не хочу обидеть разработчиков, но ощущение, что все CMS созданы программистами для программистов (или непонятно кем непонятно для кого), а не программистами для людей. Подскажите, кто что использует или может кто нибудь приведет довод к одной из вышеперечисленных CMS, почему ее стоит использовать? Буду крайне благодарен.

И еще задался вопросом, а какую CMS используют студии штатов и европы. Не уж то все на своих разработках сидят? Гуглил, ничего не нашел. Даже приличной коммерческой буржуиской CMS.

WordPress должен развиваться в правильное русло. Переписать бы его на go. Есть конечно генераторы статических сайтов Hugo. Но он для обычного человека будет сложновато.

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

Спасибо за ответ. Эх, но кто-то же должен WordPress развивать, на котором треть всех сайтов в интернете работает )))

Конечно никто не спорит. Цель микросервисов — достичь хорошего горизонтального масштабирования. Микросервисы позволяют выполнять ряд задач намного гибче. Если анализ показывает что узким местом является конкретный сервис, достаточно просто запустить его копию. По ресурсам — намного менее затратно.

Важно понимать, что микросервисы применимы не везде. Наибольшим препятствием для использования микросервисов являются CAP-теорема и распределенные транзакции. Микросервисы — это хорошо тогда, когда они реально «микро» и реально изолированы друг от друга. Это скорее вопрос организации людей, чем приложения. Можно нанять какого-нибудь баклана по дешёвке, чтобы он добавил Фичу Икс и не поломал всё остальное. А если накосячит — то просто избаиться от него и нанять другого ещё дешевле.

«Молодёжь» во все времена одинаковая. Вам бы всё переписать на хайповой технологии, да новых фич натыкать.

PHP будет жить ещё очень долго, так что его конечно стоит изучать.

Несколько лет назад многие говорили, что Phyton мёртв и не актуален. Зачем вообще на него время тратить, а теперь куда не плюнь, в ответ донесётся phyton…

Ещё в прошлом году все трубили про Vue, а теперь что-то тихо. Так и с Go будет, шум утихнет и он станет просто удобным рабочим инструментом для определённых задач.

И микросервисы не так уж хороши. Много запросов, медленный отклик и т.д. Всё хорошо в меру и к месту!

в php осталось только старый код, который нужно поддерживать. сейчас всё идёт к микросервисной архитектуре. учить нужно golang. удобство, быстрота, статика.

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

PHP в этом плане сильно специализированный, так как используется только для разработки сайтов. В такой специализации есть как плюс, так и минус.

Минус в том, что PHP приспособлен только к стандартному для него синхронному однопоточному выполнению в рамках веб-сервера, а остальное пока не очень умеет. Так что как только требуется сделать что-то для него нестандартное, то возникает необходимость эмулировать эти вещи или делать остальные части на других языках вроде серверного JavaScript для асинхронности или Go для многопоточности.

А плюс в том, что хоть он и делает всего одну работу, но делает её идеально. Разработчики самого языка не отвлекаются на посторонние задачи и совершенствуют его только в основном направлении, оптимизируя скорость и привнося только важные для него новшества из других языков. Поэтому в нише скриптовых интерпретируемых веб-языков PHP практически является самым быстрым. Быстрее него уже только языки компилируемые, но будущий PHP 8.0 с JIT-компиляцией, как нам обещает его разработчик Дмитрий Стогов в докладе, вскоре обгонит и их.

К тому же это язык с синтаксисом из семейства более продвинутых Java и C#, что позволяет PHP-программистам учиться у них и при необходимости легко перейти на любой язык этой группы. С Ruby или Python со своим обособленным синтаксисом это будет сделать проблематично.

В PHP переходят хорошие практики из других языков. Создаются и развиваются профессиональные фреймворки. Так что из языка для любительских сайтов он уверенно переходит в нишу быстрых профессиональных веб-проектов, авторам которых не хочется поднимать тяжелые серверы на Java. Учить PHP сейчас или нет? Каждый раз накатывает новая волна технологий и каждый раз снова и снова «хоронят» PHP фразами, что вот-вот очередные Ruby или NodeJS победят PHP. Но десятки лет проходят, а всё никто его не побеждает.

Помимо продвинутого программирования веб-приложений на фреймворках, PHP отличается наличием большого числа CMS для разработки стандартных сайтов. И они никуда исчезать не собираются. Для экзотических задач удобны экзотические языки. А для классических проектов успешно хватает классического PHP. Так что всегда можно сказать, что другие языки приходят и уходят, а PHP, С++ и Java скорее всего вечны. И работы на них всегда будет много.

PHP – довольно хороший вариант для изучения как для новичков в сфере IT, так и для тех, кто работает с другими языками. Синтаксис языка входит в группу C-подобных, а это даёт возможность быстрее понять логику в коде приложений на Java, C#, C++ и так далее. Те же Python и Golang выглядят непривычно, но для тех, кто хочет изучить больше языков — это не преграда.

Если говорить о плюсах PHP, на котором мы делаем большинство проектов, стоит отнести:

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

С точки зрения новичка этот язык хорош ещё и тем, что использует динамическую типизацию и модель «отработал и умер». Это делает менее острой проблему утечек памяти и позволяет писать меньше строк кода, делая универсальные методы и функции, хоть в некоторых случаях и в ущерб архитектуре.

Перспективы у PHP также довольно интересные. С версии 5.3 язык начал очень активно развиваться и приобретать выразительные свойства (пространства имён, примеси, генераторы, опциональный тайп-хинтинг и другое), возможность работы в асинхронном режиме, а в будущих версиях ожидается JIT, FFI, поддержка предзагрузки, полноценная асинхронность.

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