Плагины против тем в WordPress или где лучше наращивать функционал ресурса

Ромчик
5

Доброго времени суток. Наткнулся в интернет-просторах на одну очень интересную статью “Functionality: Plugins vs Themes”. И мне захотелось представить Вашему вниманию её перевод. Не судите строго. Я попытаюсь сделать перевод как можно ближе к контексту, а также вставлю несколько собственных ремарок. Речь пойдет о наращивании функционала ресурса в плагинах или в самой теме. Так что, кому интересно, читаем.

На производительность ресурса, использующего WordPress, влияет множество факторов. По мнению “экспертов”, один из них —  использование плагинов. Эти самые эксперты скажут Вам, что наращивать функциональность нужно внутри темы. Давайте проверим, правда ли это.

Введение

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

Общие убеждения

  1. Функциональные возможности лучше добавлять не в плагин, а в тему.

Идея эта основана на том, что плагины очень часто являются источником проблем на Вашем сайте либо потому, что они плохо написаны, либо потому, что они вступают в противоречие с чем-то в Вашей теме. Отсюда вытекает, что функциональность (например, форму обратной связи) лучше наращивать в теме. Не так ли?
Нет, не так! И вот почему:
Во-первых, единственная разница между кодом, написанным в теме, и кодом, написанным в плагине, — время исполнения. Активированные плагины загружаются до момента загрузки темы. Отсюда следует, что одинаковый код в плагине загрузится быстрее, чем в самой теме.
Во-вторых, при использовании кода в теме возникает вопрос, где лучше его разместить. Но так как плагины имеют преимущество в загрузке кода, то следовательно код лучше размещать в плагине.

  1. Код в теме работает лучше, чем в плагине

Теперь возникает вопрос: “Для размещения функциональных элементов плагичны лучше, чем темы?” И ответ будет: “Да. В основном, да”. Теперь объясним почему.
Во-первых, разделение кода на куски — это лучшее, что можно сделать для большого проекта. Благодаря разделению кода на части легче поддерживать и модернизировать проект. Размещая функциональность в отдельные плагины, мы увеличиваем эффективность создания этого кода. Каждый модуль ведется отдельно, что упрощает его разработку и выявление проблем.
Во-вторых, если что-то поломается, то Вы просто отключите данный плагин и включите его после того, как проблема будет устранена. Представьте, что функциональность реализована в теме, тогда у Вас могут возникнуть большие сложности. Если Вы не программист, то у Вас большая проблема. Да и программист не всегда сможет в кратчайшие сроки разобраться с такой ситуацией.
В-третьих, если Вы захотите поменять тему? Вся Ваша функциональность, реализованная в предыдущей теме, пропадет или, возможно, будет работать не так, как раньше. Этого не произойдет, если Вы будете использовать плагины, так как в них реализовывается функциональность.
В-четвертых, плагины могут по отдельности обновляться и расширяться, чего нельзя сказать о теме. Если будут внесены изменения в тему, то обновится вся тема, а не отдельные файлы function.php или style.css.
Можно привести еще множество доводов в пользу плагинов, но эти — самые основные.
Теперь остановимся на количестве плагинов. Вы, наверно, представляете, как быстро будет увеличиваться число активных плагинов, если каждый кусок функциональности помещать в один отдельный плагин. Не будет ли возникать проблема? А если 10 активных плагинов? Разве это не много? А если 20 или 30? Разве это не экстрим? И на эти вопросы один ответ: “Нет”.  Во время WordCamp Канзас-Сити в 2012 году автор имел возможность пообщаться с Отто, одним из ведущих разработчиков WordPress, а также с Matt Mullenweg, правой рукой Отто. Отто делает большую часть функциональности на персональный сайт Matt-а, и он рассказал, что на этом сайте стоят и работают десятки плагинов. Каждый из них выполняет определенную функциональность и все они прекрасно работают друг с другом.
Автор запустил около 50 плагинов на своем сайте.
Дело в том, что сами плагины не ухудшают производительности ресурса, пусть их будет 100 или 200. А ухудшают производительность те плагины, которые плохо написаны. Т.е. на производительность влияет не количество, а качество плагинов. И ухудшить производительность можно всего одним плохо написанным плагином, а не 300 хорошо написанными.
Проблемы с производительностью обычно сводятся к загрузке ресурсов и выполнении запросов к базе данных. И те плагины, которые не выполняют запросов к базе данных и не загружают систему, не имеют влияния на производительность (или это влияние близко к нулю).
И в заключении нужно помнить:
Первое, что количество плагинов имеет практически нулевое влияние на производительность системы, и только качество и тип плагина влияют на производительность.
Второе, что нужно знать, код в плагине и в теме работает одинаково, так что нужно избавиться от мысли наращивать функционал ресурса в теме. Тема нужна для отображения контента, и все.
И третье, что плагины — это зло только в том случае, если они “криво” написаны. Плагины не плохи по своей природе. Плагин плох только тогда, когда в нем плох код.

Понравилась статья? Поделись с друзьями.
  • Add to favorites
  • Добавить ВКонтакте заметку об этой странице
  • Twitter
  • Facebook
  • Мой Мир
  • LiveJournal
  • Одноклассники
  • Блог Я.ру
  • MySpace
  • FriendFeed
  • В закладки Google
  • Google Buzz
  • Яндекс.Закладки
  • Reddit
  • StumbleUpon
  • Technorati
  • del.icio.us
  • БобрДобр
  • LinkedIn
  • Memori.ru
  • Сто закладок
  • Blogger

  • Создание плагина “Популярные статьи” - Часть 1 | Все о WEB программировании - 17.12.2012 в 22:29

    […] сайтов лучше в плагинах. Почему? Прочитайте статью “Плагины против тем в WordPress или где лучше наращивать фун…” и Вы получите ответ. Мы с Вами рассмотрели, что такое […]

  • Серега - 26.04.2013 в 20:45

    Отличные статьи) постоянно читаю про вордпресс на вашем сайте и об остальном, но больше интересует вордпресс, скажите можно от вас ждать в дальнейшем такие темы как » первести старую тему на HTML 5″ и на подобие «интернет магзин вордпресс без плагино» думаю многим будет интересно почитать мнение о опыт профессионала =)

  • Добавление JavaScript в плагин для WordPress | Все о WEB программировании - 30.10.2013 в 14:50

    […] именно плагинами. Об этом я писал в свое статье «Плагины против тем в WordPress или где лучше наращивать фун…». В серии уроков по созданию собственного плагина для […]

  • Артем - 10.02.2014 в 12:30

    Подскажите где найти вот такой плагин

  • Ускоряем WordPress | Все о WEB программировании - 09.02.2015 в 13:14

    […] Оптимизация плагинов, количество плагинов (тут больше влияние оказывает не количество, а качество плагинов). Об этом Вы можете прочитать у меня в статье «Плагины против тем в WordPress или где лучше наращивать фун…» […]

  • ©2012-2017 По всем вопросам обращайтесь через форму обратной связи

    Яндекс.Метрика