I personally can’t wait! I have put a lot of work into SnowCMS over the past couple years, and I have finally figured out what SnowCMS should be and what SnowCMS will be, and everybody will be able to use this great system I have developed, and eventually, what everybody has developed as a community to extend this platform.

Well, I am quite tired from a long day at school. Till next time, cya!

I recently completed a new tool for SnowCMS, the Form class. The Form class allows you to create forms (if you didn’t notice) that can then be hooked into via the API and changed, without you needing to do any extra effort, you simply make the Form how you want to, and then display it. Right before the form is displayed (or processed), the API runs a hook which allows the modification of the form, from adding, changing and removing fields. In fact, currently the registration form uses this Form class, and the very first SnowCMS plugin hooks into the form and adds a CAPTCHA verification image. It’s very simple to do!

For the time being, I need to get some sleep (it is 12:15AM at the time of this post), but I hope to soon create a more in depth guide to the creation of forms using the Form class.

Cya soon!

So how do we keep your password secure? For starters, the password kept in the members database is salted with your username and then encrypted using SHA1. By salting your password, it helps prevent the use of rainbow tables (You know, those sites that have databases with plain text strings and their encrypted counterpart). Then there is logging in, when you submit your credentials through the log in form, your password gets salted with your supplied username, hashed using SHA1, then salted with a randomly generated string which is done by the server. Your plain text password is deleted before the form is sent to the server. Now, this only will occur if you have JavaScript enabled, of course. Once the hashed password is sent to the server, it takes out your members row, and salts (The last salt generated) the hashed password in the database and hashes it, then compares it to the one received from you. If they match, that means your password is correct.

Securing your password before being sent to the server might seem a bit overkill, but it can be very useful. As you never know, someone could be logging POST data, which would contain your log in credentials. All they would get would be your encrypted password which is salted with a randomly generated string. The only way they could ever use that password to log in to your account would be if the server were to generate the same random string, which is highly unlikely.

There are two ways that SnowCMS keeps your password from ever being seen by human eyes, but there is still one more. Cookies! No, not those kind, the Internet kind. With every page load, your browser sends the cookies to the server, where they can then be used to identify whether or not you are logged in. Instead of sending your password just with your username salting the password, there is also a randomly generated hash in the database that salts your password in the cookie… Just in case

Not all people have access to SSL, which would stop such possible attacks, which is why we at SnowCMS have decided to use such tactics to protect not only the system itself from security issues, but also the people who use our system as well.

Just a reminder, the SnowCMS Dev Forum is now open to the public, if you are interested in having part in the development, or just like to see what is happening, you should come and join us.

Till next time, cya!

In order to allow developers to see all of what goes on in SnowCMS in a more orderly fashion, such as API’s available, the SnowCMS SVN includes documentation which is compiled every now and again (by antimatter15, not me…), which is available here. We know that a system can be great, but that system isn’t useful if no one knows how to use what the system has to offer, so developers take advantage of what SnowCMS has to offer. Currently we have a few available classes and such to aid developers create plugins much faster, and without requiring plugins to have code that multiple plugins might end up having to include themselves, which is unnecessary. So I thought that I would, over the next week or more, make some posts about how to use the various API’s and classes available to future developers.

API

The name is pretty self explanatory, but as you can see, there are many available methods which can be used by plugins, and of course, this will no doubt be the most used by plugins.

Adding a hook

A plugin can add a hook via the $api, to modify the behavior of the system, or just do some action at the time of the hooks execution. Here is an example:

/* ... */

/* ... */
# Now somewhere in SnowCMS's code, a hook is ran, and if you registered a callback on that hook,
# your callback, is, erm, called
$text = "Hi...";
$api->run_hook('the_hooks_name', array(&$text));
echo $text;

Now once all that was ran, “Hi…” would not be seen on the screen, but “I HOOKED YOU!” would be because the function my_hook had $str be a reference parameter, and when run_hook was called, $text was defined as a reference as well, allowing any function that hooked into this hook to change what $text contained. Of course, just changing text won’t be the only thing available through hooks, but there will be a lot more, but that depends upon the hook itself. Right now there is a small list available at Google Code of currently available hooks in the system, but as time progresses, the list will grow

Adding an action

When SnowCMS refers to an action, we mean an action in the URL. With the API, plugins can register actions to add some major, or possibly not so major, but still important, features to the system. Like say if there was a forum plugin and they wanted the forums index page to be accessible through index.php?action=forum, well, you can do that, and quite easily, I might add.

Adding that accessible page is done like this:

/* ... */
$api->add_action('forum', 'forum_index', 'location\of\the\forum_index.php');
/* ... */

Now when index.php?action=forum is accessed in a browser, the file “location\of\the\forum_index.php” is loaded and the function forum_index is called on. You can also leave the third parameter blank (the location of the function) and forum_index would just be called on. Through this method plugins can add pretty significant features to the system, like forums, pages, blogs, news, directories, or anything, really. Pretty slick, huh?

Adding a sub action

Along with adding an action, you can also add a sub action, the difference is that the action must implement the usage of sub actions. Such as the forum plugin (there isn’t really one, yet, I am just using it as an example ) it must use the API (which larger plugins really ought to, but don’t have to, use the API system to allow any other possible plugins to enhance the plugin itself…) to see if there are any sub actions which are registered (More on that later).

So now say you wanted to add a feature or something of the like to the forum plugin (index.php?action=forum) such as a statistics page. You would do this:

/* ... */
$api->add_subaction('forum', 'stats', 'stats_page', 'location\of\the\stats_page.php');
/* ... */

When you would access index.php?action=forum&sa=stats “location\of\the\stats_page.php” would be loaded and stats_page would be called upon, but of course, just as with add_action, the location of the function can be left empty.

Adding a group

Since we wanted to keep SnowCMS simple, we thought by default the system would only have 2 groups, an administrative group (administrator) and a member group (member, of course! But there is also a group called guest which you can’t assign yourself ). Why? Well, think about it. Most operating systems have 2 groups, administrators, which can really do everything, then there are members, which just plain get the privilege of using the computer So there are only those two groups. However, plugins are likely to add features which members shouldn’t be always allowed to use, nor should administrators be the only group allowed to use it either. So to make that work, plugins can register groups, which administrators can assign to members, which therefore elevate the abilities of that member.

First things first, a plugin needs to register the group, otherwise an administrator can’t assign (or at least, easily) the group to a member.

/* ... */
$api->add_group('forum_moderator', l('Forum Moderator'));
/* ... */

The first parameter is the groups identifier, which is the string stored inside the database, the second parameter is the human readable name of the group, in this case, Forum Moderator (I bet you are wondering what the l() function call is for, that is for language support, but more on that later ).

Now, when you want to see if the current member is allowed to perform the tasks restricted only to forum moderators, you would do a little something like this:

/* ... */

if($member->is_a(‘forum_moderator’))
{
/* They are a forum moderator, proceed */
}
else
{
/* They aren’t a forum moderator, yell at them! */
}

/* … */

There you have it… And of course you don’t need to worry about the checking of administrator’s, if the member is an administrator, any call to the method is_a is automatically returned as true.

So there you have it… A insight on how to use SnowCMS’s API class, that is all for the time being, but come back soon and I will be posting about other tools available in the SnowCMS which developers will be able to take advantage of.

As of today, SnowCMS v1.0 is dead, but that doesn’t mean that the SnowCMS project is dead. We, the SnowCMS Dev team, have started to plan a newer version of SnowCMS, which will be SnowCMS v2.0, and this time the system will be bare bones, with only the basics, such as member management and a plug-in system, much like that of WordPress.

Now don’t think that the system with ship with only member management, that is merely the only feature which will be enabled by default, plug-ins made by the SnowCMS Dev team to extend the bare boned functionality of the system using the hooks and API’s provided with SnowCMS. We are looking forward to creating an extremely modular system, and as time passes, you should start to see code appear in the repository and more information posted here.

You are probably thinking why has this happened a second time? First there was SnowCMS v0.7 and now SnowCMS v1.0… Why did this occur? The problem was that we tried to provide a system with to many features and such at one time and after awhile, we just became overwhelmed with what we had to do, so we stopped, and we decided to once again start new, light, and well planned.

Mod system
Of course SnowCMS will have a modification system, and the dev team and I were thinking about how to do it. Some systems have a sort of API system, where basically every so often, the system will call on some kind of hooks are integrated for developers to latch on to. But there is not much power. Sure it would be simple for use to make, and then updating SnowCMS powered sites would be a snap, we don’t want to take the easy way out

Other systems allow you to modify all the files themselves. It can be a little more complicated, but it also poses a threat to users if they were to install malicious modifications. Probably pretty unlikely, but hey! It can happen…

Another way is super easy. Not having one at all. Of course, we wouldn’t do that. We have come to a unanimous decision to have file based editing for the modification system. Oh, and did I mention modifications are referred to as ‘flakes’?

Mod security
As I mentioned about allowing people to modify the sources of the system can be dangerous. So how are we as developers going to combat that?

Pretty simple, well, at least simple in concept. What will happen is people will be able to submit modifications to our site (Eventually we will have a modifications database, of course!) and once the team has reviewed it (Either developers, or maybe a modification team) and approved the modification to be done well and doesn’t do anything bad, the file will have its hash taken (SHA-1, most likely) and stored in a publically accessible way (In a database and can have the data retrieved). Now once the modification is uploaded to your site, and once your about to install it, your system will hash the file and send it off to SnowCMS.com. We (well, the server…) will then take that hash and check to see if it exists and is approved in our database. If it is, you will see a message saying the modification is safe and has been approved by the SnowCMS team.

A pretty good idea. Because if that modification which you uploaded to your site was changed in any way, it won’t be in our database. Simple, but darn effective =P.

Updating
Since SnowCMS will feature a modification (flake) system, updating will be pretty straight forward. Once SnowCMS goes gold, whenever an update is out (Like 1.0.1) we will have those updates put into a flake package. That way even when you have modifications installed, you should be able to update pretty easily with little to no errors. But of course, in the beta and RC stage, you will not be able to update via this system due to the major amount of code changes that will occur. Sorry!

BBCode
Like I talked about in previous posts, I certainly hope by either public beta release or when 1.0 goes gold, we will have the new BBCode parser complete. Still working on it.

Well, a lot of information about SnowCMS v1.0. Until next time, see ya! XD.

Not to long ago I began pondering how I could approach this problem, and how other systems do it. I then thought, XML! I remembered that in PHP using XML Parser it parses the XML file into levels with by tags, and that is how I am approaching it

I already have a very very very (Did I say very?) rough prototype, only ~32 lines of code, the function parses this string:

[b]Hello there![/b] [i]Why? [color=red]CAUSE![/color][/i]

Into:

Array
(
    [1] => [b]
    [2] => Hello there!
    [3] => [/b]
    [4] => 
    [5] => [i]
    [6] => Why?
    [7] => [color=red]
    [8] => CAUSE!
    [9] => [/color]
    [11] => [/i]
)

Right now it isn’t parsed very pretty like But for the time being, it works for the most part! I can’t wait to dig deeper into this idea tomorrow… Seeya for now! (It is 12:15AM at the time I am posting this, Lol)