If you currently have the Teasers Module enabled and displaying on your site, this technique may display some content twice.

SkyBlueCanvas Plugins to the Rescue

Since the creation of content and rendering of content is fairly well separated in SkyBlueCanvas, it is possible to display content in an unlimited number of ways. To solve this particular problem I chose to write a simple plugin to allow me to specify the specific Teaser I want to display and even restrict the display to an individual page or a list of pages.

The concept is actually pretty simple:

• Create a plugin that accepts a Teaser ID and Page ID as its arguments
• Add the Plugin Call to my template or page text

The Plugin Call

The plugin will make more sense if we first examine the plugin call. If you need a refresher on the SkyBlueCanvas Plugin API see the post on SkyBlueCanvas Plugins.

There are two ways to explicitly call a SkyBlueCanvas Plugin:

An HTML comment plugin call:

<!--#plugin:myPluginFunction(arg1, arg2,...)-->

Or a plugin call from within the text of a story:

{plugin:myPluginFunction(arg1, arg2,...)}

For this plugin we are going to pass two arguments, the Teaser ID and the Page ID and we’ll use an HTML comment plugin call. The code below will be added to our HTML template (skin):

<!--#plugin:plgSnippet(2,1)-->

The above plugin call will tells the Snippet Plugin that we will create next to display Teaser ID 2 on Page ID 1 (the home page). It won’t actually do anything yet, however. It is just an HTML comment and will not display on the page.

The Plugin Code

The PHP code below includes comments to explain each step of the process so I won’t repeat it.

<?php

  /**
  * Show an individual Teaser item in a page region indicated by
  * <!--#plugin:plgSnippet($id, $pageId)-->
  *
  * @param  array  An argument array
  * @return string The html of the snippet
  */

  function plgSnippet($args)
  {
    global $Core;

    /*
    *  If no arguments are passed, return a null value.
    */

    if (!count($args)) return null;
    $id = $args[0];

    /*
    * The second argument is optional. If you want to
    * only show the snippet on a specific page, pass
    * the page ID as the second arguemnt.
    */

    $pageId = count($args) == 2
      ? plgSnippetConvertArg($args[1])
      : null ;

    /*
    * Store the current page id in a variable.
    */

    $thisPageId = $Core->GetVar($_GET, ‘pid’, null);

    /*
    * The page id passed by the plugin call can be a single
    * page id or an array of page ids. If the page id is set,
    * make sure it matches the current page id.
    */

    if (is_array($pageId) && !in_array($thisPageId, $pageId))
    {
      return null;
    }
    else if (!empty($pageId) && $thisPageId !== $pageId)
    {
      return null;
    }

    /*
    * If we made it this far, we need to show the snippet.
    */

    $snippets = $Core->xmlHandler->parserMain(
        SB_XML_DIR . ‘teaser.xml’
      );
    $snippet = $Core->SelectObj($snippets, $id);
    if (!$snippet) return null;
    $html  = “<div id=\”snippet-$id\”>\n”;
    $html .= “<h2>{$snippet->name}</h2>\n”;
    $html .= “<p>” .
      base64_decode($snippet->intro) .
      “</p>\n”;
    $html .= “</div>\n”;
    return $html;
  }

  /**
  * Convert an argument to an array if it contains the
  * ‘,’ delimiter. Otherwise return the argument untouched.
  */

  function plgSnippetConvertArg($arg)
  {
    if (strpos($arg, ‘,’) == false) return $arg;
    $args = explode(’,', $arg);
    for ($i=0; $i<count($args); $i++)
    {
      $args[$i] = trim($args[$i]);
    }
    return $args;
  }

?>

Putting It All Together

Now, log into your SkyBlueCanvas Site Admin and go to: Collections > Plugins

Click the Add button to create a new plugin. You can name the plugin anything you like but keep in mind that plugins must be named ‘plugin.your_plugin_name.php’. Let’s just name it plugin.snippet.php.

Next, paste the PHP code above into the text area on the Plugin Editor and click Save.

The plugin is created and is now active. The next step is to create a Teaser (or Teasers) to display so go to Collections > Teasers. Click the Add button and give your Teaser a name. The name can be anything you like and may include spaces. Add the Teaser text. Be sure to leave the Link selector set to No Link. Click Save.

Next, go to Collections > Collections Publishing and make sure that mod.teaser.php is not published on any pages.

Okay, we are down to the final step - calling our Snippet Plugin to display our snippet(s). Go to Main Dashboard > Pages and click Edit in the task list next to your home page.

In the HTML editor, add the following code:

{plugin:plgSnippet(2)}

Notice that we did not provide the second argument (the page id). Since we are calling the plugin from the Home Page text, we do not need the second argument.

Save your page and go to your site’s home page. You should see the Teaser name and text displayed on the page. The Snippet output has a unique id formatted as snippet-n where n is the Teaser ID. This allows you to write CSS rules specific to each Snippet.

The Snippet output will look like this:

<div id="snippet-2">
<h2>My Snippet Title</h2>
<p>This is my first Snippet.</p>
</div>

Alternative Display Techniques

The Snippet Plugin gives you a couple of display options depending on which call method you use (i.e., HTML comment call or text-based call), and what arguments you pass to the plugin.

For instance, if you are using an HTML comment call, you can restrict the display of the snippet(s) to a single page or a list of pages.

<!--#plugin:plgSnippet(2, [1,2,3])–>

The call to the Snippet plugin shown above tells the plugin to display Teaser ID 2 on pages 1, 2 and 3. To display the Teaser only on the first page, use the following format:

<!--#plugin:plgSnippet(2,1)-->

That’s all there is to it. As you can see, the SkyBlueCanvas Plugin API gives you a lot of flexibility in what content is displayed on your site and how.

“We have focused our efforts on responding to the great feedback we’ve received from our users”, says Scott Lewis, the creator and lead developer of SkyBlueCanvas. “Over the next several weeks we will be preparing a release candidate of the new version and creating good documentation for users and developers”.

SkyBlueCanvas runs on the Apache web server and is compatible with PHP versions 4-5. The system requires no configuration or special modules. You simply un-archive the package in your website directory and start creating your content.

The system is licensed under the GNU/GPL v3.0 License. Service packages for business owners including site setup, customization and design are also available from the development team.

Demo URL
Direct Download Link

The SkyBlueCanvas Development Team is made up of Scott Lewis, Todd Crowe and Steve Fister. Scott Lewis is a web applications developer in Richmond, VA and has 8 years of experience in web applications development for the advertising, information security and telecommunications industries. Todd Crowe is a former software developer for NetScape and AOL and has been writing software professionally for over 15 years. Todd has a diverse background in developing operating systems, desktop applications, and large scale web software. Steve Fister has been a professional internet application developer for 15 years, spending most of this time in San Francisco Bay Area. Steve has broad experience in large scale portal development, content management systems, e-learning systems development, and technical writing.

###
Scott Lewis
Lead Developer
804-274-0683
United States
scott@skybluecanvas.com

We had planned an incremental release numbered v1.0.4 but after a lot of bug fixes, adding several new features and implementing WYMeditor v0.5, we decided that this release merited a more significant release number. A lot of work went into improving the over-all usability of SkyBlueCanvas in this release. We also fixed a lot of bugs that had previously escaped our attention.

For End Users

The most visible change in SkyBlueCanvas v1.1 is to the Page Manager including the ability to publish Collections from from the page level rather than a separate manager. In addition users will also notice that we have implemented the latest version of WYMeditor - version 0.5. The new Page Manager also includes the ability to re-order and publish/unpublish items from the list view as well as many other improvements.

The Page Manager, as well as many other Managers now has the ability to re-order and publish/unpublish items from the default list view so you do not need to open the editor to change the order of an item. Simply use the task buttons in the list view.

You can also now add page-specific JavaScript files to your skins. For instance, if you have a layout skin named skin.alternate.html, you can add a JavaScript file that only loads on this page by creating a file named skin.alternate.js in /skyblue_root/data/skins/your_skin/js/.

We also added a new Banner Ads Manager so you can place banner ads through the Admin Console. Previously banner ads were required to be added via FTP only.

For Developers

SkyBlueCanvas has several major changes to the code that will interest developers. We added 3 new classes to the OOP hierarchy: SkyBlueObject, Observer and SkyBlueError. These classes add some default shared functionality in getters and setters and most importantly add support for custom events using the Observer Pattern. We will provide full documentation for using custom events and the other new classes as soon as possible.

Upgrading From Previous Versions of SkyBlueCanvas

The upgrade process for SkyBlueCanvas has not changed. You can read about the upgrade process on the Upgrade Instructions page on this blog.

The changes in v1.1 will not affect your existing data at all. We did not make any changes to the data storage. There were changes to the logic in a few of the plugins and modules but these changes should not impact the display of the plugin or module output.

I am happy to introduce you all to Todd Crowe and Steve Fister. Todd and Steve are the newest members of the SkyBlueCanvas development team. Each has over 15 years of experience in software development and will be applying the fruits of that experience to SkyBlueCanvas. You can read more about Todd and Steve on the blog.

Next, we will be releasing version 1.0.4 of SkyBlueCanvas within the next few days. This is a minor version release that will fix a few bugs in the WYMeditor XHTML Editor and to some of the managers. This version will also include a few new minor features.

The development team is also working on SkyBlueCanvas v1.1, which is tentatively scheduled to be released November 1, 2008. Version 1.1 will be a fairly significant upgrade to SBC with improved usability, several new features and an improved development API. Version 1.1 will also include WYMeditor v0.5 (the current release).

Thank you and keep a look out for these two new releases.

Steve has been a professional internet application developer for 15 years, spending most of this time in San Francisco Bay Area. Steve’s broad experience in large scale portal development, content management systems, e-learning systems development, and technical writing will bring additional and complimentary skills to the SBC team.

Steve is also an avid fisherman, both salt- and freshwater and finds his Zen place on the waters of the Block Island Sound.

Todd is a website developer living on the Oregon Coast. He has been writing software professionally for over 15 years.  Todd’s diverse background in developing operating systems, desktop applications, and large scale web software brings a broad range of skills and experience to the project.

I am excited to have Todd join the team and he and I both look forward to working to make SkyBlueCanvas a great lightweight content management solution.

A word of caution, however - this is an alpha version and should not be used for production web sites. There are some known issues with the SBC implementation of WYMeditor v0.5 and IE 6 (selection is lost when the SkyBox overlay is activated). The software also has not been tested either so there are most likely some bugs. Additionally, there is no documentation of the new features except for the change log and that is not completely up-to-date.

All that not withstanding, if your php skills are a bit more advanced and you would like to bang on the new version, please feel free to so. I welcome any and all criticism and feedback. I would like to take SBC a step further towards maturity and your help would be a great service to me.

You can download the package from www.skybluecanvas.com/download-alpha

The login credentials for the admin control panel are demo/demo.

Cheers,
Scott

Updated

Download SkyBlueCanvas SiteVars Plugin

The SiteVars plugin adds a lot of flexibility and power to a SkyBlueCanvas site without requiring any knowledge of PHP or HTML. In fact, you do not even need a lot of knowledge about how the insides of SkyBlueCanvas work to use this plugin.

The plugin uses a simple ASCII-based syntax to insert values from properties that you set in the admin control panel. One of the biggest benefits of this approach is that if the values change, you do not need to update references to these values in your template or content.

There are three basic objects or domains that can be referenced by the plugin’s grammar. These are: site, page and page.link. The syntax is very simple and will always be written like this:

[[ object . property ]]

Notice the double square brackets enclosing the variable on the left and right sides. When you create these tokens, omit the spaces shown above.

Site Variables

Example Usage:

Welcome to [[site . name]]

Page Variables

Example Usage:

Bread Crumbs: <a href="index.php?pid=[[page . parent . id]]”>
    [[page . parent . title]]</a> / [[page . title ]]

Page Link Variables

The wrap_tag parameter in each variable below can be any HTML element.

Example Usage:

Pagination: [[page . link(first)]] -
    [[page . link(previous)]] -
    [[page . link(next)]] -
    [[page . link(last)]]

Example Usage 2:

<h2>Related Articles</h2>
<ul>
    [[page . link(children, li)]]
</ul>

Example Usage 3:

    [[page . redirect(http://www.skybluecanvas.com)]]

I decided the ideal architecture is one in which WYMeditor has no knowledge of plugins but rather provided the necessary hooks to attach and trigger plugins on specific state changes or custom events. It occurred to me that what I wanted was an architecture that implements the Observer Pattern so that I could subscribe to various state changes.

I also decided that I wanted to be smart about the design and make it so that other developers could also add additional functionality and not have to worry about collisions between the names of functions and properties used in their plugins and those of my or other plugins. So this requirement called for the ability to define custom name spaces.

This article proposes a new architecture that not only satisfies the requirements described above, but also makes even the core features of WYMeditor into plugins using the same API. The proposed architecture essentially converts WYMeditor into a robust editor plugin engine.

There are several benefits to the architecture which this document describes. First, it makes the base code more maintainable. When bugfixes and upgrades to isolated parts of the code are needed, only part of the code needs to be replaced. Second, it gives third-party developers much more power and flexibility to be able to control the execution of their code. Finally, it allows developers to add much more robust features like database interaction, file uploading and even image editing capabilities. I believe the possibilities become almost endless through the new architecture and API.

It occurred to me after several weeks of working with various designs for the new architecture that this design could be implemented with any jQuery extension, thus turning the extension into a pluggable application built on top of the jQuery JavaScript framework.

This article assumes that you have some familiarity with the Function.prototype concept and the $.extend() function. I will be using a generic application called MyApp to demonstrate the concept.

First, let’s begin by defining a new Object for our application.

if (!MyApp) var MyApp = {};

In JavaScript, the window object is the global scope, so we make the creation of the object conditional so that we do no end up with more than one instance of MyApp within the global space.

Next, I am going to set up the base MyApp object with a few default properties and a base method I will call main.

$.extend(MyApp, {
    target: null,
    events: {
        init   : 'onInit',
        run    : 'onRun',
        finish : 'onFinish'
    },
    main: function(target) {
        var events = MyApp.events;
        var _self  = [this];
 
        this.init(target);
 
        $(MyApp).trigger(events.init, _self);
 
        this.run();
 
        $(MyApp).trigger(events.run, _self);
 
        this.finish();
 
        $(MyApp).trigger(events.finish, _self);
    }
});

In the code above, you will notice that I have three parts which are explained in turn below.

1. The target property

The target will be the DOM element or elements on which my application will operate. If you are familiar with jQuery you know that you specify the target of any action with selectors like this:

$("a").click(function() {...});

In the above example, the target property of MyApp would refer to the “a” element passed to jQuery.

2. The events property

The events in MyApp will be the different states or state changes on which my plugins will be triggered. The number and names of events is up to you. For this demonstration I have kept it simple with init, run and finish events.

3. The main method

The main method is the base function of MyApp. It is possible to create a jQuery extension by creating MyApp as new Function rather than an Object, but using the Object allows me to namespace not only MyApp, but also to use different namespaces for each of MyPlugins within the MyApp namespace.

You will notice in the main function that I am setting a local variable named _self to an array containing a reference to the function itself. This is done to cut down on memory usage by avoiding calling the Array constructor each time the trigger method is called. The gains from this may be slight but since I like efficiency, I think every little bit of gain in execution time is positive gain.

At this point, MyApp does not do anything. I still need to define the three methods that are triggered on each of the state changes. For this demonstration my methods will be very simple: I will have them just append a message to the target of their actions.

MyApp.main.prototype.init = function(target) {
    this.target = target;
    $(this.target).append('MyApp.init Called');
};
 
MyApp.main.prototype.run = function(target) {
    $(target).append('MyApp.run Called');
};
 
MyApp.main.prototype.finish = function(target) {
    $(target).append('MyApp.finish Called');
};

I have used JavaScripts prototype object to add functions within the scope of the main function. This is a cleaner way of doing this:

main: function () {
    var init = function() {
        // code goes here ...
    };
 
    var run = function() {
        // code goes here ...
    };
 
    var finish = funciton() {
        // code goes here ...
    };
}

My code is much cleaner, easier to read and so easier to maintain.

The last step is to add my extension to jQuery:

/* Add the extension to jQuery */
 
$.fn.myapp = function() {
    return this.each(function() {
        new MyApp.main($(this));
    });
};

The code above adds a method called ‘myapp’ to the jQuery.fn array so I can call

$(element).myapp();

and MyApp will be passed the target element or elements found by jQuery’s search of the DOM. jQuery’s this.each method is used so that myapp will be executed on every element found matching my selector. It is important to return the result of the execution to jQuery to insure that jQuery’s method chaining functions correctly.

Now I have a fully functional, albeit a very simple, jQuery extension. Since the purpose of this article is to demonstrate a pluggable jQuery extension, I now need to create my plugin, which I will aptly name MyPlugin.

MyPlugin will be created in similar fashion to MyApp except that I will use a new Function rather than an Object.

First I will create the MyPlugin function which will receive a reference to MyApp as its only argument. By passing a reference to MyApp to the plugin, I make all the properties and methods of MyApp available to MyPlugin. The MyPlugin constructor will extend MyApp with MyPlugin.

/* The Plugin code */
 
var MyPlugin = function(app) {
    $.extend(app, {
        MyPlugin: this.init(app)
    });
};

I now have a MyPlugin namespace within the MyApp namespace. This may seem a bit circular, but it is very flexible and useful. First, in this way I avoid any possible collisions between the methods with MyPlugin and MyApp as well as within other plugins. By extending MyApp in this way, I also make MyPlugin available to other plugins to MyApp. I could feasibly do something like this:

MyApp.MyPlugin2 = function(app) {
    app.MyPlugin1.method();
};

MyPlugin is not yet complete, however, so I will add a simple function to it again using the prototype Object.

MyPlugin.prototype.init = function(app) {
    $(app.target).append('MyPlugin fired');
};

And lastly, I need to tell MyApp when it should run MyPlugin. I will do this using jQuery’s bind function. The bind/trigger combination in jQuery is, in my opinion, one of its most powerful features and the one that makes the architecture described in this article possible.

$(MyApp).bind('onRun', function(e, app) {
    new MyPlugin(app);
});

The jQuery.bind() function takes the following form:

$(scope).bind(event, callback);

The scope is the space in which the event will occur and the callback is the code that will be executed when the event occurs. It is important that the specified event actually exists or occurs within the specified scope. If you attempt to call the callback on an event that does not exist in the specified scope, nothing will happen or, you may get unexpected results if an event by the same name exists but in the wrong scope.

Now if we refer back to the base code for MyApp, you will notice the events I set up:

$.extend(MyApp, {
    target: null,
    events: {
        init   : 'onInit',
        run    : 'onRun',
        finish : 'onFinish'
    },
    main: function(target) {
        var events = MyApp.events;
        var _self  = [this];
 
        this.init(target);
 
        $(MyApp).trigger(events.init, _self);
 
        this.run();
 
        $(MyApp).trigger(events.run, _self);
 
        this.finish();
 
        $(MyApp).trigger(events.finish, _self);
    }
});

You will also notice in the main function this line:

$(MyApp).trigger(events.run, _self);

jQuery will then call MyPlugin passing the window’s event object and the reference to MyApp.main contained in the _self variable. As stated earlier, passing a reference to MyApp.main allows my plugin to have access to the properties and methods of main, including its target.

Our demonstration is now complete. There is not space here to enumerate all of the benefits of this architecture but I hope that at least I have managed to demonstrate the possibilities this design creates.

You can download a working copy of this demonstration at myapp.zip or see it in action at jquery.myapp.

Please use the comment form below to let me know what you think and/or to ask any questions.

SkyBlueCanvas is designed to make web site creation as simple as possible so unlike true template scripting languages like Smarty, the SkyBlueCanvas content token replacement system does not include any logic such as loops or conditionals. Stated very simply, the SkyBlueCanvas skin system uses basic string-replacement to allow you to specify which content will appear where in your HTML template.

Structure of a Skin

The simplest breakdown of a skin is what I refer to as the skeleton of a page. The skeleton includes elements that will appear on every web page, no matter what elements make up the body of the page. These common elements include the document type declaration, the HTML, HEAD, TITLE, META, SCRIPT, STYLE and BODY elements.

The code shown in Diagram 1 is the HTML skeleton that comes with SkyBlueCanvas.

Diagram 1

Located in /skyblue/rsrc/page.skeleton.html

<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Strict//EN”
  ”http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd”>
<html{doc:lang}>
  <head>
    <title>{page:title}</title>
    <meta http-equiv=”Content-Type”
          content=”text/html; charset=iso-8859-1?
          />    
    {region:meta}
    <meta http-equiv=”imagetoolbar”
          content=”no”
          />
    <script type=”text/javascript”>
        var base_uri = ‘{page:base_uri}‘;
    </script>
    {region:links}
    {region:styles}
    {region:scripts}
    {region:favicon}
    {plugin:preloader}
  </head>
  <body{page:bodyid}{body:class}>
      <!– Begin Your Skin Code –>
      {page:body}
      <!– End Your Skin Code –>
  </body>
</html>

This is the HTML that is used to render every page in a SkyBlueCanvas site. When a page is requested by a site visitor, the Skin Engine uses this HTML as the framework - or skeleton - for the page. You will notice that there are several tokens in the format {token-name} where you might usually find literal values or HTML elements such as SCRIPT and META tags. These tokens represent variable elements and act as placeholders until SkyBlueCanvas determines the specific values of the items with which the tokens will be replaced.

About the Tokens

There are two types of tokens used in SkyBluecanvas: user-owned and system-owned tokens. By owned we mean that either the user - the person building/managing the web site - or the system has control over where the tokens in question appear and with what they will be replaced. I refer to the process of mapping content to tokens as ‘targeting’ the content to a token.

It is very easy to distinguish between user-owned and system-owned tokens. Any token that appears in page.skeleton.html is system-owned. This means that the system will determine with what each of these tokens will be replaced. The complete list of system-owned tokens with their corresponding PHP constants are listed below.

The person building the site skin would probably not have any reason to ever use these tokens.* Most of them are non-displaying items for things such as meta, script and stylesheet tags.

User-owned tokens are any tokens that the person building the skin places in some HTML element as a placeholder for content. The complete list of user-owned tokens and their corresponding constants are listed below.

SkyBlueCanvas does not have any knowledge of the structure of the HTML of a page. It only looks for the content replacement tokens and replaces them with the content you specify in the SkyBlueCanvas administrator control panel. An in-depth explanation of how this ‘content targeting’ is done can be found in the article on Content Publishing.

A Simple Skin Example

Perhaps a better understanding of the content token replacement can be gained by examining a simple skin example and a diagram of the regions represented by each token. Diagram 2 shows the HTML for a very simple skin. Diagram 3 uses the token names to demonstrate where content targeted to each token will appear.

Diagram 2

<div id=”wrapper”>
<div id=”header”>
   <h1>{page:title}</h1>
    {region:header}
</div>
<div id=”top”>{region:top}</div>
<div id=”breadcrumbs”>{region:pathway}</div>
<div id=”left”>{region:left}</div>
<div id=”main”>{region:main}</div>
<div id=”right”>{region:right}</div>
<div id=”footer”>{region:footer}</div>
</div>

Diagram 3

Look closely at each token in the HTML example then find it in the image in Diagram 3. When you include one of these tokens in your Skin HTML then log into the administrator control panel and go to Collections Publishing [Diagram 4], these tokens are the options that appear in the ‘Region’ selector next to each page.

Diagram 4

Multiple Page Layouts

SkyBlueCanvas makes it possible to use different layouts on different pages. You can make use of this feature by creating additional HTML template files in /skyblue/data/skins/yourskin/.

Diagram 5

If you refer to Diagram 5, you will see the Page Manager interface. When you include more than one HTML layout file in your skin directory, these skins are loaded as the choices in the selector highlighted in blue in Diagram 5.

This next bit will be a little tricky so follow me closely. Refer again to Diagram 4. In this diagram you will see the Collections Publishing Manager interface. When you open the collections publisher, the publisher creates a composite list of all tokens in all of your template HTML files. This composite list are the choices in the Region selector highlighted in blue in Diagram 4.

When you select a region for a particular collection to appear in, SkyBlueCanvas saves this selection as part of the collection publishing objects parameters. Now we have come full circle back to the Skin Engine and how a page is rendered in SkyBlueCanvas. When a specific page is requested by a site visitor, the Skin Engine loads the skeleton, the page data object and all collections associated with that page into memory.

The Skin Engine then parses the template file specified for the page requested by your site visitor. The parsing of the template is a fancy way of saying it looks to see which tokens appear in that template file.

Next, the Skin Engine loads the collection publishing data file and looks for Collections that you indicated are to appear on this page. As the Skin Engine goes through the list of collections it determines whether each collection appears on the current page and if it does, in which region it is to appear. When the page HTML is built, it replaces the token for that region with the output of whichever collection or collections you specified appear in that region. If a token does not have any content specified to replace it, it is replaced with an empty string.

A Word About Collections Output

A full explanation of Collections and their output is beyond the scope of this article. However, a brief word about this subject is warranted.

The output of a Collection is defined in the module file for each collection. These module files can be found in /skyblue/data/modules/. For instance, the HTML output of the Links Collection is created by the /skyblue/data/modules/mod.links.php file.

For information about additional features related to building SkyBlueCanvas templates, go to http://blog.skybluecanvas.com/skybluecanvas-lightweight-cms/skybluecanvas-sitevars-plugin/.

* More advanced programmers can manipulate the system-owned content tokens, which will be the subject of a future article.