High-level View of Web & WordPress Development (transcript)

Hi, my name is Alain Schlesser.
I am a web developer specializing on the WordPress platform. I have done all sorts of
development work in the past 25 years, on different platforms and in different
programming languages, and pretty much covered all but the most obscure topics in
development.
In this session, my goal is to rip you out of your day-to-day technical nitty-gritty
details and force you to consider the big picture. We web developers have a pretty
complex job with a lot of moving parts, and I often see people trying to get to grips
with small details while they still don’t grasp the fundamental basics of their job.
They have started their journey with the famous 5-minute WordPress install, or have
picked up an introductory PHP course. Maybe they even started with another CMS, or
even with static HTML files… Some even start with the WordPress Editor you can find
under Appearances.
But how many of you have started by learning what a client/server architecture is,
and how the HTTP protocol works?
1

So, as a change, instead of learning from the inside-out, as it is usually done, we’ll
start with these basics. Don’t worry, I’m not trying to flood you with specification
details here, I want to keep this as understandable and as visual as possible.
A small disclaimer: I don’t care if any of this is not 100% technically correct or omits
small details. We’re talking concepts here, not implementations. I will over-simplify
and I will use naïve analogies. So, although I appreciate any feedback, keep in mind
that we really do want to skip the details here.
1

Ok, so first of all, let’s find out who we are and what our job is really about.
Web developer build websites.
But what does it mean to “build a website” ?
Take notice that I’m currently sitting behind this very slide doing air quotes.
2

Well, here’s what we’re doing:
We PROGRAM a COMPUTER so that it can SERVE HYPERTEXT to CONNECTING
CLIENTS.
This is true for static web pages as it is for your latest WordPress showcase site.
It is a simple sentence, but it contains a lot of information already. Each of these
underlined words represents a topic that could fill dozens of books.
My hopes are that, at the end of this presentation, you’ll have a much better
understanding of this sentence, and that you can appreciate the technology that
hides behind this simple phrase.
3

We program a computer so that it can SERVE HyperText to connecting CLIENTS.
This means that the computer we program acts as a server, and it produces content
for clients.
We have a client/server architecture here.
And they communicate over the World Wide Web.
The name “World Wide Web” makes it sound as if it was a description of something
that normally has a more technical name. But it is indeed a technical specification
that defines how an information system of interlinked HyperText files is built.
The cables and routers that are connected across the globe communicate via the
Internet protocol suite, abbreviated as (TCP/IP), which is a modern variant of a
military network.
4

All the computers that wish to connect through the Internet protocol receive an IP
address.
But remembering lots of IP addresses is not very fun.
That’s why we have domains and Domain Name Servers, which can point these
domains to a given IP address.
When you enter genesis.camp into your browser, it first looks through your local
hosts file if you have defined an IP address for this domain.
If it does not find one, it connects to a Domain Name Server to get the IP address
associated with the domain. When it gets back an IP address, it can connect to that
specific computer.
5

To connect to a server, your browser typically uses the HyperText Transfer Protocol,
HTTP, or its encrypted variant, HTTPS.
We can once again find components of our sentence from the earlier slide: We
program a computer so that it serve HYPERTEXT to CONNECTING clients. So, the
HyperText Transfer Protocol was specifically built to enable connections that let you
transfer HyperText.
So, to summarize, the above address establishes a connection over the HyperText
Transfer Protocol to the computer whose IP address has been attributed to the
domain “genesis.camp”. This computer then acts as the server. But who exactly is the
client?
6

You probably guessed it. The client is the one that started the request to connect to
the server: it is your browser!
When you enter an address into your browser window, it queries the DNS server for
the IP address of the Genesis Camp server, and establishes a connection with this
server. The server then sends the content of the requested page to the browser.
7

What do you get returned to your browser when you build a connection to a server
over the HyperText Transfer Protocol? Right, a document coded in HyperText Markup
Language, or how you normally call it, an HTML file.
So this is what we want our server to serve to connecting clients. It is a text file that
has a special syntax, so that its contents can be semantically interpreted by the client.
So, the client does not get the visual representation of a website.
The client gets the HTML file, which is basically a semantical blueprint of how to
assemble the visual representation of the website.
This is an important distinction. You can contrast this to sending someone a PDF file.
The PDF file is an exact visual representation, but it can only be used as it was initially
generated. It can not be put into another context, such as adapting it to another page
format, as it lacks information on how to rebuild it. The HTML file however contains
this information only, and needs to be rebuilt for every viewing. This enables it to
adapt to a different context, but has the disadvantage that we are now at the mercy
of the client’s interpretation. So we cannot guarantee that it always looks exactly the
8

same, as would be the case with a PDF file.
8

Earlier I said that an HTML file is a text file with a special syntax. So why is it not
simply called “Text Markup Language” ? What makes it “Hyper” ?
Well, simply put, it can contain links to other files…
Yes, this sounds only moderately “hyper” nowadays, but this simple concept is what
powers the entire World Wide Web and has managed to quickly share and expand
upon knowledge over the entire globe. And when the first notions of this concept
were written down, which you can trace back to 1945, it was indeed “hyper”, or well
above and superior to regular text.
9

What does it mean, exactly, that the HTML file is a semantical blueprint?
Imagine a standard text file.
There’s no way for a computer to know how to display this in a more meaningful way.
It is only two lines of letter sequences for the computer. If the computer would want
to change the font of the paragraph text, it would not know where this paragraph
starts and where it ends, it could only guess.
So if we wrap this text in a HTML file, we still have only text at first. But HTML allows
us to add “tags” to the content, to give them a semantic meaning.
So, we can tell a computer, what the heading is, and what the paragraph text is. We
can even add metadata, which is not directly part of the content, but adds additional
semantical meaning for the computer.
We can even add attributes to the tags, to further specify what we are dealing with
here.
10

The computer now has a much better understanding of the structure of the content.
If we now ask it to display this properly, chances are much higher that it will succeed.
10

I’ve mentioned that the HTML file is a semantical blueprint. But, semantics alone are
not sufficient to rebuild a complete representation of a webpage. We’ll also need to
know about the aesthetics as well as the interactions.
The aesthetics are handled by Cascading Stylesheets, or CSS.
They can target individual elements and tell the client what visual properties these
have.
The interaction part is handled by a scripting language that can be included inside
HTML called JavaScript.
This language allows us to write real code inside the HTML file, for whatever
purposes we might need.
11

HTML allows you to put the Cascading Stylesheets, as well as the JavaScript, into
separate files, that can be linked to as external resources.
A Stylesheet that is inline will need to be completely transferred with every page
request. Same goes for the JavaScript we’ve included.
So, to keep things modular, and to allow the browser to say: “Oh, I’ve already got that
part of the site, I don’t need to download it again.”, we can put this code into
separate files and link to them from the HTML.
When you load the next page, and the browser sees “css/styles.css”, it already has a
local copy of this file and won’t download it again.
12

Another thing that modern HTML allows us to do is to adhere to a common design
principle called “Separation of Concerns”. It basically means in this context that you
should have separate isolated layers for content, presentation and interaction,
instead of mixing it all up.
As you can see in this example code, with add CSS styles as an attribute to each tag.
We have clearly mixed the content layer and the presentation layer here. This leads to
all sorts of problems. Making changes to the presentation makes you run through the
entire content, and you risk missing some instances. And for the paragraph font size,
we have duplicated information, that adds unnecessary bandwidth consumption.
But we can extract this presentation information out of the content layer and put it in
a conceptually isolated presentation layer of its own.
You can now see that the content is cleaner, we only have to look in one place if we
want to make changes to the content, and the duplicated information has gone as
well.
If we combine this with the concept of external files discussed before, we’ll get an
13

even cleaner file.
So, now our HTML is only concerned about semantic content, and delegates the rest
to other files. This basic structure forms the basis of how HTML results are laid out in
WordPress, too.
13

When the browser loads an HTML file, it goes through the source from top to bottom
and loads every external file it encounters, applies any styles it finds and executes any
scripts it finds.
It builds what is called the Document Object Model, or DOM, for this page.
This is the internal representation of the current page inside the browser’s memory. It
is an aggregated view of all the different bits and pieces we’ve referenced inside our
HTML. At the right side you can see that it has already included the style.css file.
If we change to the “Event Listeners” tab on the right , we can see that it has also
pulled in jQuery and added click handlers into the DOM.
It also loads cookies and session information, and makes them available to the page.
And as you can see here in this screenshot on the left, it can even include a complete
local database to use within JavaScript.
So the browser is much more than a simple document viewer. It is a complete
runtime engine that allows for complex applications to be transferred via an ancient
14

protocol and manages to run everything smoothly behind the scenes.
14

To have a complete website, we need different pages most of the time. A natural
progression would be to put several interlinked HTML files together on the server.
This is what we call a static website. The HTML files get generated once and remain
static from there on.
By default, when no other file is requested, the server sends the “index.html” file, so
this is typically the home page, which would then link to the other pages.
But if we look into the WordPress folder, we’re seeing another structure…
Simply put, it has no index.html file, and it runs almost everything through a single
index.php file.
Where is the rest of the site? Where can I find the “contact.html” file?
WordPress is what we call a dynamic website. The HTML files are not generated
statically, they are dynamically generated on-the-fly as they are requested. This
makes it possible to have a website where each visitor gets a completely unique
15

version of the website. For example, a logged-in user will get another version of the
site than an anonymous visitor.
This is all made possible because the website is generated on the fly through a
scripting language, which is PHP in the case of WordPress.
15

Yes, the above slide title is what the acronym PHP stands for. PHP is a recursive
acronym, it contains itself.
The important bit here is not the linguistic particularity, though, but rather the
combination of the last two words. We’re dealing with HyperText again here, so PHP
might be a good fit for our goal we set out in the beginning: serving HyperText.
The other word stands for something even a lot of experienced developers might not
be totally aware of. PHP is a preprocessor. Although it can be used as a programming
language, going so far as to producing stand-alone binaries, it is at its core a
preprocessor.
When you have an HTML file that you will run through your PHP preprocessor, you
can include PHP tags that will get executed, and the value that gets returned by the
code inside the tags gets put in place of the tag.
This lets you put dynamic code in place of the static HTML content. Because the
HTML file containing PHP tags is not complete yet and will not be sent to the client in
this form, we call this a template.
16

Although the extension might mislead you, PHP files are NOT source code files for the
PHP programming language, PHP files are HTML templates that get run through the
PHP preprocessor. Every PHP file is a more or less valid HTML file. This is the reason
why you need to start your PHP files with the opening PHP tag, even if you’re not
including any HTML.
17

If you’re omitting the starting PHP tag, your file be rendered as a slightly malformed
HTML file, even though it has a PHP extension.
18

So remember this when you come across code that looks like this. I admit, it is a
contrived example, but I found things like these more than once at the bottom of a
long PHP file.
As you can see, my text editor, which is usually smarter than me, can’t even do any
syntax highlighting for the HTML code, because we put everything in dumb strings.
Don’t do this!
19

Here’s the same file, with the PHP tags switched around.
Now we have complete syntax highlighting and code completion in all parts, so our
text editor is happy. This is much easier to maintain and to debug. So, when you find
yourself putting HTML inside your PHP into strings, that you will echo to get HTML
back out, remember that you’re working in an HTML file already, just stop your
preprocessor!
20

Uniform Resource Locators, or URLs specify the location of a resource on a computer
network and a mechanism for retrieving it.
Here’s the complete syntax for an URL.
It starts with the “scheme”. This is normally the protocol that is used to
communicate. For a normal web access, it is HTTP or HTTPS.
Then we have an optional user & password combo. This can be used for rudimentary
access security but should be avoided in favor of other means, as transmitting the
password in clear text is inherently insecure.
Now comes the domain. This can also be an IP address.
We can also add a port number to the domain. If we omit the port number, the
default port for the current scheme will be used. For HTTP, this is port 80.
Then follows the path. It tells the server behind the domain your contacting, what
resource you’re trying to get. This can be a combination of real files & folders on the
21

server, but it can also be a virtual representation of an arbitrary resource. Pretty URLs
in WordPress are an example for this, as a specific post does not exist as file on the
server, but you can nevertheless iterate this virtual representation of posts and pages.
You can add an arbitrary query string to the request by following the path with a
question mark and name/value pairs that are separated by an ampersand. These
pairs get put into GET variables and can be retrieved through PHP. As an example in
WordPress, when you use the search box, the search results page gets loaded with a
query string that contains the lowercase letter ‘s’ as the name and the text you’re
looking for as the value.
Last but not least, we have the fragment identifier, which allows you to request a
specific part or section within the resource. Within HTML files, you can target anchor
elements or ID attributes with this identifier. The browser will then immediately scroll
to the specified location within the document.
For each request, this URL specifies HOW you want to retrieve, WHERE you want to
retrieve and WHAT you want to retrieve.
21

On a typical WordPress site, the URLs do not point to physical files. As we’ve seen
earlier, the different posts and pages on our site do not have a corresponding HTML
file on the server. So, what does the URL exactly point to, in this case?
WordPress has rewrite rules in place that define a specific pattern to look for and a
URL template it can rewrite them into.
The cryptic pattern on the left are called regular expressions. I won’t bore you with
the exact details here, they are a very dark art to master. The important bit you
should note, though, is that they contain groups of symbols that are contained within
parentheses. Both of the examples shown here contain two groups. When you now
look at the URL templates in the second column, you can see that they contain a
variable called “matches” that is followed by an index. This simply means that these
variables get replaced by the corresponding groups that were found through our
pattern.
The end result, after some more dark magic has happened, is that we get a new URL
that points to a real physical file, in this case our index.php. It also includes
arguments to the PHP file so that it knows what you want it to do.
22

WordPress is a full-fledged Content Management System, or CMS. It provides website
authoring, collaboration and administration tools that allow users to manage dynamic
website content. So, you don’t produce HTML files directly, you produce the different
pieces of information that WordPress needs to produce the HTML file for you.
It has two main storage areas: The database and the filesystem.
The database contains the page content that you write for your pages and blog posts,
metadata about this content, like what category it belongs to, or at what date it was
published, user information about the users that can log into the site and make
changes and configuration data like how the widgets are laid out or what the RSS
feed will publish.
The filesystem contains the theme files that tell it how to properly display the
different pages and posts, plugin files to extend existing WordPress functionality as
well as the media files that are referenced in your pages and posts.
What does a typical request to WordPress look like, then? What does this index.php
and all of the additional code that it pulls in do?
23

Well, it considers all of its data in the context of the URL that has been requested,
runs this data through its active theme, let’s all of the active plugins do their work,
and sends the generated result to the browser.
When the page is rendered inside the browser, it contains links to external files. The
browser then requests these files from the filesystem of the server. This request
bypasses WordPress, as the index.php is not executed in this instance.
23

WordPress lets you define custom types of content. They are called Custom Post
Types, but that is a misleading name, you can use them for way more then for posts.
WordPress includes a few custom post types by default.
The last entry of these default post types might already give it away: post types in
WordPress are not really bound to content that will be displayed on a specific page. In
fact, they are not bound to being anything in particular, really.
They give you the means to store any entity in the WordPress database that you want
to be able to manage and retrieve as an individual element.
Whether you want to add a customer database, a collection of testimonials or a log
of your telephone calls to your WordPress site, you’ll use custom post types to
implement them. It does not matter, whether you display them or not, whether you
use them on the frontend, the backend, or both. They are simply a convenient way to
store data, with advanced functionality like access control or an interface for editing
already built in.
24

Custom post types get stored in the wp_posts table.
24

If you create a custom post type in WordPress, it includes a fixed set of fields that can
be stored for each entry, like the title, the content, the author, the status, and so on.
This is all information ABOUT posts. A post HAS A title. A post HAS A status. But what
if the predefined fields are not enough? Let’s say, we implemented the phone log we
talked about in the previous slide, and we now want to also store the duration of
each call. The existing fields don’t quite fit for this. So we simply add a CUSTOM
METADATA field, that gets associated with the phone calls.
So, we can store custom data inside the WordPress database, and we can store
custom attributes about this data inside the WordPress database. But there’s one
more entity you need to know about.
Custom metadata gets stored in the wp_postmeta table.
25

WordPress has two built-in taxonomies that you can use: ‘Categories’ and ‘Tags’.
Taxonomies are a way to divide your content into subsets, so you can retrieve them
easily based on this criteria.
Of course you can also create custom taxonomies, that let you define other types of
subsets. For our Phone Log example, we might want to filter the calls by Country.
Although we could add a custom metadata field for the country, this would not be the
best way to do it. Data you need for grouping should go into taxonomies, because this
lets WordPress know that the main purpose of it is to be used as a query filter, so
WordPress adds all kinds of stuff in the database to makes this faster.
So, our phone log now gets completed by adding a custom taxonomy called
“Countries”.
Custom taxonomy terms get stored in the wp_terms table, while the relationships
between terms and posts gets stored in both the wp_term_taxonomy and the
wp_term_relationships table.
26

At first glance, menus seem to be something really special in WordPress. But in terms
of their implementation, the only thing that is exceptional about them is the user
interface in which you can edit them. Apart from that, they are nothing more then a
post type, just like the pages, the posts, or our phone log.
The menu is one example of how hierarchical data is being handled by WordPress.
Other examples would be pages and categories.
The basic concept is as follows: each item has an ID that identifies it inside the table,
and also stores the ID of its parent. When you ask WordPress to generate HTML for
an hierarchical post type, it uses a piece of code that is called a Walker. The walker
goes recursively through each parent element and looks for its children.
The walker starts by retrieving the first element that has a parent ID of 0 This is the
“Categories” element, which gets rendered.
Then it looks for the first element that has the “Categories” element’s ID as a parent
ID , so the first element with a parent ID of 1. It finds the element “Cool” and renders
it. As this has a parent, it gets put on another level.
27

Then it looks for an element that has the parent ID 3. As it does not find any elements
with this parent ID, it goes back to the level above. It nows looks for the next
element with a parent ID of 1. It finds “Uncool” at renders it at the appropriate level.
Next, it checks for an element with a parent ID of 5. No element found, so it goes
back to the level above. It now looks for another element with the parent ID 1. As it
does not find more elements like this, it goes back up to the root parent 0. So now it
looks for the element that has a parent ID of 0 and finds “Tools”. “Tools” gets
rendered as another top-level item.
Now it checks for the first element with the parent ID 4 and finds “Calculator” and
renders it.
Next, it checks for elements with the parent ID 2. As it finds none, it returns to the
previous level.
It then looks for the next element with the parent ID 4 and finds “Ruler” and renders
it.
Okay… I’ll stop here. This system simply goes on until it has run out of child elements
to its root parent.
The walker has four methods that are used to render the tree: “Start level”, “End
level”, “Start Element” and “End Element”. This makes it easy to generate an
unordered HTML list, for example.
27

WordPress provides you with something called Sidebars. Unfortunately, as with most
things in WordPress, the name is misleading. As WordPress started as a blogging
platform, sidebars were exactly that: bars at the side of your blog.
So, to give you the means to insert something into this area, you get a placeholder
that can be filled with widgets, which we’ll cover later.
Most people envision Sidebars as a means to define areas somewhere on the page
where you can put stuff into. But that is not exactly what happens.
PHP and HTML files are linear , they do not have two dimensions. One element
cannot be besides another one, it can only ever be BEFORE or AFTER another
element. The browser might display elements side by side, but while you’re coding,
everything is a simple linear text file.
So, what really happens with sidebars, is that, despite their very specific name, they
are a completely generic placeholder that you can put anywhere in your HTML. You
can use a sidebar to display sidebars, of course. But you can also use a sidebar to
display a navigation bar. You can use a sidebar to display the footer. You can use a
28

sidebar to display an ad in the middle of a post. You can use a sidebar to generate
your SEO fields. You can use a sidebar to insert JavaScript into a page. You can… well,
you can do a lot of things with sidebars.
28

We mentioned widgets before when I told you that you can use them inside sidebars.
What exactly are they?
Well, you can think of them as interactive HTML snippets. Wherever they get
executed, they check their current parameters and then return an HTML snippet that
has been adapted according to these parameters.
You can freely choose in what sidebar you wish to put them.
This makes it possible to have reusable snippets of HTML that can be freely
positioned within the document using drag & drop.
29

Actions are a mechanism that allows you to place markers in your code that allows
other plugins or themes to insert their own code in addition to yours.
Here we have a rather silly example of an action that has been defined. This is done
through the do_action function. The parameter you pass to the do_action function
acts as a label of sorts. Other developers who know about this label can write code
that gets executed at that exact moment of execution.
So, let’s say we have two different functions in two different plugins.
When the code on the left gets executed, it runs through its statements like any
other normal PHP file.
When it hits the do_action function , it asks WordPress to execute all the callback
function that have been registered with the “print_footer” label.
These actions have priorities so that we have control over the order in which they are
run. When you omit to define a priority, the default value of 10 is used.
30

So, in this case, we have a function with the default priority of 10, and a function with
the priority 5. The lowest priority gets executed first, so our code execution jumps to
func2 and executes it.
Once this is done, it jumps to func1 and executes this as well.
Finally, it returns to resume normal code execution.
30

Filters are similar to hooks, in that they can be registered for a specific “label”. The
main difference is that they pass a value to the callback function, and use whatever
they get back as return value.
So in this example, we have defined a filter labelled “name_of_captain”. It allows
other plugins or themes to change the name of the captain before it is returned.
In another plugin, we could now add a callback function to this filter. Here, we change
the abbreviated name “Mal” into “Malcolm”. If we had not added this filter, the
default name would have simply been used.
Actions & Filters together are commonly referred to as hooks.
31

A WordPress Theme is basically a collection of templates. WordPress has a hierarchy
that it walks through to see what template gets called. It looks first for the most
specialized template file that could fit the current context, and the gradually looks for
more and more generic templates. If no other specialized template file is found, it
falls back to the general index.php.
Here we have the basic structure of a template file.
There are two functions that call other templates, one for the header and one for the
footer .
Between these two, we are executing something called “The Loop” within
WordPress.
32

The Loop is the mechanism that allows you to iterate through a collection of posts.
Remember that posts does not only include the built-in post type called “post”, but
all built-in and custom defined post types. So, whatever post type we’re dealing with,
we can use The Loop to cycle through it, even our Phone Log post type.
It basically works like this:
WordPress defines a global variable called $post. When you are outside The Loop,
this variable is empty.
Running The Loop inside a template starts by examining the current query to see if
the database returned some elements.
If it has, we keep cycling as long as this is true.
We now execute a function called “the_post”. This retrieves the next post and sets
up the global variable.
Now we can use the functions that render parts of the current post like the title, or
33

the <content>. These only work inside The Loop, because they retrieve their data
from the global $post variable.
Then we get back to our while condition and check if it is still true.
If it is we retrieve the next post and can then render this one too .
So, if you encounter functions where the WordPress Codex tells you that they can
only be used within The Loop, it is because they are using the global $post variable to
get their data.
33

So, after all we’ve seen, now… what are plugins, then?
To adapt WordPress to your needs, you want to be able to make lots of changes. But
changing the source file of the WordPress core itself is a bad idea, as these changes
will be overwritten with the next update.
This is why WordPress has a folder for plugins where you can put PHP files into that
contain special comments to tell WordPress that it is dealing with a plugin.
Here you can see the basic setup of such a plugin. The comments are important for
the plugin to correctly load, and you need to make sure that there’s no spelling errors
in the terms that WordPress is looking for.
What can you do inside a plugin? Well, WordPress just wants to know where to find
the entry point into your plugin, and then executes it with every request. The rest is
up to you. You can use pretty much everything that we’ve covered so far in your
plugins, and much more.
In this example, our plugin adds a callback function to the wp_header action, which
34

echoes a string when it gets called.
34

WordPress has been much more than a blogging platform for years now, and it has a
lot of great features that make it a suitable backend for not only simple websites, but
entire web applications.
You can manage all sorts of content inside your WordPress site.
This example shows a league management system. You can see that we can easily
add all elements to the WordPress database that are needed to manage the teams,
the players, the matches, and everything else.
35

Now let’s look at the frontend of this same site.
As is the case with the backend, the frontend has long been much more than a
themeable blog.
You can have full interactivity on the frontend, and even let your users change the
content in the database from the frontend, without messing with the admin
dashboard.
36

As a last topic I want to discuss the output that WordPress generates, the HTML file
that gets sent to the browser.
As I already mentioned in an earlier slide, the entire HTML output that gets sent to
the browser is one single, linear file. You don’t send a package of files that contains
HTML, images, JavaScript, and so on. Although you can include a resource inline in
the HTML file, the result will then still only be one single, linear file.
WordPress does not send any HTML content to the browser, this is all done in the
theme. Without theme, WordPress will not return anything to the browser.
So, knowing, that, if you see something on your site that you’d like to change, the
question “Can this be done with WordPress?” can always be answered with ‘yes’.
WordPress lets your theme control what gets sent to the browser, so you have
complete control over the final result. It might be a lot of work, though, if you’re
trying to go completely against what WordPress offers out-of-the-box.
Just compare the current HTML output with the future HTML output you’d like to
have. You’ll get a set of necessary changes. As long as you find a way to incorporate
37

these changes with any or all of the mechanisms I just mentioned in this session,
you’re good to go.
For good maintainability, you might prefer to make the changes in way that is update-
proof and reuses as much existing WordPress code as possible. But if WordPress does
not offer any obvious way to do it this way, you can always completely replace parts
of it. Can’t get the navigation into the shape you want it to have? Just write one from
scratch and hook it up in your theme.
Please note that I don’t want you to think that you need to replace entire parts of
WordPress all over. But it doesn’t hurt to get creative from time to time.
37

High-level View of Web & WordPress Development (transcript)

More Related Content

Similar to High-level View of Web & WordPress Development (transcript) (20)

Recently uploaded (20)

High-level View of Web & WordPress Development (transcript)