In light of the amount of bugs in the previous beta (whoops!), I have decided to release a second beta on 23rd August 2010.

Mainly this is because not only do I plan bug fixes, but also I have to add and finish a few other features. It is not for definite at the moment, but the expected stable release date is 29th August.

Expected features are listed below from a technical perspective:

• Improved Efficiency – This will be achieved by taking a re-look at the $Page and $Template objects, primarily the inclusion of javascript on a page by page basis. Also a redo of the caching system is imperative, to enable the ability to delete certain caches rather than clearing the whole thing. On a browser-side note, all images visible on every page will be combined into one.
• User Groups and Permissions – the addition of which will complete the previously somewhat lacking users section. Permissions will be generated using a three digit system similar to UNIX file permissions. The current users section will be streamlined through the use of jQuery. Also the /_user directory will have a location determined during installation, and the /_user/settings.php file will be moved to /.settings.php
• Subdir Installation Support – support will be added for installing the CMS in sub-directories rather than exclusive support for the root directory. This will be achieved by setting a new constant during installation containing the installation URL.
• Native RSS Reading – for now this support will only be granted in reading form, but it might be extended in the future. It will consist of a class or function which will read remote RSS feeds.
• Code Documentation – the main classes and files will be documented using phpDocumentor, mainly those relevant to plugin developers.
• Streamlined Appearance – New features will be added to assure easy access to relevant sections of the CMS at all times such as pagated and re-sizable tables, expand-all and collapse-all buttons in the list pages section, a new system html email function, the retrieval of optional information via AJAX and a custom error handler for the smarty template engine. Also the Overview section will be looked at again, adding feeds from the development blog (yet to be made) and adding javascript cookies fixing the overview items in position.
• Bug Fixes – they will all be fixed hopefully!
• Plugin Architecture Expansion – a few new things to come. Watch this space!

That’s it, a lot of work involved so I better get to it!

So, Furasta.Org released tomorrow.. are you as excited as I am? Probably not.. The plugin architecture is written, although it is not feature packed at the moment, it allows for easy expansion. In fact the plugin architecture can even be expanded with plugins!

Please note that the plugin architecture may change somewhat between the beta and the stable release, but from that stage on it will remain the static, using a backwards compatible depreciation scheme.

Bundled with the beta, as you will see tomorrow, are two plugins. The first is a feature-less piece of crap really! I just stuck it in because it is slightly useful for one thing. Truthfully, it doesn’t have the support from the plugin architecture to achieve exactly what it was meant to. But that will change when the architecture expands! The latter is a download manager plugin which I wrote for Furasta.Org, and which is slightly specific to my needs. But I decided to include it anyway to show how to develop plugins.

Plugin Construction

Now I’m going to explore the Download Manager Plugin, explain how it was made, and hopefully in the process offer an insight into the system. Writing a plugin for Furasta.Org is simple enough. First create a directory in the _plugins dir, a plugin file, and set the correct permissions:

mkdir _plugins/downloadManager
touch _plugins/downloadManager/plugin.php
chmod -R 777 _plugins/downloadManager

Now edit the plugin.php file. To create a new plugin you must create a new class, which has the same name as the plugin directory. You only need two things for it to register as a plugin, the name and the version number:

class downloadManager{
  var $name='Download Manager';
  var $version=1;

Then you can add different variables, so that it displays well on the admin page:

  var $description='Adds a downloads page type and manages downloads.';
  var $email='conormacaoidh@gmail.com';
  var $href='http://blog.macaoidh.name';

The $email and $href variables do not display in the admin area (they will in coming versions), but they do appear in plugin error reports, so it is important to include them if you want people to report bugs.

Now, lets add a page type for the pages section. Page types allow the plugin access to pages in the admin area. You can select a page type while editing pages by clicking on the Show Options button. There are two things you must do, declare the variable, which is the name that will appear in the page type select box and declare the function which will appear when that type is selected:

  var $adminPageType='Download';

  function adminPageType($page_id){
    require 'admin/adminPageType.php';
    return $content;
  }

Simple enough, the plugin loads a file in the admin directory, and returns the contents to be displayed. I’m not going to show the contents because it’s not entirely relevant, you can explore them yourself with the release tomorrow.

Next we add the frontendPageType() function, which displays the content relevant to that page when it is loaded in the frontend:

  function frontendPageType($Page){
    require 'admin/frontendPageType.php';
    return $content;
  }

Note: I have added the require, although it is not present in the actual plugin, for simplicity reasons. Also note that this time the $Page object is passed rather than the $page_id. You can explore the page object at /_inc/class/Page.php. Basically you can use it to get information about the page, like

$Page->id, $Page->name,$Page->content.

Below I have added a quick Overview Item, which displays information in the homepage of the admin panel.

  function adminOverviewItem(){
    require 'admin/adminOverviewItem.php';
    return $content;
  }

Finally the most important part – the plugin registration! If you don’t register the plugin it will not run.

} // close the class
$Plugins->register(new downloadManager);

That’s the basics to create a plugin. Go to the admin page, activate the plugin and try it out (they are not activated by default). Here’s the full code:

class downloadManager{
  var $name='Download Manager';
  var $version=1;
  var $description='Adds a downloads page type and manages downloads.';
  var $email='conormacaoidh@gmail.com';
  var $href='http://blog.macaoidh.name';
  var $adminPageType='Download';

  function adminPageType($page_id){
    require 'admin/adminPageType.php';
    return $content;
  }
  function frontendPageType($Page){
    require 'admin/frontendPageType.php';
    return $content;
  }
  function adminOverviewItem(){
    require 'admin/adminOverviewItem.php';
    return $content;
  }
}
$Plugins->register(new downloadManager);

Simple as that! If you develop a plugin, please send it on to support@furasta.org. A plugin repository is planned for v1.1, but until then you will not be able to distribute your plugins without going directly through me!

Some additional information below.

Adding A Menu Item

I thought I would cover this also as it is a key feature in most plugins. Simply define the function adminMenu in your class:

  public function adminMenu($menu_array,$url){

The beauty of this plugin architecture is that it works with a hook and filter system. This is a hook because you can simply return your menu added to the existing menu like this: array_merge($menu_array,$news_menu), but it also works as a filter, because you can filter through the existing menu and change things. So what I’m going to do is add a News Settings page to the Settings tab:

    $news_menu=array(
      'News Settings'=>array(
        'url'=>$url.'&page=edit'
      )
    );

    $settings=$menu_array['Settings']['submenu'];
    if(isset($settings))
      $menu_array['Settings']['submenu']=array_merge($settings,$news_menu);
    return $menu_array;
  }

Nothing too crazy there. So that’s the admin menu added!

Installation / Uninstallation

The files:

/_plugins/plugin-dir/install.php
/_plugins/plugin-dir/uninstall.php

are loaded when a plugin is activated/deactivated.

Plugin Vars / Functions

As you will see tomorrow, I have included a file in the download called plugin_vars.txt which lists all the variables and functions currently available in the architecture. I’ll also add it here just for reference:

# variables #

$name
$description
$version
$email
$href
$importance
$adminPageType
$frontendTemplateFunction

# functions #

adminMenu($menu_array,$url)
adminPageType($page_id)
adminPage()
adminOverviewItem()
frontendPageType($Page)
frontendTemplateFunction($Page)
htaccess($htaccess)
robots($robots)

Please do have a look around the CMS tomorrow, I am open to any recommendations/criticisms/requests – anything that will improve the system!

I have been doing a lot of development on Furasta recently and the project is nearing an alpha release – I hope to have it out next week at some stage.

Below I have attached a screenshot of the new admin interface.

A sneak preview of what is to come in Furasta.Org 1.0

The release won’t be feature packed, but the plugin architecture should be working. Note that the SVN has not been updated in ages, but I should get around to it next week as well.

I have decided to work on a new full version of Furasta CMS. I have already started on work for version 1.0 which will be a full re-write.

Also Michael Dever will be helping me out and developing some of the code himself. I am very excited about this new version, as it is a full re-write it will give me an opportunity to include some of the features that I have been thinking about for quite a while, such as:

1. Plugin Architecture. Hopefully I can make this work well. I have looked carefully at the architectures of WordPress, Webme and Joomla and I hope to make one that can beat them all in performance and ease of use.

2. Users and Permissions. The CMS will include the ability to create different users, which have certain permissions to access certain pages. This is something which I touched on in v0.1.5 but intend to improve.

3. New Control Panel. The admin area will now comprise of a new, simplified, control panel. The aim here is to create a CP that looks empty, but which is full of content.

4. News Page + Comments Feature. I have wanted this for a while. Once I am confident enough with it I will move my WordPress blog to Furasta to prove that it works.

5. Possibly a simple file manager. Although I am strongly considering using KFM.

6. Re-write of the Smarty syntax. Possibly get rid of smarty all together.

Because of the massive difference between v0.1.5 and v1.0 the website http://furasta.org will have to be reconstructed. But it’s all very exciting. Now less talk and I have to get down to the action, tomorrow, after a bit of WOW.