WordPress vs traditional HTML

Part one:  I want to take a second to explain the difference between how a WordPress site works, and a traditional site contstructed with HTML.

 

In a traditional site, each page you see in your web-browser exists as a separate file on the server. So, if you have a home (AKA Index) page, and a contact page, and a product page, you will find a file named “Index.html” and a file named “contact.html” and a file named “products.html” on your server. Think of these just like individual text files  for your word-processor. You can see each one on your drive, and open each one individually.

In a WordPress installation, however, you can search high and low, and -never- find a single page! While they may look just like traditional pages in your browser, the are not a single file at all: they are a set of instructions on how to build the page from scratch each time it is accessed, from bits and pieces which are kept in a MySQL database. Because they are rebuilt each and every time anyone accesses them,  WordPress sites are slower to load than single-page sites. (That’s why they rely on caching so much.)

WordPress sites are comprised not of “pages” but instead of “engines” –  plug-in bits of code, which are sets of instructions on how to do a particular thing, such as display a slide show, or create a calendar. These engine/plug-ins are made by many different developers, yet still must work together with every other engine. (Sometimes they do not “play nice” and the site will misbehave, or even crash.)

Because of this structure in WordPress, unlike a traditional HTML site, it is far more difficult to make a “simple change” to one “page” – there are no pages in WordPress. So while an HTML site can easily change the color of one word, or move something a tiny fraction of an inch up or down on a single page, doing so is “non-trivial” in a WordPress site, since it’s an plug-in/engine assembling the page on the fly. Which engine is it? Does that engine use the same text styling or position code elsewhere in other assemblies? (Ans: yes – it usually does.)

If I make a change to some item on a page created with HTML, only that page is affected; but on the other hand, changing the way an “engine” works may affect the entire site!

Here’s an analogy: you can get from upstate New York to NYC using either a train or taking an Uber. Each of them has a route (a “template”) on how to get there. The Uber driver’s template may have her turning on 42nd street, but you can ask her to turn on 46th, and that change to her template is quite possible. On the other hand, if you want the train to turn on 46th street, it ain’t gonna happen. One template is changeable, and the other is not. HTML is to Uber as Train is the WordPress.

 

CSS goes a long way to making it possible to fix -some- of this limitation, but not all of it. One of the main issues with changing CSS on WordPres sites, is that many plugin authors use embedded, or  “inline CSS” which has a higher priority than linked CSS, and changes made to either will be lost when the plugin is updated.  One can use a “child” theme or code in order to keed the customization, but if the plugin happens to update the code used in your child copy, then the child copy must be replaced and altered. There is also the “inportant!” key, to force over-rides, but that may or may not work, and certainly ends up with  convoluted site code.

Finally, this is why WordPress sites require virtually daily maintenance: the plug-ins are  frequently updated, as is the core of WordPress. In short, it’s a constantly moving, almost living, breathing, entity,  requiring constant attention and grooming.

However, even with these technical drawbacks, WordPress powers 1/3 of all websites on the internet. It allows non-programmers to make changes to the information displayed, or even how it’s displayed. And despite the tenuous nature of plug-ins, they are usually powerful and carefully crafted engines that add sophisticated capabilites to websites, without have to pay thousands of dollars to a developer.

I hope that helps explain things a bit.

 

Part 2: more detail and what it really looks like.

ScreenShot 2019 06 29 at 11 07 38 PM

We’re going to be looking at the code that created the page contents above.

 

Let’s compare a simple website page that merely displays a couple of short sentences. The first webpage is built traditionally, using HTML.

The second identical page is from a WordPress site.

We’re doing this to compare how the two are different, and to see why changing something as simple as text size or color is so much more complex on one than on the other.

The first thing you’ll notice is one is 13 lines long, while the other is 607 lines!

(The long one has been moved to the end.)

You don’t need to understand the code samples. Even knowing nothing about HTML, you can easily see how the color-coding is done. And if I tell you that h1 is a larger type size than h3 (and h5 is smaller yet) you can figure out that swapping one for another will change the size of the headline text.

So – here we go !

Here’s the HTML –

ScreenShot 2019 06 30 at 12 11 27 AM

 

change h1 to h3
change a color to “Gray” or “Orange”

Point here is that you can “change the template” and the change is ONLY ON THIS Page.

this page is simply a text file on your server. When your browser asks for the page, a copy of the contents of this text file is sent back.

Because it’s a text file sitting on a server, it can be edited and changed.

On the other hand…

______________________________________________________________________________________

Below is the same thing from WordPress. Notice that instead of 13 lines, there are 607*
Instead of simple direct colors and settings, there are literally hundreds of “script” lines. These are mini-programs that tell -your browser- how to create a page. In other words, the ONLY place in the whole universe that page actually exists at this moment, is in YOUR browser, assembled as it comes in. Unlike HTML, there are no text-file pages on a WordPress site.

There is no HTML file at all!

So – how do we make changes?

Obviously, we can’t reach into the user’s browser to make a change… and there is no text file to change, so our only option for customization is to change the code that is used to make the page – either the scripts themselves, or the settings they use.

You’re probably ahead of me already…but in case you’re not – there’s a problen with this: if you make such a customization, then the change will appear on -every page- that is built with the altered script, unlike HTML where only -one- page is affected.

It is possible to use page-specific CSS to over-come this limitation. The issue there is that there is Theme CSS, plugin-CSS and some plug-ins have embedded CSS, which is quite tricky to change and/or override.

*Technically, not all 607 lines of sample code below are devoted to just the lines of text. A lot of it is other stuff needed by WordPress… but that’s partly the point, isn’t it? (Additionally, some of the code below is particular to the site I was on when I generated it, but the gist of it is correct…)

Further, the huge number of lines for the most trivial few lines of displayed text, should help explain why WordPress sites use caching. Caching preassembles much of the code while it is still on the server and sends it in one call from your browser instead of requiring hundreds.

So – here you go. Compare these 600+ lines to the 13 used in traditional HTML above, and you’ll have some basic sense of how different WordPress is.

(It’s so big that I had to put the whole post into a PDF. Sorry. Here it is:

htm-vs-WP.pdf

Leave a Reply

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