Webhosting, websites, completely lacking fundementials
-
OK reading through several posts of late shows me that I completely lack some fundamentals of modern webpages, etc.
I've install IIS and Apache before, placed static HTML files on those servers and accessed them just fine from browsers. But I'm at a loss on what WordPress does, or other web add-ons.
When I stood up my MediaWiki site last year, I didn't understand a lot of what I was doing - I know that editing the webpages required the use of a browser to edit them inside the, for a lack of a better word, built in editor. Of course this left me very wanting in the design elements of that page and ultimately lead to it's demise.
To give this thread a bit more focus - A goal is a good looking website where the homepage primarily gives current/recent news, links to a Table of Contents for 2-3 different manuals (employee handbook, company policies and procedure) those table of contents must be provided in a pleasing to the eye manner, and easily used. They also need to be links to the specific pages they are talking about. Each page should contain a link to a downloadable/printable PDF.
As mentioned elsewhere, MediaWiki while functional was so ugly no one would use it. It was also extremely difficult to format things into a readable setup, and attaching PDFs was a huge pain.
-
Well let's start by looking at what a web server has done traditionally, starting long ago (like 1994 time frame.) A web server is just a file server that speaks in the HTTP protocol. That's all at the most fundamental level. HTTP can serve anything, any kind of file that you like. But people assume that it will serve HTML pages, by and large.
This is the world of "static web serving." The client (generally a browser, but certainly not always) uses the HTTP language to ask for a file and the web server sends it (if it has it.) That's it.
If the client doesn't ask for a file but just connects to a generic location (say www.mysite.com) the web server normally is set to send out a default file to the client, generally something like index.html.
-
I'm completely on board there, and even a bit more where I know scripts can be downloaded into your browser telling the browser to go to the same or different servers to get even more pages/code.
-
So that part is boring but handle. It's just a file server like any other, it just has its own protocol that is relatively efficient for static text files. You can serve out PDFs, binaries, whatever you like using it.
Over time, people got bored with this as their web pages were always the same. You could not "do anything." So the idea of not serving out a file but rather generating one "on the fly" was discovered. Through the CGI (Common Gateway Interface) languages were able to be accessed by a web server. So a page could contain code, rather than HTML, and instead of just being handed out to the client, the code would generate HTML and be handed to the client.
The first languages doing this were ones like Perl and Python, later PHP, Ruby and more. Often, for example, instead of index.html as a default "file", index.php would be used. The web server would know that a .php extension meant not to hand the file to the client but instead to hand it through the CGI to a language runtime that would process the code and return HTML.
Once the PHP module or whatever was done running, the resulting HTML "file" would be handed to the client. The webserver is still getting requests as normal and still responding with HTML as normal - but in between the PHP module is turning PHP code into valid HTML. This takes us from static pages to dynamic pages.
Of course just about the most common feature of something like a PHP page is that it can talk to other things like a database to pull information to put into the HTML that it generates.
-
It is from this use of Perl, Python, PHP, etc. to generate HTML instead of just handing out static pages directly that first introduced us to the concept of "web applications." One of the most common uses of this is to make an online store or a blog. Most blogs started out as trivial PHP code that would create a common header, footer, sidebars, etc. and would pull post text out of a database and inject it into the body of an HTML page before returning the page to the browser.
To a web browser, a page coming from PHP is still static HTML like always. It has no way to know that PHP or any language was used to generate the page on the fly. The browser still requests a web page via URL as always, it still receives an HTML file as always.
-
So a LAMP stack, as an example, refers to a Linux OS, an Apache web server, MySQL or MariaDB as a database and PHP all installed on a system. If you just had LA without the MP, you could easily serve out static webpages. If you had LAP without the M, you could generate dynamic sites but could not use a database which could do some interesting things, but only so many (would be easy to inject the current time into a webpage, for example.)
With a LAMP stack you have all of the tools for making powerful, dynamic websites and the majority of web applications are built on this framework. There is nothing saying that you need to use these particular technologies to make a web application, but they are simple, free and widely available and so are generally assumed for most publicly available applications (although relatively uncommon for internally created ones.)
So many web applications like Wordpress, Drupal, MediaWiki and Joomla are just PHP "pages" that exist as files like index.php and talk to a local MySQL database to store their data. That's all the more that they are - a collection of PHP files instead of HTML files that are opened by Apache and handed off to PHP to turn into HTML to provide to a web browser.
Most web hosting assumes either a LAMP stack or LAMP stack compatibility so rarely are the specific needs talked about as these have become so common that everyone just assumes that those components will be used. Hosts like GoDaddy, ASO, etc. provide a LAMP stack. Installing a PHP application like those mentioned is as easy as copying the files there as if they were a static web page, providing them a database to look to and that's it.
-
Also, in another thread, the question was asked about why Digital Ocean was not considered when shopping for a web host. And I said that because DO is not a web host. I want to break this down quickly in "as a Service" terms in the hopes that it clarifies some things.
Getting a server as a VM where you have full control of the server is called: Infrastructure as a Server (IaaS). This is what Rackspace, Azure and Amazon AWS are most known for. This is where you are getting VMs.
Getting an application environment and you only have access to the top level of the stack is called: Platform as a Service. This is what OpenShift, Railyard and Joyent are most known for.
Getting an application itself is called: Software as a Service and is what Office 365 and Google Apps are known for.
So in the example of web hosting here is a quick breakdown of a real stack:
Software as a Service SaaS: Hosted Wordpress (Wordpress dot com)
Platform as a Service PaaS: Hosted LAMP (A Small Orange)
Infrastructure as a Service IaaS: Hosted Linux (Digital Ocean, Rackspace) -
Drupal, like the others uses php and MySQL for data. But you can do some really cool stuff since it's database driven. There's a module called Views which allows you to create really complex SQL queries, and it's gui driven. You can write the SQL if you want, but you don't have to. You can create full database applications with relations to retrieve data and display it pretty much however you want.
Here's what Views looks like:
Here's the query created from that:
Another cool thing views can do is change output of specific items. So for this view, it takes an input of a fontawesome name (just the specific name like "news" or "flash") and rewrites it with the HTML around it. So when you fill in the form to create the content all you type in is "pencil" and a size number and it outputs it as
<i class="fa fa-pencil fa-<size_number>x"></i>
which is this: