Computer Science, WordPress Development, and Laravel Development

Posted on Posted in Computer Science 101, PHP Dev, WordPress

Here I will finally analyze WordPress and Laravel, the two most popular PHP development frameworks, using my OPIE (Output Equals Process of Input plus Errors) analysis of logic as the cornerstone of computer science.

And I brought slides!

This is essentially a map the OPIE process, where, as I mentioned in my post on the Prism Effect, the setting stored in the MySQL have a dynamic behavior-altering effect on the PHP, so that the WordPress core, through plugins and settings, can behave like thousands of different things with one code base. Ultimately, the user (the admin, the web developer) inputs content (posts, pages, custom post types) into the MySQL, and inputs a theme and plugins into the WordPress core, along with core settings, plugin settings and theme settings stored in my MySQL. The output, the web pages served to the viewer, are the result of the process, the PHP code (plugin, theme, core) with its behavior altered by the settings, processing the content (posts and pages) in dynamic ways to modify and ultimately output the HTML. At an advanced level, the core template hierarchy engine chooses a template file from the theme, which template file is actually a script that executes with the viewer-requested content loaded from the MySQL, and the content is processed by that script, as well as all plugins that are called by any actions or filters in the script, to ultimately output the HTML–which is most commonly interpolated into an HTML skeleton in the theme template file. Which template is chosen is determined by the content that is requested–its type and, sometimes, its ID–which is itself determined by core by analyzing the URL parameters that are fed to it by the request routed to core through htaccess (at least, on Apache–I have yet to tweak the {incredibly misspelled} nginx).

So, what this really means is that WordPress is a process, where the user inputs content, processed by core, that leads to it being processed by plugins, and then processed by the theme, and by a template file in that theme, all of which leads to the HTML served to the viewer.

Of course, you will notice that I am being fuzzy about whether the admin, the website owner and author, or the viewer who sees the web page, is the “user.” In this end, this is merely a matter of semantics and how you look at the OPIE. If the admin is the user, the input is the content. If the viewer is the user, the input is the HTTP request URL that calls the process and results in the HTTP response that is created by WordPress processing the post, page, etc. content, as I described. The viewer’s OPIE process essentially wraps around the admin’s OPIE process.

Now, for some Lara-fun (in Laravel every word must be preceded by the Lara prefix):

This slide is my diagram of Laravel mapped to the MVC pattern I explained in a prior post. The details added here are: the URL of the request, and its parameters, defines a “Route”, the Route is a logical entity that defines a Controller, and the Controller handles the app logic and interacts with the data in the Model (the database and the classes that handle it), which in turn populates a View that defines the Response, the HTML output delivered back to the end user.

There are some technical details to Laravel, which I will dive into after my next and last slide:

The whole concept of the kernel, the container, service providers, and middleware is a little complicated. I like to think of it as the app, which is the code that the web application developer writes for the Controllers, Views, and Model, and then the coating of cake frosting that gets spread on top of the app: the middleware, and the service providers that define class objects in the container that the app uses. Basically, middleware is code that the request and response go through on their way into and out of the app–sort of like filters in WordPress. Service providers, again with a “sort of” caveat, define objects of classes for the app to use in its OOP (object-oriented programming) designs, with the container being what one should think of as the thing that brings the objects to the app. Again, remember this is all with my caveat of “sort of”, and I am, after all, merely a junior developer.

From a computer science, logic, and OPIE point of view, it is interesting that the way to “think” about a web application from a WordPress point of view is different from the way to think about it in Laravel. In Laravel, one thinks in terms of Requests and Responses, with what happens in between being the dynamic behavior of the Controller defined by the Route interacting with the Model and executing software business logic to populate the View, etc. This is all a fairly dynamic, fluid way to envision what the web application does, with only Routes, and the logical path of output from process of input defined by each Route, as the stable, enduring piece of the system–here I mean stable and enduring not in the sense of persistence of data, but in terms of there being an intelligible, cognizable element in the software logic that is established with some permanence in its role in the output equals process of input lifecycle. In contrast, in WordPress one thinks of posts and pages–actual things, actual permanent, stable objects that you can hang your hat on, blocks of text with formatting that define template output and plugin processes applied to them, even if their existence in the developer’s thought differs sharply from the reality of their existence in the code, as well as other meta-things like categories and tags. The WordPress content, the posts and pages, endure, and then all the business logic of the application is just identifying what content to process (core), processing the content (plugins) or formatting and rendering the content as output (themes). I don’t think that WordPress developers think in terms of HTTP requests and responses the same way as a Laravel developer–which is fitting, because Laravel is built on the Symfony request and response class, whereas WordPress is built around its foundation as a blog that publishes posts and a CMS that publishes pages.

This difference in thought highlights something that I have noticed–that WordPress is designed for end user happiness, to maximize end user happiness as its goal, while Laravel is designed for maximizing developer happiness as its goal. The developer in Laravel can, with a little elbow grease, have an idea of the entire logic flow of what happens to the data from the receipt of the request, through the app, to the output of the response, and make it do what he wants. In contrast, WordPress is designed to make life as easy as possible for the end user, the blogger or business owner–using themes and plugins through a GUI with no coding needed, letting the developer think in terms of blog posts and pages, which are things an end user can wrap his head around, whereas an end user doesn’t know an HTTP response from the rings of Saturn. This, perhaps, highlights the differing paths to popularity and dominance of each framework–with WordPress very popular among users, and the developers flocking the write plugins and themes for those users, whereas Laravel is surging among the developers who operate at a higher level of technical aptitude, and they will code first and find an end user base second. In that sense, if endurance requires end users, a lot of them, and their money, WordPress will have a long shelf life while Laravel still has some things it needs to do. One can use WordPress as a web application framework–if one tweaks the right themes and plugins, it is endlessly extensible–although, of course, Laravel can be used as a CMS, and customizing it is more high-energy, high-power for the true coder, the “coder’s coder”, as it were. Coder’s can love geeky coder things all we want, but in the end, the end users, their money, and the money of the business that pays for the coding to get at the end user’s money, is what defines popularity.

This emphasis on end user happiness and not on developer happiness is, perhaps, why WordPress is incredibly popular, yet it is something of a black sheep, a mark of ineptitude, when mentioned among coders who operate at a high level of technical competence. That having been said, in terms of technical sophistication, give me WordPress over C# or .NET seven days a week, and Java’s popularity is also a little bit of a leftover from the 90’s and a lot of legacy code that got exciting about the JVM, threading, etc., none of which are very exciting in 2017.

Leave a Reply

Your email address will not be published. Required fields are marked *