Лучшая CMS

Популярность WP обусловлена тем фактом, что пока все создатели CMS делали продукт, удобный для программистов (ООП, MVC), WP делали продукт, удобный для конечного пользователя: репозиторий плагинов с установкой из админки, удобный интерфейс, черновики и прочее. Как результат: большой спрос среди пользователей, которые, в свою очередь, сделали спрос на программистов. Тут злую шутку сыграл PHP и его процедурный стиль: чрезвычайно низкий порог вхождения, и, как результат, куча плагинов, сделанных на коленке, что и дало вторую волну пользователей.

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

Так мы и получили блоговый движок, на котором делают интернет-магазины.

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

Так же как и в темах делать ренайм функций или менять вхождение аргументов в них. Да и нативный php в вперемешку с html кодом как то не возбуждает честно говоря.

То есть, при обновлении ядра претерпевшего изменения, возможно часть плагинов ( а то и все ) отъехали, придется делать правки темы ( так как не является шаблоном ).

Не есть комильфо :)

В общем и целом:

для очень и очень многих задач Вордпресс подходит идеально.

Сколько вот работал с разными CMS, частенько ловил себя на такой мысли: а нафига этот сайт вообще делали на ModX/Drupal/MadeSimple и т.д.

Ну то есть не то чтобы Вордпресс был однозначно лучше, нет, просто не было никаких преимуществ использования других систем. Иногда это даже касалось магазинов.

Что вспоминается, так это чудовищная работа с файлами (картинками например) во многих cms.

Ну а если на сайте требуется блок "новости" или "блог" - ну это всё, приплыли, нужны модули всякие и работать оно все равно не будет даже близко так как Ворпресс по умолчанию.

На то они и мужики :) Мужикам надо знать как печь топить, дрова колоть. Зачем им архитектура ВП?)

borisd, наследование бывает не только у классов :)

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

У меня наследование моделек идет вот так:

    'news' => {
        '#parent' => 'article',
        'rules' => {
            'default' => {
                'parent_id' => {
                    'int',
                    {'defaultParent','where'=>{'route'=>'news:index'}},
                },
                'showDate' =>{'virtual',{'defaultCopy','field'=>'created'}}
            },
        },
    },

А вариант

безусловно самый ужасный.

В ВП для создания новых типов записей используют плагины, которые оборачивают довольно толстый код создания типа записи. Это было бы терпимо, если бы не два момента - таких плагинов несколько, и поскольку они не являются частью ядра, то мы получаем зоопарк "фреймворков" - все пишут на ВП, но реально каждый на своем варианте. Далее - весь этот "код" хранится в базе. Т.е. гит в пролете поиск по коду в пролете, копипаст в пролете и т.п.

Еще у ВП как следствие парадигмы "скопируй шаблончик и радуйся" нет универсального подхода к наследованию. Если у стилей есть наследование, то не факт, что оно будет у модели, и явно будет устроено по другому. И если в событийной модели есть событие, то отлично, а если нет, то всё, забуть. В ядро не попасть. (С грамотным наследованием можно прописать свой класс отнаследованный от стандартного и всё, но это если ты можешь сообщить что нужно использовать другой класс, например у меня рядом с #parent можно написать #class и это работает и для моделей, и для вьювов и для контроллеров и для сервисов и т.п., а вот у ВП так подменить что-то не всегда выйдет, есть у них внутри какой-то класс, но подменить его нельзя, только перехватывать что-то). Но и это не главные проблемы ВП. Вылазить за стандартные события особо не нужно, но вот отсутствие единообразия, внятной структуры - проблема. Как в том анекдоте - зал для удовольствия совмещен с туалетом: вся логика в фанкшн.пхп. Да, "мужики" инклюдами создают некое подобие структуры. Но это исходя из видения конкретного "мужика". Так то почитают википедию, да будут всякие опенкарты МВЦ называть (суки!).

Кодекс это костыль для попытки упорядочить то, что не упорядочить естественным образом.

Но и это пол.беды. Нет простейших инструментов. Вот это уже беда.

ORM/ActiveRecord:

Ну вот есть у нас допустим страница категории товаров. У нее есть товары, мы их себе спокойно выводим. Все хорошо. Тут прилетает задача сделать вложенные категории. Ну фиг с вами, выводим список категорий вверху, внизу товары категории. Не проблема.

Тут прилетает задача - выводим для вложенных категорий не только название, описание, ссылку и иконку, а еще и топ5 товаров из вложенной категории. Черт! тут уже пляски пошли с бубном. Нет, нет, вы не поняли. У товаров ведь есть список категорий к которым он относится, их тоже нужно вывести, чтобы красиво и удобно было. Да, еще у товара есть производитель. А у производителя есть логотип. Его тоже нужно обязательно вывести в этом превью товара.

А это уже на день работы вырастает.

Или нет?)

Или можно написать что-то вроде:

//$category - моделька выводимой категории
foreach($category->subcategorys->findAll() as $cat) {
    echo $cat->title; echo $cat->url; // тут конечно будет верстка ссылки, но это детали
    $products = $cat->products->limit(5)->order('popularity')->findAll();
    echo showModels('product/viewSmall',$products);
}

Ну а product/viewSmall мы уже писали до того, когда писали вывод товаров в категории.

Но раз в ВП тоже можно нормально дробить и переиспользовать (правда хрен так кто делает), то напишу и его (схемотично конечно).

echo $model->title; echo $model->url; echo $model->preview; // ....
foreach($model->category->findAll() as $cat) {
    echo $cat->title; echo $cat->url; // тут конечно будет верстка ссылки, но это детали
}
echo $model->manuf->logo->small;

Да, в ВП это можно сделать. Да, есть даже неплохие плагины которые упрощают это до _ПОЧТИ_ такого же уровня. Но! Это уже не вордпресс, а некий плагин. Со всеми вытекающими.

Помимо ОРМ в ВП не хватает других полезных инструментов, вроде валидации, активформ и т.п.

Например я делаю.. ну скажем у меня сайт автосалона, и мне нужно сделать форму записи на Тестдрайв.

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

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

<?=view('widget/formModel',['model'=>$model,'noHelp'=>TRUE]);?>

Всё.

Красивая бутстраповая формочка, с нужными типами полей, с ошибками если были ошибки, с прочими полями. Всё готово. Когда клиент захочет добавить поле "Город", чтобы расширить сеть на другие города, то я даже в шаблон заглядывать не буду. Вообще. Просто добавлю строчку в описании модели, да добавлю колонку в базу.

ПС: И тем не менее.ВП хорош. Стар, неуклюж, но хорош.

---------- Добавлено 29.11.2016 в 11:35 ----------

Серьезно. :)

Потому что:

Core-разработчики знают все паттерны. :)))

Просто хрен они их могут позволить применять в прикладном коде.

Всё старое отвалится. _Ничего_ не останется. Совсем.

---------- Добавлено 29.11.2016 в 11:42 ----------

EAV - хороший паттерн. Его преимущества и недостатки тривиальны.

Для гибкого блога с низким порогом вхождения это самое то.

Хотя я тоже предпочитаю полноценные поля а не EAV.

А так то тут половина даже не понимает о чем мы :) "Движок то сам всё выбирает", а то как выбирает, и чего это стоит - не важно. )

---------- Добавлено 29.11.2016 в 11:43 ----------

Вот ведь блин :)

Обе позиции в туду отодвигаю уже второй месяц)))

Ну, пример был сильно упрощенный. В джанго ведь наследумая модель может быть самостоятельной или абстрактной, можно использовать прокси-модели. Всё зависит от ситуации.

Например, у вас в категории может быть не один, а много разных типов материалов, причем сложных типов с объемными тяжелыми материалами. Так вот чтобы публикации списка материалов категории не дергать все эти материалы разных типов из разных таблиц, можно создать базовую легкую модель с минимальным набором полей: тайтл, анонс, превьюшная картинка, ключ на категорию и подобное. А все остальные сложные типы будут наследоваться от этой базовой модели. Тогда при публикации категории вы одним запросом извлекаете объекты базового типа и через шаблон публикуете их список (тайтл, картинка, анонс). И всё. Всего один запрос к БД, не зависимо от типов материалов и прочего.

Тут оч много намешано..

См.

1. "Добавлять" - вовсе не значит ДОБАВИТЬ. Одним добавленным хуком или строкой в конфиге можно ОТМЕНИТЬ работу кучки функций.

2. Плагин - это такой же код. Это механизм как раз и создан для того, что бы реализовать что-то, чего нет (или не так как хочется) в ядре. Плагинопаронойя - это реально болезнь читателей ГС. Не наличие, а сам код - вот что важно.

3. Плагинами в основном решаются не проблемы, а функционал. Лишь малая часть оных закрывает "проблемы". Но это проблемы локальные/временные. Напр. транслитерация - надо оно в ядре? Нет. Или исправления работы криво настроенного хостером нжикса. Плагины тут - лекарство от др проблем. Это плохо?

4. Если можно закрыть проблему в теч неск мин - это плохо? Потом уже спокойно разбираться в причинах. С тем же инжиксом напр или криво установленным сертификатом.

Вот тут как бэ соглашусь. Но чем в html использовать макросы (аля [meta_date_post:current(DD-MM-YY)]) - может лучше сразу пхп? Дилемма, да.

Если изначально всё сделано правильно, то не придётся. Обратная ж совместимость. Но нек функции устаревают, да. Хотя функционал не пострадает ещё оч долго (сейчас даже многое 5тилетней давности работают), но лучше заменить. Оно и в логах меньше нотисов и безопасность опять же.

В друпале на каждое кастомное поле две таблицы создаются, с полями БД, зависящими от типа юзерского поля. А как в WP в одну таблицу запихивают поля разных типов? Поле БД соответствующего типа в эту единую таблицу добавляют?

Вот это всё - от незнания ВП. И лени "мужиков". :) И причины и следствия.

Это просто.. Это вообще-то ДОКУМЕНТАЦИЯ. Такая документация, которой нет ни в одном двиге. (по-русски в тч).

Да, на данный момент кодекс местами устарел и создаётся новая версия. С разделением для юзеров и девелоперов.

1. Плагин - и есть ВП. См 107.

2. В яре нафик не нужны ВИЗУАЛЬНЫЕ инструменты управления кастомеными типами контента. (там и так хватает лишнего). Этим будут пользоваться менее 1% юзеров. А для грамотных есть АПИ и плагины.

---------- Добавлено 29.11.2016 в 13:07 ----------

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

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

Помню в году этак 2007-2008 я сильно возмущался что пользователи моего сервиса не следуют инструкции "обязательно нажмите вернуться на сайт после оплаты".Ну что они тупые или слепые? Я ведь красным h1 написал на полстраницы написал, прямо перед оплатой. Почему в день по пять человек в саппорт пишут "у миня непаполнилося"? Потом таки переписал так чтобы вебмани подтверждали оплату и без юзера. Многие ляпы "мужиков" в полноценных движках просто невозможны, или затруднительны. Что не отменяет других недостатоков у полноценных...

---------- Добавлено 29.11.2016 в 12:12 ----------

Есть понятие "стандартные плагины".

Но дело даже не в том.

Такие ядерные настройки в базе - усложняют отладку, разработку, версиозность и т.п.