SnowCMS

It has been a few days since we have announced the death of SnowCMS v1.0, and the soon to begin development successor of SnowCMS v1.0, SnowCMS v2.0 (codenamed North Pole, my idea ). As stated, SnowCMS will be a pretty darn modular system, basically only including a member system, plugin system (plugins called flakes in the SnowCMS world) and a set of API’s. With these API’s developers will be able to add numerous features and enhancements to our system, in fact, the SnowCMS Development team will be creating modifications to extend the systems capabilities, but still allow users to enable and disable flakes they don’t want. Meaning SnowCMS technically speaking isn’t a Content Management System, it is whatever you want. You could just enable a forum flake, and it is a forum, enable pages, it is a simple CMS, enable a blog flake and it is a blog, and well, you get the idea…

Well, anyways, we have been busy planning the system before we dive into coding, some recent planning was about member groups, plugin dependencies and language support.

Member groups

We have been wondering whether or not we should allow users to add more member groups and change the permissions accordingly, but we also wondered about predefined groups, sort of like what WordPress does.  With predefined groups it may be somewhat simpler to implement, but it is also somewhat easier on the users themselves as they don’t have a ton of member groups that they have to be like, what does this one do that the other doesn’t? and so on, but the con of such a system would be the fact that users wouldn’t be allowed as much control as possible.

After we all thought about what we should do regarding member groups, we decided to have predefined groups, however, the API would allow plugins to easily register member groups with the member system. The system by default will have two groups, Administrators and Members, Administrators being able to do whatever you can throw at them, but Members being, well, no where near as powerful. However, with the API plugins have the ability to register groups, that way they can have groups that can do more than what Members can, but still less than an Administrator, pretty much just elevating a Members permissions, slightly.

Plugin dependencies

Since most of the core system will only be a member system with a plugin system (along with some API’s), some plugins may actually enhance other plugins, so a plugin for a plugin, and in order to enable that ability, a plugin needs to know that the plugin(s) it depends upon, exist and are activated. We thought about just allowing the plugin to specify the name(s) the the plugin(s) it depends upon, but of course multiple plugins can have the same name, and what good would that do? Even if on the SnowCMS.com plugin site required that no plugin had the same name, that doesn’t mean there couldn’t be any other plugin out in the wild (or on another plugin site) that it depends upon. Tricky tricky, or at least confusing.

So antimatter15 came up with the idea of specifying the plugins address where information about the plugin can be found and downloaded as well. For example, say I (aldo) was the author of a plugin called Super Awesomeness (So the URL friendly version would be super-awesomeness), and if another plugin depend upon Super Awesomeness v1, it would specify snowcms.com/p/aldo/super-awesomeness/1.0. The plugin system would check to see if that plugin is already on the site, and activated when activating the plugin which depends on it. If the plugin isn’t already on the site, it would prompt you saying that the following plugins are required for this plugin to operate, do you want to download and activate them? (Listing them, of course). Then those dependencies would be met, and the plugin could be activated and work, as expected. The cool thing about this is that the dependency names specify the whole domain of where the plugin resides, allowing third-parties to manage their own plugins and such. (You will also be able to specify an update URL for that plugin, which periodically it goes to that URL to see if there is a newer version, if so, it tells the user that there is an update available. This will allow people who maybe sell plugins to others, but provide the purchasers with updates… )

Language support

With SnowCMS v1.0, language support was done through variables, such as $l['go'] would contain Go, and $l['confirmation'] would be Are you sure? and so on. That was slow and tedious work, having to update a language file every time you wanted something to be written out, and having to see if something like that was already in a variable elsewhere, so this time, we are doing it slightly different.

We have decided to create a function called l (that is a lowercase L by the way ), the parameter being the text you want to have output in English. For example:

l('Hello there!');

Now if your systems language was set as English, that string would simply be returned, however, if your systems language was in another language, a language file would be loaded and the correct language string would be returned.

Now, on the SnowCMS site, there will be a portion of which where people can contribute to translations. By default, Google Translator will be used to translate English into whatever language, but we all know that those translations are never 100% correct, so people will be able to modify those accordingly. Every so often the system will check to see if there is a newer version of translations, and download them (These translations will be a plugin, actually ) like say if another string was added (There will always be newer plugins and newer plugin updates which may have a string which is not yet translated, which is reported to the translation site) and what not.

Well, that is about it for now, until next time, cya!