Структуризация проекта в WordPress, Laravel Blade и не только

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

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

Возможно, ситуация, описанная мною вам знакома, возможно нет. После 5 лет разработки в экосистеме WordPress я понял, что нужно что-то менять. Нужно переосмыслить структуризацию проекта, ввести правила организации логики и вывода, решить проблему повторяемости кода. Так и родилась идея написать wordpress theme framework — Classy.

image

Если вы разрабатывали темы под WordPress, вы знаете, что каждый view, будь то представление того, как будет выглядеть открытая статья (single-post.php), или страница со списком всех статей (archive-post.php), требует репрезентации в основной директории темы. Подобное решение возможно имеет смысл при несложном проекте, но как только проект обрастает логикой — это становится проблемой.

Пример количества файлов на средней сложности проекте:
├── 404.php
├── README
├── archive-gallery.php
├── archive-inspiration.php
├── archive-rent.php
├── archive-vendor.php
├── attachment.php
├── category.php
├── comments.php
├── footer-rent.php
├── footer-vendor.php
├── footer.php
├── functions.php
├── gulpfile.js
├── header-rent.php
├── header-vendor.php
├── header.php
├── image.php
├── index.php
├── page-diy-ideas.php
├── page-edit-vendor-profile.php
├── page-local-blogs.php
├── page-login.php
├── page-my-favorites.php
├── page-my-listings.php
├── page-my-messages.php
├── page-my-profile.php
├── page-new-listing.php
├── page-password-reset.php
├── page-register.php
├── page-vendor-guide.php
├── page-vendors.php
├── page-wedding-ideas.php
├── page.php
├── screenshot.png
├── search.php
├── searchform.php
├── sidebar-home.php
├── sidebar-rent.php
├── sidebar-vendor.php
├── sidebar-filters.php
├── sidebar-general.php
├── sidebar-user.php
├── single-inspiration.php
├── single-rent.php
├── single-gallery.php
├── single-vendor.php
├── single.php
├── style.css
├── tag.php
├── taxonomy-location.php
├── template-about.php
├── template-activate-account.php
├── template-become-a-member.php
├── template-contact.php
├── template-default.php
├── template-faq.php
├── template-grab-a-badge.php
├── template-map.php
├── template-new-inspiration.php
├── template-new-rent.php
└── template-welcome.php

«Это все и мы знаем, но что ты предлагаешь?” — спросите вы. А я предлагаю простую вещь, которая с недавнего апдейта WordPress, а именно с версии 4.4 наконец стала полностью доступна — вынести все view в соответствующую папку, а в корне оставить просто index.php, который будет брать на себя весь render:

Classy::render();

и то, что раньше выглядело как:

├── archive-rent.php
├── single-rent.php
├── header-rent.php
├── footer-rent.php
└── sidebar-rent.php

теперь выглядит как:

├── views
│ ├── rent
│ │ ├──archive.blade.php
│ │ ├──single.blade.php
│ │ ├──layout.blade.php

Организованнее? Думаю, да.

Как это работает?


Если вы знакомы с иерархией WordPress, то знаете, что при обработке запроса, он пытается найти самое специфичное представление для данного запроса и спускается вниз пока не дойдет до index.php, собственно, того файла, на который мы и поставили основной Classy::render().

image

В данном случае Classy::render выполняет две функции, одну для поиска view (ClassyView::get_template()) и другую для поиска scope (ClassyScope::get_scope()). Эти 2 функции, повторяют алгоритм поиска view который используют wordpress, но делают они это раздельно, дважды. Это позволяет нам иметь независимую архитектуру представления и данных.

Зачем, спросите вы? Очень часто возникают ситуации при разработке, когда одни и те же данные необходимо отобразить по-разному. К примеру, у нас есть множество templates, которые являются не более, чем разновидностью дизайна для page.php. Так почему же не прописать один раз данные в scope/page.php и просто разработать отдельные view для templates: view/page/dark.php, view/page/light.php, и т.д. Вследствие этого, мы уменьшаем количество повторяемого кода, так как scope у нас приготавливается единожды.

Так что там с WordPress 4.4?


Ах да, совсем забыл рассказать про это. В WordPress 4.4 наконец-то появилась возможность модифицировать список шаблонов, которые отображаются пользователю в административной панели. Теперь, благодаря хуку “theme_page_templates”, мы можем этот список переписывать и добавлять в него наши зарегистрированные по новому способу шаблоны.

А регистрируются они очень просто. К примеру, мы хотим создать шаблон about. Для этого мы создаем представление view/page/about.blade.php и вверху файла указываем Template Name: About. То есть, в конечном счете, наш view будет выглядеть так:

{{-- Template Name: About --}}

@extends('base.default')

@section('content')
    @if ($post)
        <article class=“about">
            <h1>{{ $post->title() }}</h1>

            <section class="body">
                {{ $post->content() }}
            </section>
        </article>
    @endif
@stop


Концепция моделей


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

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

В нашем случае есть модель — ClassyPost, которую может расширить любая другая модель custom post type.

Laravel Blade


Использование template engine в разработке WordPress — дело каждого, но опыт показал, что он помогает уменьшить время разработки проекта, делая его более структурированным, а код приятным и легким для чтения. До недавних пор я использовал Timber, который является имплементацией template engine — Twig, но в нем есть ряд минусов:

1) Выполнение php функций. Думаю тут можно обойтись без комментариев, потому что оно выглядит вот так:

{{function('edit_post_link', 'Edit', '<span class="edit-link">', '</span>')}}

В то время, как Laravel Blade позволяет выполнять php код и та же самая функция будет выглядеть так:

{{ edit_post_link('Edit', '<span class="edit-link">', '</span>') }}

2) Скорость. Timber не самый быстрый фреймворк и его основной проблемой является перегруженность функционалом. На маленьких проектах это незаметно, но когда вы имеете дело с проектами с большей посещаемостью — это становится болевой точкой. Моей же идеей было сохранить минималистичность фреймворка, чтобы там было только то, что действительно используется в проекте.

Заключение


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

Репозиторий в GitHub.
Поделиться публикацией
Похожие публикации
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама
Комментарии 42
  • +3

    сколько усилий для езды на мертвой лошади… удел ВП — бложики, визитки да простые магазинчики с посещаемостью 0,1 пользователь в сутки
    зы. чую щас заминусуют
    ззы. стремления ТС-а структурировать проект очень похвально и инструмент вполне себе. Но если есть выбор, то я предпочту чтото получше ВП

    • 0
      Не буду этого отрицать, ибо более чем согласен с вами. Проблема в том, что многие клиенты (хотя возможно эта специфика конкретно наших клиентов) настаивают на том, чтобы остаться на Wordpress. И их можно понять. Со стороны клиента, Wordpress — это удобная административная панель, где зачастую без дополнительных затрат можно добиться той или иной функциональности, просто установив плагин. Клиенты любят ту экосистему, которая создалась вокруг Wordpress и не хотят с нее уходить.
      • 0
        Вот из-за таких заказчиков, которые любят установить плагин, начинаются проблемы с соседними проектами. Заказчик ни сном, ни духом установил багнутый плагин, и через него потом все проекты на хосте заражены
        • 0
          Клиентские проекты лучше рассаживать как минимум по разным пользователям на сервере либо в идеале каждого на свою VM
      • +1
        Ну да, ну да… lifehacker.ru, www.mercedes-benz.com/en/, nginx.com, techcrunch.com — это всё «бложики, визитки да простые магазинчики с посещаемостью 0,1 пользователь в сутки» )))
        Просто признайтесь — не пользовались wp. Вполне себе не плохой движок, если использовать с умом. А без ума можно все что угодно угробить…
        • 0
          ох если бы, если бы… мне приходилось писать под ВП плагины и Натягивать дизайн на тему. То что под капотом не выдерживает никакой критики.
          я не спорю, что на ВП можно запустить большой проект. я говорю, что усилия необходимые для того, чтобы заставить ВП работать под нагрузкой и со сложной бизнесс логикой сопоставимы с написанием такой же системы с нуля
          • 0
            Скорее когда-то давным давно запускали проект и не думали, что разрастется до таких масштабов. А переписать все с нуля — обычно на такое сложно решиться. Конечно, есть извращенцы, кто и на битриксе лендинги просит. То что система для бложиков и визиток развивается — это хорошо,

            Потому что с точки зрения бизнеса, лучше быстрее запуститься кое как и потом по ходу дела решать возникающие проблемы, чем с начала придумывать идеальную систему, которая все-равно в скором времени попадет под поезд правок.
        • 0
          Серьезно?
          То есть все эти люди дураки получается?
          https://wordpress.org/showcase/

          Уж лучше WP чем собственная разработка «мегакулпрогеров-говнокодеров» со своими «ЦМС».
          • 0
            погуглите рейтинг ЦМС по количеству взломов.
            готовы рискнуть репутацией и данными своих пользователей используя ВП?
            • +1
              Нужно же учитывать еще и количество проектов на CMS.
              Если я не ошибаюсь Wordpress самая популярная.
              • 0
                Ну тогда WP одна из самых надежных ;). Смотри: есть своя супер-система, используемая на 1-м сайте. И этот сайт взломали. Итого — 100% взломов. И есть WP используемая на миллионах сайтов. Взломали — пусть будет 50%. Что надежнее?)

                А если серьезно — «нет надежных систем, есть мало изученные». Вон недавно linkedin поломали. У них не wp ;)
                • 0
                  взломать можно все, но wp ломают просто на автомате. боты долбятся во все известные уязвимости и в случае успеха сообщают в центр куда удалось залить шелл или осуществить инъекцию.
                  • 0
                    Ну так о то и речь. Ломают, чаще всего, не сам WP, а плагины/темы. Да, это проблема. Но это проблема почти всех популярных CMS, в том числе того-же drupal, который вы привели в пример. Огромная популярность + малый порог входа = кривые и дырявые плагины/расширения. При чем тут сам движок-то?)

                    Ну и заставить wp хорошо работать под нагрузками не такая уж и проблема. Особенно по сравнению с drupal старых версий ;)
                    • НЛО прилетело и опубликовало эту надпись здесь
                  • 0
                    тоесть ваша поделка априори надежна и глобальна?
                    • 0
                      поделка — это ВП, но если вам нравится риск, то пользуйтесь на здоровье
                      • 0
                        Ух как категорично. Ну да, в nginx и techcrunch глупые-же люди работают, обожают риск на серверах ;)
                        • 0
                          «Слухи об уме и доброте дельфинов основаны на рассказах уставших пловцов, которых они толкали к берегу, но мы лишены возможности услышать рассказ тех, кого они толкали в другую сторону»

                          когда именно ваш бизнес развалиться изза дырки в самом ВП или сотороннем плагине или по причине того что некритичная дырка ВП наложилась на некритичную дырку плагина и открыла двери в ад, вот тогда вы пожалуй поймете почему нельзя использовать продукты класса ВП для коммерческих продуктов
                          • 0
                            Ну точно так-же можно перефразировать: «Когда ваш бизнес развалится из-за вашей дыры, недостаточного тестирования или малого опыта вашего сотрудника, вот тогда вы пожалуй поймете, почему НЕОБХОДИМО использовать надежные и проверенные решения класса WP для коммерческих продуктов». Суть так-же самая: если руки кривые — инструмент не виноват ;)

                            Я использую wp последние лет 6-7 наверное. Пока что ни разу не взломали и это не смотря на то, что обновляю я его достаточно редко (примерно раз в год). Судя по логам — часто пытаются брутфорсить.

                            У каждого своя точка зрения и свой опыт. Мой мне говорит, что WP — хороший и надежный продукт (не смотря на старый стиль кода внутри). У вас своя. На этом и разойдемся.
                            • 0
                              вы передергиваете. Когда ошибка ваша, то это именно ваша ошибка и ваша отвественность. Вы взяли плохих специалистов/наговнокодили сами. Когда ошибка в стороннем плагине или стороннем решении, то страдаете вы, хотя вроде как вы то и не при чем тут. Врятли автор кривого плагина возместит вам ваши убытки.

                              >> Я использую wp последние лет 6-7 наверное
                              «Слухи об уме и доброте дельфинов основаны на рассказах уставших пловцов, которых они толкали к берегу, но мы лишены возможности услышать рассказ тех, кого они толкали в другую сторону»

                              прочитайте вдумчиво еще раз.
                              зы. да, лучше разойдемся
                              • 0
                                >Когда ошибка в стороннем плагине или стороннем решении, то страдаете вы, хотя вроде как вы то и не при чем тут.

                                Как это «не при чем»? Взяли и даже не проверили? Код своих программистов тоже не проверяете? Использование любого инструмента — ваша зона ответственности, не зависимо от того, сами вы создали этот инструмент или взяли готовый.

                                Удивлен, что вы пользуетесь операционными системами (*nix/win). Или не пользуетесь? Они ведь дырявые ;)

                                >прочитайте вдумчиво еще раз.

                                Прочел. Подумал. Прочел еще раз. Подумал еще. Не понял, что вы хотели сказать. Доверия к wp у меня значительно больше (хотя и не абсолютно), чем ко многим другим cms и даже fw. И доверие основано не на слухах, а на опыте. Если ваши админы/программеры настолько криворуки, что допустили взлом wp — тут вам вообще мало что поможет, имхо.
                                • 0
                                  тобишь вы при каждом апдейте вп, при каждом апдейте каждого плагина проводите полный аудит безопасности?
                                  ну тогда вопросов нет.
                                  зы. хотя один есть. стоимость подобного аудита
                                  • 0
                                    При апдейте wp — changelog минимум просматриваю, выборочно (если что-то заинтересовало) смотрю код.
                                    При апдейте плагинов — почти тоже самое, но более пристально. Хотя тут немного проще — плагины я использую мало и очень редко обновляю.
                                    • 0
                                      тогда, если вы почти не используете плагины, то недостающий функционал пишите сами.
                                      если вы всеравно пишите сами, то зачем базироваться на ВП со всеми его десткими болячками, если можно писать на чемто более современном и надежном?
                                      • 0
                                        Наверное потому, что я считаю wp достаточно современным и надежным для блогов ;).
                                        Плюс, я использую мало плагинов не потому, что мне хочется писать свои, а потому что мне они вообще не нужны — стандартный функционал покрывает большинство задач. Остальные покрываю плагинами, которые да, стараюсь изучить.

                                        По поводу болячек wp — подскажите, это что-за болячки такие?)
                                        • +1
                                          стоп-стоп. мой первый коммент в теме:
                                          >> удел ВП — бложики, визитки да простые магазинчики…

                                          ваш предыдущий:
                                          >> Наверное потому, что я считаю wp достаточно современным и надежным для блогов ;).

                                          о чем вы со мной спорите так упорно?

                                          зы. детские болячки это смешанная логика и представление. это глобалы по коду. это отсутсвие какой либо абстракции
                                          • 0
                                            А разве я где-то предлагал что-то другое?) У nginx и течкранча — именно блоги на wp.
                                            Да и не спорю я с вами, а пытаюсь объяснить, что вы сильно не правы, когда заявляете:

                                            1. «сколько усилий для езды на мертвой лошади…»
                                            2. «с посещаемостью 0,1 пользователь в сутки»

                                            Оба утверждения в корне не верны. wp живее многих других cms и вполне себе справляется с нагрузками. Ну и в плане безопасности wp даст фору многим ;).
                • 0
                  Но если есть выбор, то я предпочту чтото получше ВП

                  Можете написать, что именно, почему и для каких задач?
                  • 0
                    для магазинов e-commerce движки (Magento, OXID)
                    для визиток/лендингов — статику
                    для црм или чегото подобного скорей всего самописное кастомное решение
                    даже для бложика я лучше возьму друпал новый, который не побоялся сломать обратную совместимость ради избавления от легаси кода

                    зы. спасибо за карму. Снова комменты раз в 5 минут
                    • 0
                      Не трогал я вашу карму. И вообще ничего плохого в альтернативном мнении не вижу.
                      • 0
                        за карму это не вам лично. извините если так подумали.
                • –3
                  > Печальная правда в том, что он совершенно не приспособлен для этого.

                  а ваш Laravel Blade — говнище еще похуже стандартного шаблонизатора php.
                  потом сиди полдня разбирайся в этом говне вместо того чтоб за 5 минут поправить.
                  слава богу такие индивиды которые тащут всякую дрянь в WP, редко встречаются.
                  идите на drupal пилите — там symfony добавили для таких любителей обмазываться фрейморками.
                  и оставьте в покое божественный wordpress если не можете постигнуть его философию.

                  > Структуризация проекта в Wordpress
                  все там уже структурировано и продумано и нефиг лезти в тулу со своим самоваром
                  • +2
                    Философия Wordpress и не нарушалась. Все сделано на основе API которое предоставляет сам Wordpress. Что касается Laravel Blade, мне не очень понятно в чем конкретно проявляется его «говнище». Хотя преимущество его использования перед «стандартным шаблонизатором php» — очевидны. Он позволяет писать меньше кода, в особенности повторяемого кода за счет расширяемости и удобного синтаксиса. Кроме того, он по умолчанию фильтрует выводимые данные, тем самым защищая от XSS атак. В результате чего быстрее разработка и меньше багов.
                    • +1
                      В любом случае, спасибо за комментарий. Как ни странно, но это первый комментарий касательно фреймворка :)
                    • 0

                      Не боитесь использовать composer внутри экосистемы WP? Кто-нибудь столь же беспечный напишет развесистый плагин с использованием composer, укажет в require другую версию какого-то из пакетов — и сломается или плагин, или тема, смотря кто первый загрузится.

                      • 0
                        Вы вообще плагины под Вордпресс видели? Какой composer? Хочешь комьюнити у плагина — будь добр писать на PHP 5.2
                        • –1

                          Спасибо за вашу оценку моей квалификации, оставьте её при себе. Плагины и темы под WP писал и даже этим зарабатывал. Ещё вопросы?

                          • +1
                            И я писал, и тоже этим зарабатывал и только ленивый не писал. Поэтому я хорошо знаю качество этих плагинов. Вы слишком переоцениваете свою квалификацию, ибо для вордпресса даже школьники умеют писать и зарабатывать на них. Ещё вопросы?
                            • 0
                              Ещё раз: своё мнение о моей квалификации оставьте при себе. С первого раза не понятно?
                              • 0
                                Ох уж это быдло из read-only
                                • 0
                                  Отлично. Продолжайте переход на личности, если по сути ответить нечего.
                      • 0
                        что и требовалось доказать:
                        https://habrahabr.ru/company/ua-hosting/blog/302328

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