First online deployment (Feb 27th, 2019)

First online deployment
--------------------------------------
February 25th, 2019


In the previous topic I sort of mapped out the points I would like to include during the development of the quark CMS framework. I also did a few changes: added the path to the template location in the content definitions file, changed the template loading to pass through an output buffer and did a few minor corrections, nothing too significant. And I will continue with trivial changes this time as well, simply logging them in this blog as I do them but this time these changes will have an impact, as I want to put the framework into real and practical use. Therefore I won't be bloating the source code with various attempts and less than functional features such as the two new templates I'm working at the time of this writing, which I'm going to remove temporarily from the source tree and replace them with a simple teletype one while getting the rest functional enough to work on bitnova site. 

If you happened to enter the site up until now you would have seen a black page with 3 links to the text files containing the previous posts in this blog and nothing other than that, simply because the cms wasn't ready yet to be deployed. So first thing first: make the framework runnable from inside a folder of the site and keep site customizations separate from the core files. That's not just good practice, but it will help with framework updates each time I'll make a feature upgrade or a bug repair as I want to make it as painless as possible and use something simple like git. I can easily create a git submodule in bitnova's repository and whenever necessary I only need to pull the new version of quarkCMS from the repository server. I also think that later on, this separation will help integrating the CMS over quarkOS. To achieve this, it is fairly simple: we'll add an attribute to the quarkCMS class, called contentPath. This will indicate where all definitions and data files are located relative to the site root and, together with the template location definition in the content definition file, the framework has all the basic input it needs to render the site correctly. 

By doing this separation of customized content from the quarkCMS core files we freely obtain a new feature as well: sample content files, which can reside in their own content subfolder inside quarkCMS folder. One has only to point to their respective content definitions file to test functionality using the sample content.

Here is where I actually decided to simply use the framework as it was and deploy it on bitnova site. I still had to do a couple of things, namely write a simple temporary template and change the GenerateContent() function. For the template I chose to use a few divs in table like layout and make everything green like in the days of teletype monitors :) (I'll change this later to the real template I'm writing for bitnova). On the second issue, the changes in GenerateContent() function were necessary in order to read and display the content of the text files inside the template. So instead of 

function GenerateContent()
{
    include $this->lang_hrefs[$this->idx_current_lang].$this->menu_hrefs[$this->idx_current_page];
}

now the function treats the special case when the included file contains only texts reading the content, filtering it and then echoing it to the output buffer. 

function GenerateContent()
{
    $lang_path = '';
    if (isset($this->lang_hrefs[$this->idx_current_lang])) $lang_path = $this->lang_hrefs[$this->idx_current_lang];
    $filename = $lang_path.$this->menu_hrefs[$this->idx_current_page];
    
    if (file_exists($filename))
    {
        $ext = strtolower(pathinfo($filename, PATHINFO_EXTENSION));
        $s = file_get_contents($filename);
        
        switch ($ext)
        {
            case 'txt':
                echo '<pre style="white-space: pre-wrap;">'.filter_var($s,FILTER_SANITIZE_SPECIAL_CHARS).'</pre>';
                break;
            default:
                echo $s;
                break;
        }
    }
}

After that, I tested and deployed the framework on bitnova site, so more than probably you're reading this post using the actual CMS framework discussed in it. The next step will be to decouple content pages from menu items. Up until now, all content pages were linked to menu items which were displayed in a single level menu (and they still are at the time of this post) when the GenerateMenu() function was called. This doesn't have to be true always, as we mostly want to use menus to navigate to different site sections and not individual pages necessarily, or at least not from the top level of a site menu. For instance, these blog topics may all be part of a blog section of the site which we might want it accessible from a single link in the top menu, and not by linking for each individual post. There might also be other use cases, such as entire menus visible only on specific blog or presentation articles and so on. We'll get there, but the immediate action would be to decouple menu items from content pages. To achieve this with minimal changes in code and declarations, we simply have to make menu_item tags optional or add to them some visibility property. That is I think the subject for the next post.

The other next step would be to choose a license and publish the code on github for anyone to be able to download it, use it and possibly improve on it if possible, although I was expecting to have some "news" functionality when doing that. We'll see...

The other other next step would be to finally introduce the concept of a content generator object as a general mechanism which can be inherited for particular cases such as menus, articles, contact forms, modules etc.

Script executed in: ms
Page rendered in: ms
quarkCMS