Right now I am working on a new class called Extractor which will do what one might think: extract files, such as zips, tarballs and gzipped tarballs without having to detect the compression method used manually.

Additionally I have created an Extraction interface which may be implemented to support the extraction of other compression methods.

With this new Extractor class I also worked on updating the current Zip and Tar classes to add a new method called read. This new method allows files to be retrieved from the compressed file without having to decompress the entire package. This individual file may be returned or saved to a specified file.

This may sound insignificant (or that I am going off-track from what I have been working on lately), but it allows the process of installing and updating themes and plugins more efficiently.

Currently a package (theme or plugin) is extracted to make sure the package can actually be extracted and to make sure that the package is valid (e.g. a real theme or plugin), then its status is checked. If the status check finds that the package is not approved the user must choose to continue with the installation, if they do the page is refreshed and everything up to this point is redone, but the status returned is ignored. Now the compatibility of the package is checked and if it isn’t compatible the user is once again asked to continue with installation anyways, if so the process is once again repeated.

This means the package could be extracted up to three different times (the extracted package is removed on each page load in case the user leaves the page). This needs to occur to make sure the compressed package can be decompressed and to make sure the right files exist and to check its compatibility with the system.

Now that files can be extracted individually the package does not need to be extracted over and over again, making the process much more efficient.

Just thought I’d let you know

What do I have left to do?

• Some tweaks to the theme control panel, such as making the theme files checked against the security database (to see that they are safe), and to check for and apply updates to a theme.
• Remove AJAX from the plugin updater.
• Leverage the simple notification system: currently there is a way for plugins to display simple notifications in the control panel sidebar, but SnowCMS itself does not take advantage of this feature. I will make it so when there is a system update, plugin update, or theme update, you will see a notification that there is some sort of update available.

Hopefully we really are close this time, as I am really looking forward to getting SnowCMS out to the web to demonstrate what it is capable of!

So I began thinking, hold on… If any plugins in the default SnowCMS package have any vulnerabilities, an entirely new version of SnowCMS would have to be released because that installation package would need updating (I don’t want to update it without a version change…), but all existing installations would merely get the plugins update through the plugin manager, and their SnowCMS version would be different, and a fake update would need to be sent out to change it.

To me, that is quite pointless. So the idea of distributing SnowCMS with plugins is out. The plugins folder will be completely empty when you download the installation package . Plus, this allows other plugins which aren’t first party to have just as much chance to be picked as ours.

But of course! When you setup SnowCMS the very last step will mention the fact that SnowCMS, by default, comes with very little functionality, and there will likely be a list of plugins (such as link managers, page managers, stuff most people would intend to use SnowCMS for) with the most popular ones.

Just thought I would let you know

If you are wondering what’s currently going on, right now I am working on member management, which will require a new tool (the Table class, but more on that later), once the new tool and member management are done, I will start on an error log viewer (completely slipped my mind!!!). After that, work on the SnowCMS site will begin! So soon enough, SnowCMS.com will actually be powered by SnowCMS Why you may ask..? Because! Until the site is setup, I won’t know exactly how the plugin site will be setup, which is quite important to do before plugin management can be done

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 if you are interested in getting involved (whether it be giving input, reporting issues, or whatever!) why not come check it out?