Lesson 1: Client and Server Infrastructure: File, Web, Database Tools vs. WordPress

ByDr.-Ing. Erik Neitzel
Lesson 1: Client and Server Infrastructure: File, Web, Database Tools vs. WordPress

This lesson takes you by the hand and shows which client and server side components you need and what ways exist in order to successfully build a database supported web application. We will also point out what it is that WordPress already addresses and how the contents of this lesson can help you sort out problems with your Blog.

The overall architecture

First of all, let’s take a look at the overall architecture we’re dealing with while developing:

Overall Architecture

Our client provides us with a web browser that can interpret HTML and, if needed, JavaScript scripts. All that is done at the client side with no server interaction after initially receiving the files in question.

Then, still on our client, we either have an editor to create our files locally, or a terminal application which lets us develop code remotely. I will cover this in a second.

We already mentioned the files that can or often need to be created locally, e.g. HTML markup, PHP code, JavaScript code or images (JPG, PNG, etc.). All the files we’re creating locally (on the client side) need to be transferred to the server, where it can be deployed to other people’s web browsers.

That transfer from our developer client to the server is done using file transfer client tools such as WinSCP (Windows) or Cyberduck (OSX). They support different protocols such as FTP or SSH, depending on your preferred way of communication and the abilities of your server.

Now let’s take a look at how your development can take place.

The client-driven way to develop

There are various ways to develop. One way is in favor of the client. You can use a local editor application at your desktop in order to create all kinds of code, e.g. Textpad. You then need to transfer that code to the server using your file transfer client, e.g. WinSCP. That application then contacts the file service on the server you want to send files to, possibly running an ProFTPd (the counterpart of your file transfer process, which is not interesting for you unless you need to setup your own file server).

Overall Architecture

That file server then puts all of the files received to the hardware of the server, where it can be accessed by the webserver, for example — which is want we want, isn’t it 🙂

The server-driven way to develop

Another method of developing is in favor of the server. You can use a client-side application like Putty (Windows) or Terminal (OSX) to connect to your server using SSH. Once connected, you can use server-side editing tools like VI. I will cover VI handling in another article.

VI editor solution via terminal

The advantage here is that you do not have to transfer any code to the server, since you’re writing files directly to the servers hard drive.

The disadvantage is that you have to maintain a stable internet connection all the time, which can be difficult in crowded WLAN environments.

The user-server interaction roundtrip

Now let’s see what happens if you or another user tries to access files you created. The browser sends a request against a specific file, which is also the case if the address being accessed is just “www.domain.com”, since the webserver, receiving that request then searches for a file called index.php or index.html. Once that file is found, what happens next depends on the kind of file being accessed.

Infrastructure Roundtrip

HTML provisioning

If the file in question is pure HTML or basic JavaScript, the server will just send the markup back to the browser where it can be interpreted.

Server-side script interpretation

If the file is of PHP or any other server side script language, the webserver needs interpreter modules installed which enables it to further process that script. Every script processing results in yet another markup output (HTML, for example) which can be interpreted by the client’s browser after transfer. The way in which that markup was created, however, is not visible by the outside world.

Server-side script and database interaction

Having a PHP or other server side script, a database can also play a role when it comes to accessing structured data, like processing login information. The webserver then needs further components to interpret DBS connections. If the script in question is PHP and the database system is MySQL, the PHP script needs both correct database connection parameters in place and a well defined SQL statement. Both of that can be thrown against the MySQL server instance which then deals with the query and sends the result set back to the webserver. The webserver then does the same as it always does, creating markup and sending it back to the client’s browser.

That would be a full roundtrip, and it is important to understand that interaction in order to successfully build a standalone web application — which is what we’re aiming at.

The WordPress approach

All of the components above are still present in a certain way with a WordPress installation. Yet there are important differences:

  1. A content management system like WordPress serves the purpose of separating layout and content.
  2. You can add texts, images and videos by uploading them to WordPress using WordPresses “Media Library” (via HTTPS instead of FTP/SSH)
  3. You may still edit theme files (PHP, JS, CSS) using VI (or also using manual uploads), but you can also use WordPresses own “Theme Editor” (under “Appearance”)
  4. You do not have to worry about *how* PHP is used to generate HTML content using the content and theme layout functions and style definitions present in the CMS.

The following scheme shows the architecture differences of WordPress in relation to a standalone website.

Wordpress code and media infrastructure difference

Please remember: You need to understand the basic principles of what is happening within a CMS, or at least within a WordPress theme, in order to be able to repair broken files and help yourself with your blog project. That is why the following chapters walk you through everything you minimally need to know about the interaction between HTML, PHP and databases.

The next lessons:

Dr.-Ing. Erik Neitzel

Search

Newest articles

Meta