Wordpress Benefits
This publication is a response to the post “WordPress Disadvantages - The Technical Side” .
According to the author’s tradition, I’ll clarify several points:
I have never seen simpler and more elegant implementations of functionality than in WordPress. I do not believe that all CMS should be used in all projects, but, in my opinion, WordPress copes well with the tasks assigned to it and by no means without the use of OOP. The whole trick is that no one forbade the use of OOP. Many plugins are written just with its use.
But still, it's worth drawing a line in which cases it is worth using WordPress.
I personally identified the following points for myself:
- The site should be informative, without complex queries for which ORM or ActiveRecord may be required. Those. for API, statistics - I would not recommend using CMS;
- The admin panel should be taken as granted and no one will require another control panel;
- It is assumed that WordPress will cover most of the functionality, and less will need to be added (plugins, themes);
- The project is large and loud. Using WordPress in this case will only benefit both CMS developers as advertising and project developers (frequent updates, low entry threshold, ready-made solution out of the box).
In other cases, I am entirely for the use of my or other frameworks.
Further, the author gives examples.
Yes, there are certain difficulties with finding errors in different parts of the project. However, what could be simpler than using global variables? The need to pass a variable through different functions can make it difficult for a beginner to understand what is going on inside the code, just like a misunderstanding of where these variables come from. In our case, they are well known, since they are written off in a designated place and presented for granted.
I want to note that this also has its own plus. Accustomed to MVC can inadvertently cross themselves, seeing in the templates the code responsible for building queries to the database.
We will not consider those who really abuse the logic for the input parameters when building this very request (here I agree that it is better to put everything in the form of functions in the functions.php file). However, I still do not think this is something supernatural. On the contrary, the case is convenient when you can make a request in the team template by specifying post_type team.
It may seem unusual to someone that making a request can affect the further output of contextual information, but if you understand how to avoid this, the problem immediately disappears. You can avoid using get_posts or wp_reset_query. Say, if you are completely lazy, you can use a design of the form:
I do not recommend anyone to use the above code, this approach is fundamentally wrong to use.
Further, the author is indignant that all the data fit into one common table layout. The first time I came across this, I was in a slight shock. I was haunted by the thought of how to do everything so carefully that for each new entity there is no need to produce tables. Moreover, we reserve the possibility for any type of data to keep a history of changes (revisions), to be united among themselves as creating a selection of similar materials (taxonomy). We have expanded access to all data in one place.
With this point I agree. Developers could not simplify this point for beginners, without knowledge of regular expressions it is difficult to use link predefinition.
On my own I will add that in many ways rewrite functions conflict with each other. For example, a taxonomy link may conflict with an existing link to custom content type or page.
I agree that in its current form the file architecture is not very flexible. Again, I repeat, developers are not forbidden to use their own include and requre_once, to classify everything in separate subfolders for more DRY.
All thoughts about what a simple file architecture should be, often blur the boundaries of the understanding of an ordinary beginner, or, say, a designer who just needs to tweak the layout. Template naming rules structure it all.
Regarding the use of less, sass. I was very able to use them, as it is now in WordPress.
It seems to me that the author, to some extent, has only recently begun to use autoloders with namespace, encapsulation, and inheritance. At the same time, writing off the functional approach to programming the WordPress development team to try to write a decent architecture. Although, in fact, a low bow to the guys that they did not hit PHP5 Only programming and did not encapsulate everything inside classes with namespaces.
I do not argue that this approach will sooner or later become obsolete, after the release of another super simple CMS, with elements of OOP, but so far everything is extremely clear even to those who are familiar with programming by hearsay, and it’s really easy for pros to understand everything, including writing their own plugins, hooks, predetermining custom functions, without spending an extra three days behind complex documentation.
I will briefly answer that here I agree with the indignant author.
It is assumed that the declared types will be used for their intended purpose, otherwise the question arises - why should they be declared. It is clear that the author implies the use of specific types for specific images, but here another question begs - how can you be sure that the use of this image is not needed in another user case.
We must pay tribute to the developers that they did not leave it to the will of the fate of any third-party plug-in that generates pictures as needed (the same item with a pseudo-crown)
You can philosophize for a long time on the topic of patterns, algorithms, amenities ... Wait a minute, let's take into account that WP was created not for pro programmers, but for ordinary people who are interested in how they create their own blog. In this perspective, perhaps WordPress is doing its job 99%.
According to the author’s tradition, I’ll clarify several points:
- In order to clarify, I must say right away that I also intend to consider the article from the technical side, but through the prism of all developers, and not just experienced ones;
- I had to deal with many CMS, including ezpublish, which is written, almost all, with strict use of OOP. At one time he used Drupal tightly;
- Most of the time I program using third-party frameworks and am aware of what a good engine should be;
- In no case, I do not consider myself a PHP guru, I just know that real gurus will probably bypass the WordPress theme.
I have never seen simpler and more elegant implementations of functionality than in WordPress. I do not believe that all CMS should be used in all projects, but, in my opinion, WordPress copes well with the tasks assigned to it and by no means without the use of OOP. The whole trick is that no one forbade the use of OOP. Many plugins are written just with its use.
But still, it's worth drawing a line in which cases it is worth using WordPress.
I personally identified the following points for myself:
- The site should be informative, without complex queries for which ORM or ActiveRecord may be required. Those. for API, statistics - I would not recommend using CMS;
- The admin panel should be taken as granted and no one will require another control panel;
- It is assumed that WordPress will cover most of the functionality, and less will need to be added (plugins, themes);
- The project is large and loud. Using WordPress in this case will only benefit both CMS developers as advertising and project developers (frequent updates, low entry threshold, ready-made solution out of the box).
In other cases, I am entirely for the use of my or other frameworks.
Further, the author gives examples.
“Global variables are so cool, aren't they?”
Yes, there are certain difficulties with finding errors in different parts of the project. However, what could be simpler than using global variables? The need to pass a variable through different functions can make it difficult for a beginner to understand what is going on inside the code, just like a misunderstanding of where these variables come from. In our case, they are well known, since they are written off in a designated place and presented for granted.
“Would a database abstraction layer be useful to a developer?”
I want to note that this also has its own plus. Accustomed to MVC can inadvertently cross themselves, seeing in the templates the code responsible for building queries to the database.
We will not consider those who really abuse the logic for the input parameters when building this very request (here I agree that it is better to put everything in the form of functions in the functions.php file). However, I still do not think this is something supernatural. On the contrary, the case is convenient when you can make a request in the team template by specifying post_type team.
It may seem unusual to someone that making a request can affect the further output of contextual information, but if you understand how to avoid this, the problem immediately disappears. You can avoid using get_posts or wp_reset_query. Say, if you are completely lazy, you can use a design of the form:
$oldpost = $post;
// query_posts()
$post = $oldpost;
I do not recommend anyone to use the above code, this approach is fundamentally wrong to use.
Further, the author is indignant that all the data fit into one common table layout. The first time I came across this, I was in a slight shock. I was haunted by the thought of how to do everything so carefully that for each new entity there is no need to produce tables. Moreover, we reserve the possibility for any type of data to keep a history of changes (revisions), to be united among themselves as creating a selection of similar materials (taxonomy). We have expanded access to all data in one place.
“Routing with mod_rewrite”
With this point I agree. Developers could not simplify this point for beginners, without knowledge of regular expressions it is difficult to use link predefinition.
On my own I will add that in many ways rewrite functions conflict with each other. For example, a taxonomy link may conflict with an existing link to custom content type or page.
“What about file architecture?”
I agree that in its current form the file architecture is not very flexible. Again, I repeat, developers are not forbidden to use their own include and requre_once, to classify everything in separate subfolders for more DRY.
All thoughts about what a simple file architecture should be, often blur the boundaries of the understanding of an ordinary beginner, or, say, a designer who just needs to tweak the layout. Template naming rules structure it all.
Regarding the use of less, sass. I was very able to use them, as it is now in WordPress.
It seems to me that the author, to some extent, has only recently begun to use autoloders with namespace, encapsulation, and inheritance. At the same time, writing off the functional approach to programming the WordPress development team to try to write a decent architecture. Although, in fact, a low bow to the guys that they did not hit PHP5 Only programming and did not encapsulate everything inside classes with namespaces.
I do not argue that this approach will sooner or later become obsolete, after the release of another super simple CMS, with elements of OOP, but so far everything is extremely clear even to those who are familiar with programming by hearsay, and it’s really easy for pros to understand everything, including writing their own plugins, hooks, predetermining custom functions, without spending an extra three days behind complex documentation.
Pseudo Cron Tasks
I will briefly answer that here I agree with the indignant author.
"Image slicing"
It is assumed that the declared types will be used for their intended purpose, otherwise the question arises - why should they be declared. It is clear that the author implies the use of specific types for specific images, but here another question begs - how can you be sure that the use of this image is not needed in another user case.
We must pay tribute to the developers that they did not leave it to the will of the fate of any third-party plug-in that generates pictures as needed (the same item with a pseudo-crown)
Conclusion
You can philosophize for a long time on the topic of patterns, algorithms, amenities ... Wait a minute, let's take into account that WP was created not for pro programmers, but for ordinary people who are interested in how they create their own blog. In this perspective, perhaps WordPress is doing its job 99%.