The Path To A CMS (part 2)

So far I had no clue how to manage themes, but after a little pondering I managed to come up with a solution. I was too lazy to google it anyways and I believe this solution fits me best because I created it. No, I do not care whether it is an actual method, I manifested it within my own ideologies so therefore; it is mein.

Anyhows, this is pretty much how it will manage the templates.
So it will load themes as theme1,theme2,theme3 and so on using the swagging configuration parser. Now using the values of the keys, I’ll take control of the explode() function with the delimiter of ‘.‘ to get the correct values.

 

 

This would be a prototype of how the themes ‘database’ would be like. If you’re wondering what the ‘.pb‘ extension is, that’s the CMS’s own configuration extension abbreviated as ‘project blog‘.

So yeah, I suppose this concludes the theory behind the themes management module. I will update what goes in the upcoming posts. It might be of another module as I lack the ability to finish one module at a time and I usual end up doing bits and pieces of everything all together. Oh well.

The Path To A CMS (part 1)

And so while I took the last sip of my everlasting (somewhat) dew, an idea struck of why not go in all the way? (no innuendo intended) Dedicating time to develop a functioning CMS. Time is something I probably have right now, so why not? It would not be a complex CMS like WordPress, Joomla or whatsoever. However a minor one, that would classify as my first. (Again, no innuendo intended)

And I started off with a directory of what I’ll be currently needing. So far at the roof of the directory I have index, admin, article & a error page with two more directories; interface & core. The interface directory will be dealing with themes and the core directory will, obviously, be dealing with the main thing itself.

The index page will be implemented with the top first 5 articles with the pagination system I developed a few days ago.
The article page will deal with per article display. Whatever article the user chooses to visit would be displayed there.
The error page will deal with error re-directs, mostly from the .htaccess file.
And so far, lastly, the admin page. I’ll be developing this in the end however. This page, you guessed it, will deal with administration stuff.

The core will contain these classes:

• class.articles.php
• class.database.php
• class.theme.php
• class.parser.php
• class.admin.php

As you probably guessed it, multiple themes will be something I’ll be implementing. I developed a prototype of this a while back and it’s something that my portfolio right now uses. Although I haven’t really implemented other templates other than the current one yet.
Parser class will deal parsers that I may implement, here’s to one that I’m definitely implementing is my swagging configuration parser which will deal with template source links, titles and whatnot. I do not yet know If I should allow database credentials to be stored in here, it may be risky because security hole. But let’s see what do.

I have the whole night plus a leftover pizza left, let the project begin.

The Config Parser With Swag

So this is another minor project I worked on. Playing around with strings of text ends up to be quite fun, especially when you get it right the first few times. So, What’s the use of this crap? Simply put, using configuration files in browser based applications is quite useful and more user-orientated. I solely made this for the purpose of using it in a project I had been working on called ‘Project.Extract‘. That would be something to post about later on.

The parser consists of two public functions.

public unpack()

public pack()

I should get a code-display plugin for WordPress. Any hows, these two functions as you can see can be used to parse any configuration file you’ve got in mind. It has to be of a valid extension provided in the $config_preset_header_info array of valid extensions. And of course, when you’re done parsing, it loads the values into the $config array.

Other than that, It provides accurate variable types. You won’t get any PHP parsing errors where ‘age‘ would be accounted as a string. And know how annoying it is when your ‘true‘ values become ‘1‘ in the parsed file? Well, no more!

So in a conclusion I could say, this minor project got me around parsing files and whatnot, and most likely could be applicable in future projects. I’m still debating over whether I should add a nesting option for sub-configuration values for values. Something like this:

[main]

blah=blah

somethingelse=false

[side]

dis=dat

You get the idea. (I seriously need to get a code-management display plugin…)

You can view the source and/or download it here.

Playing Around With Pagination

Pagination was one of my fears however that just changed today. I managed to set up a minor prototype pagination class.

Yeah, Yeah. It’s not much of an accomplishment, but eyy, 1 fear down. Now that a prototype is done I might be able to get on to creating a proper pagination class. What’s the hype? My lazy brain which operates at a below average level managed to formulate some equations that I don’t even know what to call, but hey, it worked. And I managed to somehow develop an hierarchy for this.

What’s the purpose of this inconspicuous development? As a designer If I’m asked to develop a backhand as well for a blog-type design I might be able to implement one of my own as a default. On the plus side, I’ll be striving to develop a prototype CMS sooner or later just for the purpose gaining some experience points which lack.

It’s just the beginning of a worthy system!

The Beginning

Lets start off. I suppose that I should perhaps grace my first post by introducing myself. I’m a web developer and designer. I like programming.

Yeah, that’s it.