Project structuring in WordPress, Laravel Blade and more.
WordPress can love, you can not love, but it's hard not to agree with the fact that it solves problems. Recently, development under WordPress has gone far from creating primitive blogs with 4-5 information pages. More and more companies are using WordPress as a tool for creating full-fledged user systems with a large number of internal logic. The sad truth is that he is completely unsuited for this. But alas, the understanding of this comes only with the next launch of the project in production.
The cost of functionality leads to the fact that the project becomes very difficult to maintain. All the logic that was embedded in the project is poorly structured, poorly described, in most cases devoid of tests. If the project was developed by one person, then the understanding of the internal component of the project goes along with this person. And as a result, the company gets another legacy code.
Perhaps the situation I described to you is familiar, perhaps not. After 5 years of development in the WordPress ecosystem, I realized that I need to change something. It is necessary to rethink the structuring of the project, introduce the rules of organization of logic and output, solve the problem of code repeatability. So the idea was born to write wordpress theme framework - Classy.
')
If you developed themes under WordPress, you know that every view, be it a presentation of how an open article will look like (single-post.php), or a page with a list of all articles (archive-post.php), requires a representation in the main topic directories. Such a decision may make sense with a simple project, but as soon as the project becomes cluttered with logic, it becomes a problem.
“That's all we know, but what do you suggest?” - you ask. And I propose a simple thing, which from the recent WordPress update, namely from version 4.4, has finally become fully accessible - to put the whole view in the appropriate folder, and to leave just the root index.php, which will take over the entire render:
and what used to look like:
Archive── archive-rent.php
Single── single-rent.php
Header── header-rent.php
F── footer-rent.php
Side── sidebar-rent.php
now looks like:
Views── views
Rent ├── rent
│ │ ├──archive.blade.php
│ │ ├─single.blade.php
│ │ ├─layout.blade.php
Organized? I think yes.
If you are familiar with the WordPress hierarchy, then you know that when processing a request, it tries to find the most specific presentation for this request and goes down until it reaches index.php, in fact, the file that we set the main Classy :: render ()
In this case, Classy :: render performs two functions, one for searching the view (ClassyView :: get_template ()) and another for searching the scope (ClassyScope :: get_scope ()). These 2 functions repeat the search algorithm for the view that wordpress uses, but they do it separately, twice. This allows us to have an independent view and data architecture.
Why, you ask? Very often there are situations when developing, when the same data needs to be displayed differently. For example, we have a lot of templates that are nothing more than a kind of design for page.php. So why not write once the data in scope / page.php and just develop separate views for templates: view / page / dark.php, view / page / light.php, etc. As a result, we reduce the amount of repeated code, since the scope is prepared once.
Oh yeah, I forgot to tell you about it. WordPress 4.4 finally has the opportunity to modify the list of templates that are displayed to the user in the administrative panel. Now, thanks to the theme_page_templates hook , we can rewrite this list and add our newly registered templates to it.
And they are registered very simply. For example, we want to create an about template. To do this, we create the view / page / about.blade.php view and specify Template Name: About at the top of the file. That is, ultimately, our view will look like this:
Unfortunately, WordPress does not use the default data abstraction layers, but it is necessary.
Instead of writing the next prefix_vendor_get_posts, why not use the Vendor class as a model, and get_posts as its usual method. This seemingly simple way will save you a lot of energy while supporting the project, and, most importantly, it will allow you to write functionality with fewer bugs.
In our case there is a model - ClassyPost, which can be extended by any other model to custom post type.
Using a template engine in the development of WordPress is everyone’s business, but experience has shown that it helps reduce project development time, making it more structured, and making code pleasant and easy to read. Until recently, I used Timber, which is an implementation of the template engine - Twig, but it has a number of drawbacks:
1) Perform php functions. I think here you can do without comments, because it looks like this:
While Laravel Blade allows you to execute php code and the same function will look like this:
2) Speed. Timber is not the fastest framework and its main problem is functional overload. On small projects, this is not noticeable, but when you deal with projects with more attendance, it becomes a pain point. My idea was to keep the framework minimalist, so that there was only what was really used in the project.
The Classy project is completely open-source. My initial idea was to help solve the problem of project organization in WordPress, which I and my colleagues encounter, and I hope this implementation will help others. In the current implementation bugs are possible, but I will actively work to eliminate them. I look forward to your feedback on the work done.
GitHub repository .
The cost of functionality leads to the fact that the project becomes very difficult to maintain. All the logic that was embedded in the project is poorly structured, poorly described, in most cases devoid of tests. If the project was developed by one person, then the understanding of the internal component of the project goes along with this person. And as a result, the company gets another legacy code.
Perhaps the situation I described to you is familiar, perhaps not. After 5 years of development in the WordPress ecosystem, I realized that I need to change something. It is necessary to rethink the structuring of the project, introduce the rules of organization of logic and output, solve the problem of code repeatability. So the idea was born to write wordpress theme framework - Classy.
')
If you developed themes under WordPress, you know that every view, be it a presentation of how an open article will look like (single-post.php), or a page with a list of all articles (archive-post.php), requires a representation in the main topic directories. Such a decision may make sense with a simple project, but as soon as the project becomes cluttered with logic, it becomes a problem.
An example of the number of files on an average project complexity:
40── 404.php
RE── README
Archive── archive-gallery.php
Archive── archive-inspiration.php
Archive── archive-rent.php
Archive── archive-vendor.php
Attach── attachment.php
Category── category.php
Comments── comments.php
F── footer-rent.php
F── footer-vendor.php
├── footer.php
Functions── functions.php
G── gulpfile.js
Header── header-rent.php
Header── header-vendor.php
Header── header.php
Image── image.php
Index── index.php
Page── page-diy-ideas.php
Page── page-edit-vendor-profile.php
Page── page-local-blogs.php
Page── page-login.php
Page── page-my-favorites.php
Page── page-my-listings.php
Page── page-my-messages.php
Page── page-my-profile.php
Page── page-new-listing.php
Page── page-password-reset.php
Page── page-register.php
Page── page-vendor-guide.php
Page── page-vendors.php
Page── page-wedding-ideas.php
Page── page.php
├── screenshot.png
Search── search.php
Search── searchform.php
Side── sidebar-home.php
Side── sidebar-rent.php
Side── sidebar-vendor.php
Side── sidebar-filters.php
Side── sidebar-general.php
Side── sidebar-user.php
Single── single-inspiration.php
Single── single-rent.php
Single── single-gallery.php
Single── single-vendor.php
Single── single.php
Style── style.css
Tag── tag.php
Tax── taxonomy-location.php
Template── template-about.php
Template── template-activate-account.php
Template── template-become-a-member.php
Template── template-contact.php
Template── template-default.php
Template── template-faq.php
Template── template-grab-a-badge.php
Template── template-map.php
Template── template-new-inspiration.php
Template── template-new-rent.php
Template── template-welcome.php
RE── README
Archive── archive-gallery.php
Archive── archive-inspiration.php
Archive── archive-rent.php
Archive── archive-vendor.php
Attach── attachment.php
Category── category.php
Comments── comments.php
F── footer-rent.php
F── footer-vendor.php
├── footer.php
Functions── functions.php
G── gulpfile.js
Header── header-rent.php
Header── header-vendor.php
Header── header.php
Image── image.php
Index── index.php
Page── page-diy-ideas.php
Page── page-edit-vendor-profile.php
Page── page-local-blogs.php
Page── page-login.php
Page── page-my-favorites.php
Page── page-my-listings.php
Page── page-my-messages.php
Page── page-my-profile.php
Page── page-new-listing.php
Page── page-password-reset.php
Page── page-register.php
Page── page-vendor-guide.php
Page── page-vendors.php
Page── page-wedding-ideas.php
Page── page.php
├── screenshot.png
Search── search.php
Search── searchform.php
Side── sidebar-home.php
Side── sidebar-rent.php
Side── sidebar-vendor.php
Side── sidebar-filters.php
Side── sidebar-general.php
Side── sidebar-user.php
Single── single-inspiration.php
Single── single-rent.php
Single── single-gallery.php
Single── single-vendor.php
Single── single.php
Style── style.css
Tag── tag.php
Tax── taxonomy-location.php
Template── template-about.php
Template── template-activate-account.php
Template── template-become-a-member.php
Template── template-contact.php
Template── template-default.php
Template── template-faq.php
Template── template-grab-a-badge.php
Template── template-map.php
Template── template-new-inspiration.php
Template── template-new-rent.php
Template── template-welcome.php
“That's all we know, but what do you suggest?” - you ask. And I propose a simple thing, which from the recent WordPress update, namely from version 4.4, has finally become fully accessible - to put the whole view in the appropriate folder, and to leave just the root index.php, which will take over the entire render:
Classy::render(); and what used to look like:
Archive── archive-rent.php
Single── single-rent.php
Header── header-rent.php
F── footer-rent.php
Side── sidebar-rent.php
now looks like:
Views── views
Rent ├── rent
│ │ ├──archive.blade.php
│ │ ├─single.blade.php
│ │ ├─layout.blade.php
Organized? I think yes.
How it works?
If you are familiar with the WordPress hierarchy, then you know that when processing a request, it tries to find the most specific presentation for this request and goes down until it reaches index.php, in fact, the file that we set the main Classy :: render ()
In this case, Classy :: render performs two functions, one for searching the view (ClassyView :: get_template ()) and another for searching the scope (ClassyScope :: get_scope ()). These 2 functions repeat the search algorithm for the view that wordpress uses, but they do it separately, twice. This allows us to have an independent view and data architecture.
Why, you ask? Very often there are situations when developing, when the same data needs to be displayed differently. For example, we have a lot of templates that are nothing more than a kind of design for page.php. So why not write once the data in scope / page.php and just develop separate views for templates: view / page / dark.php, view / page / light.php, etc. As a result, we reduce the amount of repeated code, since the scope is prepared once.
So what's up with WordPress 4.4?
Oh yeah, I forgot to tell you about it. WordPress 4.4 finally has the opportunity to modify the list of templates that are displayed to the user in the administrative panel. Now, thanks to the theme_page_templates hook , we can rewrite this list and add our newly registered templates to it.
And they are registered very simply. For example, we want to create an about template. To do this, we create the view / page / about.blade.php view and specify Template Name: About at the top of the file. That is, ultimately, our view will look like this:
{{-- 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 Concept models
Unfortunately, WordPress does not use the default data abstraction layers, but it is necessary.
Instead of writing the next prefix_vendor_get_posts, why not use the Vendor class as a model, and get_posts as its usual method. This seemingly simple way will save you a lot of energy while supporting the project, and, most importantly, it will allow you to write functionality with fewer bugs.
In our case there is a model - ClassyPost, which can be extended by any other model to custom post type.
Laravel blade
Using a template engine in the development of WordPress is everyone’s business, but experience has shown that it helps reduce project development time, making it more structured, and making code pleasant and easy to read. Until recently, I used Timber, which is an implementation of the template engine - Twig, but it has a number of drawbacks:
1) Perform php functions. I think here you can do without comments, because it looks like this:
{{function('edit_post_link', 'Edit', '<span class="edit-link">', '</span>')}} While Laravel Blade allows you to execute php code and the same function will look like this:
{{ edit_post_link('Edit', '<span class="edit-link">', '</span>') }} 2) Speed. Timber is not the fastest framework and its main problem is functional overload. On small projects, this is not noticeable, but when you deal with projects with more attendance, it becomes a pain point. My idea was to keep the framework minimalist, so that there was only what was really used in the project.
Conclusion
The Classy project is completely open-source. My initial idea was to help solve the problem of project organization in WordPress, which I and my colleagues encounter, and I hope this implementation will help others. In the current implementation bugs are possible, but I will actively work to eliminate them. I look forward to your feedback on the work done.
GitHub repository .
Source: https://habr.com/ru/post/301848/
All Articles