Originally the SnowCMS v2.0 control panel was going to look much like the WordPress Admin Center, but as I started to get going, I decided that just wouldn’t work. I personally don’t care for the WordPress Admin Center layout anyways.

So I found another little project called the Jaws Project, from which I got my inspiration (and admittedly, a lot of it). Here you can see the home page of the control panel.

As displayed in the settings screenshot, the form you see there is generated with the Form class, just thought I would mention it .

The rest of the control panel (which would be most of it ), is currently not operational, though tomorrow I hope to get started on the Members section. Cyall!

If you haven’t noticed, not much has been going on in the SVN, but don’t worry! I should be able to work on SnowCMS a lot more now, as I will have time to work on it in school every other day.

For those of you that care (which most probably won’t ), I am going to submit SnowCMS in my nomination for the Oregon Student Technologist of the Year Award, and I would like to have a finished (or almost finished) product by May 7th. So be sure to pay close attention, as I should be working hard, especially with Spring Break starting Thursday!

Also, I have been pondering about changing SnowCMS a bit. I would like to start thinking of SnowCMS more as an operating system (which is why most things will be plugins), my thoughts started with the update part of SnowCMS. Usually CMS’s wait a bit to fix bugs, or at least to send out the update, same with security issues (well, except when it is major, it gets shoved out ASAP). However, with an operating system, updates come when they come, and separate (like with Windows, you know, Patch Tuesday ), so why not with SnowCMS? Why not release a fix to a bug when it is fixed? Why not release a fix to a security issue when it is fixed (even if it is small, when it comes to large sites, a small issue can be made huge)? And of course, major security issues ASAP.

That is my idea… Updates will be dispatched on a once-its-fixed basis. Also, with versions, once a patch is released, the version is incremented, like with SnowCMS v1.0, the first patch would be v1.0.1, which isn’t so with operating systems. It is more like MAJOR.MINOR PATCH# or REV#, and that’s how SnowCMS will be as well, but if you choose to show the version in the footer, you will only see v1.0 or v1.1 (.1 would be like a service pack, by the way). When it is time to check for updates (either manually, or automatically), each system file will be checked for a version number (or a checksum, but if someone manually edited a file, that could lead to issues, though its probably not a good idea to edit it, but hey, it’s yours), if it doesn’t match what it should be, well, there is an update required! It is more than likely all patches will be distributed in unified diff format).

That is my idea at least. I would like to do that, but if it gets to be troublesome (or someone points out a major issue), I will reconsider.

Anyways, till next time, cya!

As time progresses, the codebase of SnowCMS, of course, increases. However, as of right now, SnowCMS is primarily worked on by one person. Sure, things get done, and without communication issues, but that is simply because there is little communication happening!

Right now I am looking for others to become actively involved with SnowCMS, such as people who are interested in themes (we need people to tell the developers how to allow the maximum amount of customization for theme creators, along with making themes easier to create), plugins (for this, we need people who are interested in creating plugins for SnowCMS, that way they can tell us if the system needs more extensibility, such as more hooks and filters, and where), but also development of SnowCMS itself. Though if you want to be a developer at the core level of SnowCMS, you will need to start out at the lower ranks and rise up, as we need to be able to tell whether or not you are fit to have such access.

So if you are interested in any way, go to the SnowCMS Dev Forum, register an account, and introduce yourself!

Hope to see you there!

The SnowCMS Dev Team would like to wish everybody a Merry Christmas and a Happy New Year! Sadly, there is no SnowCMS release for the holidays

I would have been very excited to be able to release a beta version of SnowCMS during the holidays, but unfortunately I have been very sick lately, and coding when your sick is no fun! But don’t worry, I am getting better and slowly adding to the codebase. Lately I have been working a lot on the API’s and tools which will come with SnowCMS such as the Members and Messages classes.

Till next time, cya!

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!

I always like to keep people who are interested in SnowCMS aware of what is going on, but sometimes I am not quite sure what it is I should talk about in these posts. Since right now these posts are really the only connection we have to the community.

So if you have a question about the development of SnowCMS, simply post a comment on this post, and I will try to answer it in a later post as best as I can. Thanks!