Wordpress Benefits
This publication is a response to the post "Wordpress flaws - the technical side . "
According to the author’s tradition, I’ll clarify a few points:
I have never seen simpler and more elegant implementations of functionality than WordPress. I do not think that this project should be used in all projects, but, in my opinion, WordPress copes well with the tasks assigned to it and not without the use of OOP. The whole point is that no one has forbidden the use of the PLO. Many plugins are written using it.
But still, it is worthwhile to draw a line in which cases WordPress should be used.
')
I personally identified the following points:
- The site should be informative, without complex requests for which you may need an ORM or ActiveRecord. Those. for API, statistics - I would not advise using CMS;
- Admin should be taken for granted and no one will require another control panel;
- It is assumed that WordPress will cover most of the functionality, and less will have to finish (plugins, themes);
- The project is big and loud. Using WordPress in this case will only play into the hands of 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 their own or other people's 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 happening inside the code, just like not understanding where these variables come from. In our case, they are well-known, as they are unsubscribed in a pre-allocated place and presented for granted.
I want to note that this also has its plus. Those who are accustomed to MVC may accidentally cross themselves when they see the code in the templates 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 query (here I agree that it is better to put everything in the form of functions into the functions.php file). However, I still do not think this is something supernatural. On the contrary, a convenient case is when a request can be made in the team template, specifying the post_type team.
It may seem unusual for someone that by making a request it may 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’re completely lazy, you can use a construction like:
I do not recommend anyone to use the above code, this approach is fundamentally wrong.
Further, the author is indignant that all the data fit into one common table schema. The first time faced with this, I was in a light shock. I was haunted by the thought of how to do everything so neatly that for every new entity you do not have to produce tables. Moreover, we retain the ability for any type of data to keep a history of changes (revisions), to be combined with each other as a collection of similar materials (taxonomy). We have expanded access to all data in one place.
With this point, I agree. Developers could not simplify this moment for beginners, without knowledge of regular expressions, it is difficult to use link predefining.
From myself I will add that in many respects rewrite functions conflict with each other. For example, a taxonomy link may conflict with an existing custom content type or page link.
I agree that in its present form the file architecture is not very flexible. Again, I repeat, it is not forbidden for developers to use their own include and requre_once, to distribute everything in classes in separate subfolders for a larger DRY.
All thoughts about what a simple file architecture should be often blur the boundaries of understanding an ordinary beginner, or, say, a designer who only needs to correct the layout. Template naming rules structure it all.
About the use of less, sass. I was perfectly able to use them, as it is now in WordPress.
It seems to me that the author, to some extent, has only recently started using autolumbers with namespaces, encapsulation, inheritance. At the same time, writing off the functional approach to programming of the WordPress development team to an attempt to write a decent architecture. Although, in fact, a low bow to the guys that they did not hit in PHP5 Only programming and did not encapsulate everything inside the classes with namespaces.
I do not argue that such an approach will sooner or later become obsolete, after the release of the next super simple CMS, with elements of the PLO, but so far everything is clear even to those who are familiar with programming by hearsay, and the pros are even less likely to easily understand everything, including writing their own plug-ins, hooks, predetermination of custom functions, without sitting out the extra three days for complex documentation.
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 arises - how can one be sure that the use of this image will not be needed in another case?
We must pay tribute to the developers that they did not leave it to the fate of any third-party plug-in that generates images as needed (the same item with a pseudo-crown)
You can philosophize on the topic of patterns, algorithms, amenities for a long time ... Wait a minute, let's take into account that WP was not created for pro programmers, but for ordinary people who are interested in how to create their own blog. In this perspective, perhaps WordPress copes with its task by all 99%.
According to the author’s tradition, I’ll clarify a few points:
- In order to clarify, I will immediately say 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 have dealt with many CMS, including ezpublish, which is written, almost all, with strict use of OOP. At one time I used Drupal tightly;
- Most of the time, I program with third-party frameworks and know what a good engine should be;
- By no means, 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 WordPress. I do not think that this project should be used in all projects, but, in my opinion, WordPress copes well with the tasks assigned to it and not without the use of OOP. The whole point is that no one has forbidden the use of the PLO. Many plugins are written using it.
But still, it is worthwhile to draw a line in which cases WordPress should be used.
')
I personally identified the following points:
- The site should be informative, without complex requests for which you may need an ORM or ActiveRecord. Those. for API, statistics - I would not advise using CMS;
- Admin should be taken for granted and no one will require another control panel;
- It is assumed that WordPress will cover most of the functionality, and less will have to finish (plugins, themes);
- The project is big and loud. Using WordPress in this case will only play into the hands of 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 their own or other people's 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 happening inside the code, just like not understanding where these variables come from. In our case, they are well-known, as they are unsubscribed in a pre-allocated place and presented for granted.
“Would a database abstraction layer be useful to a developer?”
I want to note that this also has its plus. Those who are accustomed to MVC may accidentally cross themselves when they see the code in the templates 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 query (here I agree that it is better to put everything in the form of functions into the functions.php file). However, I still do not think this is something supernatural. On the contrary, a convenient case is when a request can be made in the team template, specifying the post_type team.
It may seem unusual for someone that by making a request it may 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’re completely lazy, you can use a construction like:
$oldpost = $post; // query_posts() $post = $oldpost; I do not recommend anyone to use the above code, this approach is fundamentally wrong.
Further, the author is indignant that all the data fit into one common table schema. The first time faced with this, I was in a light shock. I was haunted by the thought of how to do everything so neatly that for every new entity you do not have to produce tables. Moreover, we retain the ability for any type of data to keep a history of changes (revisions), to be combined with each other as a collection 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 moment for beginners, without knowledge of regular expressions, it is difficult to use link predefining.
From myself I will add that in many respects rewrite functions conflict with each other. For example, a taxonomy link may conflict with an existing custom content type or page link.
“How about a file architecture?”
I agree that in its present form the file architecture is not very flexible. Again, I repeat, it is not forbidden for developers to use their own include and requre_once, to distribute everything in classes in separate subfolders for a larger DRY.
All thoughts about what a simple file architecture should be often blur the boundaries of understanding an ordinary beginner, or, say, a designer who only needs to correct the layout. Template naming rules structure it all.
About the use of less, sass. I was perfectly able to use them, as it is now in WordPress.
It seems to me that the author, to some extent, has only recently started using autolumbers with namespaces, encapsulation, inheritance. At the same time, writing off the functional approach to programming of the WordPress development team to an attempt to write a decent architecture. Although, in fact, a low bow to the guys that they did not hit in PHP5 Only programming and did not encapsulate everything inside the classes with namespaces.
I do not argue that such an approach will sooner or later become obsolete, after the release of the next super simple CMS, with elements of the PLO, but so far everything is clear even to those who are familiar with programming by hearsay, and the pros are even less likely to easily understand everything, including writing their own plug-ins, hooks, predetermination of custom functions, without sitting out the extra three days for complex documentation.
Pseudo Cron Tasks
Briefly answer that here I agree with the indignant author.
"Cutting images"
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 arises - how can one be sure that the use of this image will not be needed in another case?
We must pay tribute to the developers that they did not leave it to the fate of any third-party plug-in that generates images as needed (the same item with a pseudo-crown)
Conclusion
You can philosophize on the topic of patterns, algorithms, amenities for a long time ... Wait a minute, let's take into account that WP was not created for pro programmers, but for ordinary people who are interested in how to create their own blog. In this perspective, perhaps WordPress copes with its task by all 99%.
Source: https://habr.com/ru/post/251315/
All Articles