Издержки функциональности приводят к тому, что проект становится очень сложно поддерживать. Вся логика, которая была заложена в проект плохо структурирована, плохо описана, в большинстве случаев лишена тестов. Если проект разрабатывал один человек, то понимание внутренней составляющей проекта уходит вместе с этим человеком. И в итоге компании достается очередной legacy code.
Возможно, ситуация, описанная мною вам знакома, возможно нет. После 5 лет разработки в экосистеме WordPress я понял, что нужно что-то менять. Нужно переосмыслить структуризацию проекта, ввести правила организации логики и вывода, решить проблему повторяемости кода. Так и родилась идея написать wordpress theme framework — Classy.
Если вы разрабатывали темы под WordPress, вы знаете, что каждый view, будь то представление того, как будет выглядеть открытая статья (single-post.php), или страница со списком всех статей (archive-post.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
L-- template-welcome.php
«Это все и мы знаем, но что ты предлагаешь?” — спросите вы. А я предлагаю простую вещь, которая с недавнего апдейта WordPress, а именно с версии 4.4 наконец стала полностью доступна — вынести все view в соответствующую папку, а в корне оставить просто index.php, который будет брать на себя весь render:
Classy::render();
и то, что раньше выглядело как:
+-- archive-rent.php
+-- single-rent.php
+-- header-rent.php
+-- footer-rent.php
L-- sidebar-rent.php
теперь выглядит как:
+-- views
¦ +-- rent
¦ ¦ +--archive.blade.php
¦ ¦ +--single.blade.php
¦ ¦ +--layout.blade.php
Организованнее? Думаю, да.
Как это работает?
Если вы знакомы с иерархией WordPress, то знаете, что при обработке запроса, он пытается найти самое специфичное представление для данного запроса и спускается вниз пока не дойдет до index.php, собственно, того файла, на который мы и поставили основной Classy::render().
В данном случае 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.
Комментарии (42)
IvanPanfilov
26.05.2016 20:36-3> Печальная правда в том, что он совершенно не приспособлен для этого.
а ваш Laravel Blade — говнище еще похуже стандартного шаблонизатора php.
потом сиди полдня разбирайся в этом говне вместо того чтоб за 5 минут поправить.
слава богу такие индивиды которые тащут всякую дрянь в WP, редко встречаются.
идите на drupal пилите — там symfony добавили для таких любителей обмазываться фрейморками.
и оставьте в покое божественный wordpress если не можете постигнуть его философию.
> Структуризация проекта в Wordpress
все там уже структурировано и продумано и нефиг лезти в тулу со своим самоваром
anrw
26.05.2016 21:03+2Философия Wordpress и не нарушалась. Все сделано на основе API которое предоставляет сам Wordpress. Что касается Laravel Blade, мне не очень понятно в чем конкретно проявляется его «говнище». Хотя преимущество его использования перед «стандартным шаблонизатором php» — очевидны. Он позволяет писать меньше кода, в особенности повторяемого кода за счет расширяемости и удобного синтаксиса. Кроме того, он по умолчанию фильтрует выводимые данные, тем самым защищая от XSS атак. В результате чего быстрее разработка и меньше багов.
anrw
26.05.2016 21:04+1В любом случае, спасибо за комментарий. Как ни странно, но это первый комментарий касательно фреймворка :)
SergeAx
27.05.2016 12:16Не боитесь использовать
composerвнутри экосистемы WP? Кто-нибудь столь же беспечный напишет развесистый плагин с использованием composer, укажет вrequireдругую версию какого-то из пакетов — и сломается или плагин, или тема, смотря кто первый загрузится.
kovalevsky
27.05.2016 16:36Вы вообще плагины под Вордпресс видели? Какой composer? Хочешь комьюнити у плагина — будь добр писать на PHP 5.2
SergeAx
02.06.2016 01:53-1Спасибо за вашу оценку моей квалификации, оставьте её при себе. Плагины и темы под WP писал и даже этим зарабатывал. Ещё вопросы?
kovalevsky
02.06.2016 11:18+1И я писал, и тоже этим зарабатывал и только ленивый не писал. Поэтому я хорошо знаю качество этих плагинов. Вы слишком переоцениваете свою квалификацию, ибо для вордпресса даже школьники умеют писать и зарабатывать на них. Ещё вопросы?
SergeAx
02.06.2016 13:17Ещё раз: своё мнение о моей квалификации оставьте при себе. С первого раза не понятно?
oxidmod
01.06.2016 09:13что и требовалось доказать:
https://habrahabr.ru/company/ua-hosting/blog/302328
oxidmod
сколько усилий для езды на мертвой лошади… удел ВП — бложики, визитки да простые магазинчики с посещаемостью 0,1 пользователь в сутки
зы. чую щас заминусуют
ззы. стремления ТС-а структурировать проект очень похвально и инструмент вполне себе. Но если есть выбор, то я предпочту чтото получше ВП
anrw
Не буду этого отрицать, ибо более чем согласен с вами. Проблема в том, что многие клиенты (хотя возможно эта специфика конкретно наших клиентов) настаивают на том, чтобы остаться на Wordpress. И их можно понять. Со стороны клиента, Wordpress — это удобная административная панель, где зачастую без дополнительных затрат можно добиться той или иной функциональности, просто установив плагин. Клиенты любят ту экосистему, которая создалась вокруг Wordpress и не хотят с нее уходить.
kucheriavij
Вот из-за таких заказчиков, которые любят установить плагин, начинаются проблемы с соседними проектами. Заказчик ни сном, ни духом установил багнутый плагин, и через него потом все проекты на хосте заражены
rhamdeew
Клиентские проекты лучше рассаживать как минимум по разным пользователям на сервере либо в идеале каждого на свою VM
aktuba
Ну да, ну да… lifehacker.ru, www.mercedes-benz.com/en/, nginx.com, techcrunch.com — это всё «бложики, визитки да простые магазинчики с посещаемостью 0,1 пользователь в сутки» )))
Просто признайтесь — не пользовались wp. Вполне себе не плохой движок, если использовать с умом. А без ума можно все что угодно угробить…
oxidmod
ох если бы, если бы… мне приходилось писать под ВП плагины и Натягивать дизайн на тему. То что под капотом не выдерживает никакой критики.
я не спорю, что на ВП можно запустить большой проект. я говорю, что усилия необходимые для того, чтобы заставить ВП работать под нагрузкой и со сложной бизнесс логикой сопоставимы с написанием такой же системы с нуля
ReZet
Скорее когда-то давным давно запускали проект и не думали, что разрастется до таких масштабов. А переписать все с нуля — обычно на такое сложно решиться. Конечно, есть извращенцы, кто и на битриксе лендинги просит. То что система для бложиков и визиток развивается — это хорошо,
Потому что с точки зрения бизнеса, лучше быстрее запуститься кое как и потом по ходу дела решать возникающие проблемы, чем с начала придумывать идеальную систему, которая все-равно в скором времени попадет под поезд правок.
makecode
Серьезно?
То есть все эти люди дураки получается?
https://wordpress.org/showcase/
Уж лучше WP чем собственная разработка «мегакулпрогеров-говнокодеров» со своими «ЦМС».
oxidmod
погуглите рейтинг ЦМС по количеству взломов.
готовы рискнуть репутацией и данными своих пользователей используя ВП?
vov1
Нужно же учитывать еще и количество проектов на CMS.
Если я не ошибаюсь Wordpress самая популярная.
aktuba
Ну тогда WP одна из самых надежных ;). Смотри: есть своя супер-система, используемая на 1-м сайте. И этот сайт взломали. Итого — 100% взломов. И есть WP используемая на миллионах сайтов. Взломали — пусть будет 50%. Что надежнее?)
А если серьезно — «нет надежных систем, есть мало изученные». Вон недавно linkedin поломали. У них не wp ;)
oxidmod
взломать можно все, но wp ломают просто на автомате. боты долбятся во все известные уязвимости и в случае успеха сообщают в центр куда удалось залить шелл или осуществить инъекцию.
aktuba
Ну так о то и речь. Ломают, чаще всего, не сам WP, а плагины/темы. Да, это проблема. Но это проблема почти всех популярных CMS, в том числе того-же drupal, который вы привели в пример. Огромная популярность + малый порог входа = кривые и дырявые плагины/расширения. При чем тут сам движок-то?)
Ну и заставить wp хорошо работать под нагрузками не такая уж и проблема. Особенно по сравнению с drupal старых версий ;)
alexkunin
Так это к любой популярной системе можно применить: давно используется? много инсталляций? есть история уязвимостей? вот скриптик, пожалте. Популярность и распространенность еще и другую сторону имеют, положительную: тонны плагинов на все случаи жизни, тонны тем, множество вопросов с ответами, к любой проблеме можно нагуглить решение.
Не так давно пришлось работать с сайтом, где был свой самопальный фреймворк (с французскими комментариями). Гугл был бесполезен, только вдумчивое курение исходников позволило как-то что-то делать. Прям как в старые добрые…
Но WP не люблю, просто приходится работать. И все эти пережитки вроде глобальных переменных, абсолютных путей и т.д. — ну поубивал бы, чесслово.
IvanPanfilov
тоесть ваша поделка априори надежна и глобальна?
oxidmod
поделка — это ВП, но если вам нравится риск, то пользуйтесь на здоровье
aktuba
Ух как категорично. Ну да, в nginx и techcrunch глупые-же люди работают, обожают риск на серверах ;)
oxidmod
«Слухи об уме и доброте дельфинов основаны на рассказах уставших пловцов, которых они толкали к берегу, но мы лишены возможности услышать рассказ тех, кого они толкали в другую сторону»
когда именно ваш бизнес развалиться изза дырки в самом ВП или сотороннем плагине или по причине того что некритичная дырка ВП наложилась на некритичную дырку плагина и открыла двери в ад, вот тогда вы пожалуй поймете почему нельзя использовать продукты класса ВП для коммерческих продуктов
aktuba
Ну точно так-же можно перефразировать: «Когда ваш бизнес развалится из-за вашей дыры, недостаточного тестирования или малого опыта вашего сотрудника, вот тогда вы пожалуй поймете, почему НЕОБХОДИМО использовать надежные и проверенные решения класса WP для коммерческих продуктов». Суть так-же самая: если руки кривые — инструмент не виноват ;)
Я использую wp последние лет 6-7 наверное. Пока что ни разу не взломали и это не смотря на то, что обновляю я его достаточно редко (примерно раз в год). Судя по логам — часто пытаются брутфорсить.
У каждого своя точка зрения и свой опыт. Мой мне говорит, что WP — хороший и надежный продукт (не смотря на старый стиль кода внутри). У вас своя. На этом и разойдемся.
oxidmod
вы передергиваете. Когда ошибка ваша, то это именно ваша ошибка и ваша отвественность. Вы взяли плохих специалистов/наговнокодили сами. Когда ошибка в стороннем плагине или стороннем решении, то страдаете вы, хотя вроде как вы то и не при чем тут. Врятли автор кривого плагина возместит вам ваши убытки.
>> Я использую wp последние лет 6-7 наверное
«Слухи об уме и доброте дельфинов основаны на рассказах уставших пловцов, которых они толкали к берегу, но мы лишены возможности услышать рассказ тех, кого они толкали в другую сторону»
прочитайте вдумчиво еще раз.
зы. да, лучше разойдемся
aktuba
>Когда ошибка в стороннем плагине или стороннем решении, то страдаете вы, хотя вроде как вы то и не при чем тут.
Как это «не при чем»? Взяли и даже не проверили? Код своих программистов тоже не проверяете? Использование любого инструмента — ваша зона ответственности, не зависимо от того, сами вы создали этот инструмент или взяли готовый.
Удивлен, что вы пользуетесь операционными системами (*nix/win). Или не пользуетесь? Они ведь дырявые ;)
>прочитайте вдумчиво еще раз.
Прочел. Подумал. Прочел еще раз. Подумал еще. Не понял, что вы хотели сказать. Доверия к wp у меня значительно больше (хотя и не абсолютно), чем ко многим другим cms и даже fw. И доверие основано не на слухах, а на опыте. Если ваши админы/программеры настолько криворуки, что допустили взлом wp — тут вам вообще мало что поможет, имхо.
oxidmod
тобишь вы при каждом апдейте вп, при каждом апдейте каждого плагина проводите полный аудит безопасности?
ну тогда вопросов нет.
зы. хотя один есть. стоимость подобного аудита
aktuba
При апдейте wp — changelog минимум просматриваю, выборочно (если что-то заинтересовало) смотрю код.
При апдейте плагинов — почти тоже самое, но более пристально. Хотя тут немного проще — плагины я использую мало и очень редко обновляю.
oxidmod
тогда, если вы почти не используете плагины, то недостающий функционал пишите сами.
если вы всеравно пишите сами, то зачем базироваться на ВП со всеми его десткими болячками, если можно писать на чемто более современном и надежном?
aktuba
Наверное потому, что я считаю wp достаточно современным и надежным для блогов ;).
Плюс, я использую мало плагинов не потому, что мне хочется писать свои, а потому что мне они вообще не нужны — стандартный функционал покрывает большинство задач. Остальные покрываю плагинами, которые да, стараюсь изучить.
По поводу болячек wp — подскажите, это что-за болячки такие?)
oxidmod
стоп-стоп. мой первый коммент в теме:
>> удел ВП — бложики, визитки да простые магазинчики…
ваш предыдущий:
>> Наверное потому, что я считаю wp достаточно современным и надежным для блогов ;).
о чем вы со мной спорите так упорно?
зы. детские болячки это смешанная логика и представление. это глобалы по коду. это отсутсвие какой либо абстракции
aktuba
А разве я где-то предлагал что-то другое?) У nginx и течкранча — именно блоги на wp.
Да и не спорю я с вами, а пытаюсь объяснить, что вы сильно не правы, когда заявляете:
1. «сколько усилий для езды на мертвой лошади…»
2. «с посещаемостью 0,1 пользователь в сутки»
Оба утверждения в корне не верны. wp живее многих других cms и вполне себе справляется с нагрузками. Ну и в плане безопасности wp даст фору многим ;).
vov1
Можете написать, что именно, почему и для каких задач?
oxidmod
для магазинов e-commerce движки (Magento, OXID)
для визиток/лендингов — статику
для црм или чегото подобного скорей всего самописное кастомное решение
даже для бложика я лучше возьму друпал новый, который не побоялся сломать обратную совместимость ради избавления от легаси кода
зы. спасибо за карму. Снова комменты раз в 5 минут
vov1
Не трогал я вашу карму. И вообще ничего плохого в альтернативном мнении не вижу.
oxidmod
за карму это не вам лично. извините если так подумали.