Преимущества Wordpress

Эта публикация является ответом на пост «Недостатки Wordpress — техническая сторона».

По традиции автора, уточню несколько моментов:

  1. Дабы внести ясность, сразу скажу, что я тоже намерен рассматривать статью с технической стороны, но через призму всех разработчиков, а не только опытных;
  2. Мне доводилось иметь дело со многими CMS, в том числе и ezpublish, который написан, практически весь, со строгим использованием ООП. В своё время плотно использовал Drupal;
  3. Большую часть времени я программирую с помощью сторонних фреймворков и осведомлён, каким должен быть хороший движок;
  4. Ни в коем случае, не считаю себя гуру PHP, просто знаю, что настоящие гуру возможно обойдут тему WordPress стороной.

Я нигде не встречал более простых и элегантных реализаций функционала, чем в WordPress. Я отнюдь не считаю, что во всех проектах должна использоваться эта CMS, но, на мой взгляд, WordPress хорошо справляется с возложенными на него задачами и отнюдь не без использования ООП. Вся фишка в том, что ООП использовать никто не запрещал. Многие плагины написаны как раз с его использованием.

Но всё же, стоит провести черту, в каких случаях стоит использовать WordPress.

Я лично выделил для себя следующие пункты:
— Сайт должен быть информативным, без сложных запросов для которых может понадобится ORM или ActiveRecord. Т.е. для АПИ, статистики — я бы не советовал использовать CMS;
— Админка должна быть принята, как должное и другую панель управления никто не потребует;
— Предполагается, что WordPress покроет большую часть функционала, а меньшую надо будет дописать(плагины, темы);
— Проект большой и громкий. Использование WordPress в таком случае будет только на руку как разработчикам CMS в качестве рекламы, так и разработчикам проекта (частые обновления, низкий порог вхождения, готовое решение из коробки).

В остальных случаях я всецело за использование своих или чужих фреймворков.

Далее автор приводит примеры.

«Глобальные переменные это так классно, не правда ли?»


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

«А пригодился бы разработчику слой абстракции базы данных?»


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

Не будем считать тех, кто действительно злоупотребляет логикой для входных параметров при построении этого самого запроса (тут я соглашусь, что лучше это выносить всё в виде функций в файл functions.php). Однако всё же я не считаю это чем-то сверхъестественным. Наоборот, удобен случай, когда в темплейте team можно сделать запрос, указав post_type team.

Кому-то может показаться непривычным, что делая запрос он может повлиять на дальнейший вывод контекстной информации, но если понять, как этого избежать, то проблема сразу исчезает. Избежать можно, используя get_posts или wp_reset_query. Скажем, если совсем лень, можно использовать конструкцию вида:

$oldpost = $post;

// query_posts()

$post = $oldpost;

Я не рекомендую никому использовать вышеуказанный код, такой подход использовать в корне не верно.

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

«Маршрутизация с помощью mod_rewrite»


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

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

«Как насчет файловой архитектуры?»


Соглашусь, что в имеющемся виде файловая архитектура не шибко гибкая. Опять же, повторюсь, разработчикам не запрещено использовать свои собственные include и requre_once, разносить всё по классам в отдельных подпапках для большего DRY.

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

По поводу использования less, sass. Мне прекрасно удавалось ими пользоваться, в том виде, как оно сейчас есть в WordPress.

Мне кажется, что автор в какой-то степени только недавно начал использовать автолодеры с неймспейсами, инкапсуляцию, наследование. При этом, списывая функциональный подход к программированию команды разработчиков WordPress на попытку написания достойной архитектуры. Хотя, на самом деле, низкий поклон ребятам, что они не ударились в PHP5 Only программирование и не заинкапсулировали всё внутри классов с неймспейсами.

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

Псевдо Cron задачи


Коротко отвечу, что тут я согласен с негодующим автором.

«Нарезка изображений»


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

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

Заключение


Можно долго философствовать на тему паттернов, алгоритмов, удобств… Погодите-ка, давайте учитывать, что WP создавался не для профи программеров, а для обычных людей, интересующихся как им создать свой блог. В таком ракурсе, пожалуй, WordPress справляется со своей задачей на все 99%.
Поделиться публикацией
Похожие публикации
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама
Комментарии 17
  • +11
    В итоге, вы сами соглашаетесь с автором того поста, что у wordpress много косяков.
    Или это и имелось ввиду его преимуществом? :)
    • +3
      Астрологи объявили неделю Wordpress на Хабре.
      • +2
        количество холивара в комментариях увеличено втрое
      • 0
        Если по теме: Cron в Wordpress «вылечили» от болезни запуска только во время посещения сайта. С использованием LESS/SASS тоже проблем не возникает.
        • +1
          Скажу плюс к псевдокрону.

          WordPress же не рассчитан исключительно на крупные порталы, он вполне может использоваться для домашней странички/блога с посещаемостью 10-15 «своих» в месяц, зато можно аккуратно автоматизировать какие-то простенькие задачи, и не разбираться с нормальным кроном, ведя ВСЕ на сайте.
          Причем для хостера нагрузка от псевдокрона вполне может быть ниже, если на сервере висит таких пару сот сайтов, и крон дергается не каждую минуту, а только при посещении.

          Еще совсем недавно (лет 5-8 назад), большинство хостингов не предоставляли возможности настроить какие-либо задачи по крону, и псевдокрон отлично подходит для простеньких сайтов, на которых нужен запуск каких-либо задач по расписанию, а WP гораздо старше. Так что, выкидывать из него функционал? Он же не мешает, если с минимальными знаниями можно использовать то, что подходит больше.
          • +3
            «Нарезка изображений»
            нет. Это действительно больная тема. К примеру, смена дизайна сайта подразумевает, что нужно скачивать плагин по ресайзу фото так как на новом сайте картинки другого размера.
            К тому же, куча плагинов по ресайзу на лету, которые позволяют сейчас делать то что будет в ядре:
            core.trac.wordpress.org/ticket/15311

            И надеюсь, что мой баг наконец зарелизят. У превьюшек не отрезаются метатеги. А поскольку jpg не сжимается в gzip серверами, легко можно по 30кб набрать пол метра веса лишнего в галерейке из 15 фото.
            core.trac.wordpress.org/ticket/28634
            • +6
              Далее автор негодует, что все данные вписываются в одну общую схему таблиц. Первый раз столкнувшись с этим я пребывал в лёгком шоке. Мне не давала покоя мысль, как можно настолько аккуратно всё сделать, что для каждой новой сущности не придётся плодить таблиц. Более того, мы сохраняем за любым типом данных возможность вести историю изменений (ревизии), быть объединными между собой в качестве создания подборки похожих материалов (таксономия). Имеем расширенный доступ ко всем данным в одном месте.

              С каких пор пихать все данные системы в одну таблицу это хорошо? С чего вдруг много таблиц это плохо? Если провести аналогию с ООП, то следует создать один божественных класс на всю CMS и пользоваться им.
              • +3
                <?php
                
                class HandOfGod
                {
                
                    ...
                
                }
                ?>
                
                • 0
                  Простите, не удержался.
                  <?php
                  
                  class DiegoMaradonna extends FootballPlayer {
                  	...
                  	private $hand = null;
                  
                  	public function setHand(HandOfGod $hand) {
                  		$this->hand = $hand;
                  	}
                  	...
                  }
                  
                • 0
                  Тот же битрикс долгое время так жил (все данные инфоблоков в двух таблицах). Не знаю как сейчас.
                  Это не оправдывает Wordpress.
                  Это не хорошо.
                  Но как видите, некоторые так живут…
                • 0
                  По-моему, эти две статьи (преимущества и недостатки) можно свести к двум пунктам:
                  • Вам нужен простой инструмент для создания сайта? Используйте WordPress
                  • Вы профессиональный разработчик и можете создать свое? Используйте свое
                  • +4
                    А если я профессиональный разработчик, но не хочу создавать свое?
                    • +1
                      Умные — направо, красивые — налево
                    • 0
                      Профессионал — это тот, кто зарабатывает деньги своим трудом и знаниями. Я использую WordPress в проектах — я не профессионал?
                      • +1
                        Деньги своим трудом и знаниями может зарабатывать и не профессионал. Думаю, профессионал это некая ступень личной карьерной лестницы, которая начинается с новичка и кончается гуру.
                    • +1
                      Какая-то куцая статья, если честно. У автора, походу, взыграл праведный гнев кое-где, вот он и решил в ответ написать. Но получилось, ИМХО, как-то не очень, оригинальная статья более содержательная, что ли.
                      • 0
                        Краткое содержание статьи сводится к следующей парадигме: «Можешь лучше — напиши свое. Не можешь — пользуй то что дают».

                        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.