Hello, and welcome to CMS Made Simple 2.0. Version 2 has been a long time in coming, with a great deal of effort by a great group of people, but it’s finally here. We are starting the next generation of CMSMS with more power, more stability, and plenty of room for growth.

The effort for CMSMS 2.0 started about two years ago--around the time when CMSMS 1.11 was initially released. Our initial list of goals was small, but as time went on more goals were adopted around a central theme of improving the functionality, scalability, usability, and adaptability of our favorite content management system. We are proud to say that we have largely accomplished that goal.

Because one of our goals--as you will read below--was to not break every existing CMSMS website, the 2.0 series is not a complete rewrite of all of CMS Made Simple. There is enough new code, exciting ideas, and novel concepts that we feel it worthy of a brand new version number and not a point release.

In the following sections we will outline what has changed in this version, and how it will affect you and your sites.

  Major Goals

  Modularize

CMS Made Simple has always had a strong module API, allowing developers to create fantastic add-ons to CMS Made Simple for a variety of purposes. Our module API makes it simple to interact with the database, create appealing views, interact with the user, do ajax, and any number of things. It is indeed one of CMSMS's greatest strengths.

One advantage to the module API in CMS Made Simple is that different developers can develop multiple solutions to the same problem. And because CMS Made Simple is open source, module developers can take a module and fork it to a different name, and add functionality to it. We felt that we should support the open source concept as much as possible, and also take advantage of our powerful module API for as much core functionality as possible.

To that end, the functionality for managing templates and style sheets has been removed from individual PHP files and made into a module. Additionally, the functionality for managing content pages has been moved into a module. This makes it possible for other module developers to fork these modules and add functionality. Even the mechanism by which website administrators manage modules is a module in itself. And we have moved more of the functionality of module management into that module.

  Reduce Limitations

CMS Made Simple has always had certain limitations, particularly in managing larger sites with larger amounts of content pages. One of our chief goals in the 2.0 project was to reduce any and all limitations. This would allow us to deal with larger websites, websites of different types and purposes, and to deal with them in a familiar, easy to use way.

  Rationalize Templates

In the 1.x series of CMS Made Simple we had at least three different types of Smarty templates, each with different functionality but essentially the same purpose:

• Page Templates
• Global Content Blocks
• Module Templates

We realized that we were maintaining three different API's, and three pieces of functionality for managing what are basically the same things. We also realized that each module developer was charged with writing an interface for managing their own templates in each of their modules. This is a considerable duplication of effort by all module developers and the Dev Team. We felt it made sense to rationalize templates into one interface.

  Clean up the Code

The CMSMS 1.x API continues to carry a significant amount old code from the early days of PHP, and/or old ways of doing things. Much of it was not significantly changed in order to aid in managing backwards compatibility. There were many deprecated API functions and functionality that we were hesitant to remove in fear of breaking too many websites.

It was time to revisit this code so that we could move forward. By cleaning up the code we knew we could increase stability and readability, increase performance, and make new API's that are stable, and allow for growth. There is still more to do. More Power to the Templates

One of the significant problems that website developers and module developers face is the ability to create appealing forms. Our PHP based form API functions made this difficult. They are limited, and inflexible. We needed the ability to allow the forms to be created as much as possible in Smarty templates, where they could be styled and javascript could be used to implement great interactivity.

  Easier Navigations

Building advanced navigations has always been a difficult process in CMS Made Simple. Though the MenuManager module is powerful, and flexible, it has always been difficult to template.

One of our most important goals for 2.0 was to make it easier and faster for web developers to build powerful navigations.

  Improve Performance and Reliability

A website is nothing if it does not perform well. A slow website gets ignored by customers, gets ranked lower in the search engines, and does not show the product well to the customer. To that end we needed to remove some bottlenecks in the way data was managed, and in some of the code.

  Easier installs and upgrades

One of the things our community regularly bemoaned was the installation and upgrade process, particularly upgrades. The process of uploading hundreds of files in the 1.x series is slow and prone to error. This is usually because web developers often still use FTP to transfer files to remote hosts.

And when upgrading, people sometimes found that their site was not yet ready for upgrade AFTER the new version had been uploaded overtop of an existing version. This meant that web developers had to waste even more time restoring their site from a backup.

Fixing a corrupt config file, or missing files was a similarly tedious process. One of our primary goals was to make this easier, and save web developers a significant amount of time.

  Don't Break Everything

The biggest goal that we constantly reminded ourselves of during development was that we could not break everything. We could not--and should not--start over. Even though we were breaking some modules, getting rid of old and deprecated API's, and improving functionality, we needed to make sure that most websites could be upgraded with minimal effort.

We knew that we had to make it relatively easy for our website users to upgrade their websites to the new code, to take advantage of the new functionality and performance, even if that upgrade was not going to be as simple as most of our upgrades have been in the past.

This meant finding a balance between rewriting code for optimum growth, cleanliness, and performance and largely maintaining backwards compatibility.

  General Improvements

In this section we will go into more detail about some of the general improvements we have achieved in CMS Made Simple 2.0.

  Rationalizing Templates, Stylesheets and Collections

As mentioned above, one of our major goals in the 2.0 project was to rationalize the various template API's and interfaces. To that end, we removed the API's and functionality for Global Content Blocks (which were always a form of Smarty template), and page templates, and wrote a series of new API's to rationalize the way we interacted with this data.

Templates and style sheets are now stored in different database tables. Templates and style sheets both support locking, and descriptions, and can be optionally associated with a Design (also known as a Collection). Templates now support the concept of ownership, and additional editors. However, templates must now all be uniquely named. There is a new concept of a 'template type', which is just a loose association useful for filtering of displays. Templates and style sheets do not necessarily need to be associated with a design.

There are a few default template types created upon install. One of them is “Core::Generic” indicating a generic template. This replaces the functionality of Global Content Blocks. Similarly the “Core::Page” template type is for content pages. Core modules all create their own template types on install.

A “Design” or “Collection” is a mechanism used to associate templates and style sheets together. Any number of templates of any type, and any number of style sheets can be associated with a design.

Because style sheets are associated with designs and not page templates, now when editing a content page you must select both a template (by default only page templates are displayed), and a Design.

More information on the concept of Designs, and the new way style sheets and templates work will be described when we talk about the Design Manager further below.

  Removed ImageManager

The image manager functionality in CMSMS 1.x was difficult to use, and buggy. In CMSMS 2.0 we have merged most of that functionality into the File Manager module and removed the Image Manager completely.

  Better management of user preferences

In CMSMS 2.0 we have added the capability of resetting all of a user’s preferences to defaults, and to for an administrator to copy them from another user.

  Improved System Information

We have improved the system information page to provide more information to our users in helping to diagnose problems. Additionally, there is more information that can be pasted into a forum post to aid others when assisting with difficulties.

  UTF-8 Support for aliases and URL's

Most modern browsers now support UTF-8 Characters in URL's (as is seen by some of the new naturalized top level domain names). CMSMS 2.0 now supports UTF-8 characters in content page aliases, and URL slugs.

  Reduction of Smarty variable conflicts

On a regular basis, users of CMS Made simple were encountering problems with one Smarty variable overwriting another. This is due to the nature of the way that CMSMS uses Smarty--essentially assigning Smarty variables to a global scope. It is part of the power of CMSMS, and also one of the problem areas.

To that end, we have modified all of the core modules in CMSMS 2.0 to create a new Smarty scope for all of the front end display templates (at least the front end templates). Additionally, each part of the page template that is processed separately is in its own Smarty scope. This, for the most part, solves the problem.

The functionality of creating a Smarty variable in a module template, and using it in a different part of the page template, remains. The procedure for this has changed, however, therefore there is a small compatibility issue that you may encounter when upgrading.

  Improved UDT interface

The interface for the User Defined Tags has been improved to make it easier to interact with. We now use a jQuery-ui dialog to display the output from running a UDT.

  One Admin Theme

Up until CMSMS 2.0 we supported two admin themes in the core. This was problematic as the CSS classes for those two admin themes were inconsistent. The inconsistency made it difficult for module developers to create more extensive and advanced interfaces in their module's admin panels.

The Dev Team voted on the issue and decided that we would maintain one admin theme, and that that theme would be the OneEleven theme.

Dropping support for the NCleanGrey admin theme in the core allows developers to create better module interfaces, and to go forward with developing a style guide for module developers.

  Increased Content Capacity

On a fairly regular and increasing basis our user community was reporting that there were limitations of 64kb of data in each content block, content property, template, and stylesheet. We have increased that limit to 2MB across the board.

  jQuery-UI Based page selector

One of the limitations of CMSMS 1.x was the fact that when selecting a page whether it be the parent page when editing a content item, or when selecting a page as a preference in a module admin panel, a single drop down list was presented. This was slow and cumbersome when the number of pages in a website grew past a couple of hundred items. To that end, we have written some new ajaxy jQuery-ui functionality, and a custom control that makes selecting a content page a bit less cumbersome, even though it may require more mouse clicks on larger sites.

  More Smarty plugins

As mentioned above, in order to give more control to the designer when modifying templates, particularly those with forms, we have created a few more Smarty plugins for CMSMS. Here are some of the new plugins:

• cms_action_url
  This plugin allows creating a URL to any module action. It is useful in both backend and frontend templates.
• cms_html_options
  An advanced plugin for providing an array and building a select.
• cms_module_hint
  A new plugin that allows specifying default parameters to modules on a per-page basis, without having to specify them in the module call, or on the URL.
• cms_yesno
  A simple plugin useful for creating a yes/no option.
• form_start
  This is a flexible plugin for building a CMSMS compatible
  tag. Particularly for forms that must be submitted to modules. As CMSMS requires a few hidden input fields to be submitted with each form so that the proper module action can be called, we wrote a Smarty plugin so that developers could add styles and attributes to the form tag, and still allow it to work with the module. Sample usage would be something like:
  {form_start class="myform" id="something" style="border: 1px solid blue;"}
• relative_time (modifier)
  This is a simple Smarty modifier to convert a date to a relative time from the current server time.
• admin_icon (admin only)
  A simple plugin to assist in adding icons from the admin theme into a template.
• cms_admin_user (admin only)
  A simple plugin for retrieving information about a specified admin user.
• cms_help (admin_only)
  This plugin aids in creating context sensitive help for a module's admin panel.
• page_error (admin_only)
  A plugin to display an error message in a way that is consistent with the admin theme.
• page_warning (admin_only)
  A plugin to display a warning message in a way that is consistent with the admin theme.
• tab_header (admin_only)
• tab_start (admin_only)
• tab_end (admin_only)

The above plugins are useful in a module's admin panel templates to aid in building a tabbed interface. These plugins make it easier for a module developer to merely provide all of the data to Smarty and to do all of the form layout in the Smarty template, where it belongs.

Note that we did not create Smarty plugins for each and every type of input element. We knew that in order to do that we would need to create overly large and complex plugins that would accept any and all of the attributes that each input field accepts in both HTML 4 and 5. We felt that it is better to allow the module developers and website developers to do as much work as possible in HTML when building forms so that they can take advantage of all of the features of HTML, of various frameworks, and of javascript.

  File based Template support for modules

When re-working the template API it became apparent that developers occasionally like to work with file based templates so that they can use their favourite editor. The new API allows for specifying a file based template vs. a database template just by adding a .tpl file extension to the template name when requesting it. With the exception of content pages this works throughout the system.

  Preload Pages and Templates

CMSMS 2.0 now remembers the list of pages that needed to be loaded for a frontend request, and the list of templates (from the new API) that need to be loaded, and loads them automatically.

This saves a number of database queries for repeated requests for a page, and significantly improves performance.

  CMSMailer Changes

The mail API has now been rewritten and merged into the core. Use of CMSMailer is no longer required. The settings for sending mail is now located in the global settings panel.

Though a CMSMailer module exists as part of the core, it is now just a stub module without an interface. Its only purpose is for backwards compatibility with older code, and as such it is not installed by default for new installs.

Improvements to the core page types

The core page types have been improved, particularly for the “Content” type. Among other features are the ability to adjust the sorting of content blocks from within the template, to specify default values for each content block--and a place holder value, and the ability to set a content block as required. This provides the website builder with significantly improved control over how the content editing page will appear, and its behavior.

The organization of the various elements for the core content types has been re-organized to be more logical when editing those content items. For example, when editing a 'Content' page in CMSMS 2.0 there are now at least five tabs in the form. “Main”, “Navigation”, “Logic”, “Options”, “Permissions”, and, of course, “Preview”.

  Context sensitive help

All of the new functionality, and much of the existing functionality, has been adjusted to add context sensitive help. This makes learning the functionality of CMSMS much easier for the content editor or even for the designer.

  Separation of settings from functionality in the admin interface

In CMS Made Simple 2.0, many of the forms to control various settings have been moved away from the functional interface to theirown entry in the admin navigation, with different permission controls. This not only makes the interface for those with restricted permissions more simple, but it makes the module code much more simple as well.

  Changed config entries

The admin_encoding and default_encoding config entries have been removed and will serve no purpose.

The tmp_cache_location, tmp_templates_c_location, and public_cache_location variables are new config entries. They allow modifying the location where CMSMS stores its temporary files. If possible, it is advisable that the tmp_cache_location and tmp_templates_c location variables be set to paths that are writable by the php process, but not publicly browsable.

The public_cache location should be set to a location that is writable by the php process, and below the root of your CMSMS install, and browsable by the public.

There are a few other config entries that are no longer relevant. The current list of relevant entries is contained in the CMSMS_Config_Reference.pdf file that is included in the distribution.

  Code Optimization and Caching

A significant amount of time has been spent optimizing the performance of CMSMS. This includes profiling, doing query analysis, and writing new mechanisms to reduce the amount of time that CMSMS spends communicating with the database.

  New Install / Upgrade / Freshen Assistant

As previously mentioned, the old installation (and particularly the upgrade) routine was problematic. We needed to come up with something better--and, thanks to the new technologies available in the newer versions of PHP, it was possible.

The new Installation Assistant is a self-contained executable archive that contains the entire distribution of CMSMS, all of the language packs, and ll of the installation and upgrade procedures, in one binary file. Installation, upgrading, and freshening an installation of CMSMS is as simple as transferring one file to the server, and then browsing to it. It is possible to perform the system tests and check for permissions problems without corrupting an existing install of CMSMS.

This new Installation Assistant has many features:

• The ability to select which languages you want to install without having to download the full version, or multiple language packs.
• Freshen an existing version (copy all of the core files overtop again), and re-create the config file
• Backup the existing config file in the event of a freshen or upgrade.
• An advanced mode with more options and more verbose output
• Better, and more verbose system tests and permission checks
• More checks to ensure that you are not accidentally installing over an existing system or an incompatible system.
• More...

  Core Modules

As mentioned in the introduction, some of the primary goals of the 2.0 project was to move more core functionality into modules; to improve the front end navigation building process, and to improve usability. To that end, numerous new core modules have been written, and many more have been changed.

Here is a brief list of the new core modules and what has changed in the other core modules.

The Content Manager module

The content management and editing functionality of CMS Made Simple has been completely rewritten using the module API. Moving this functionality provides numerous benefits:

• The ability to create better user interfaces easily
• The ability to replace the module with another that provides different functionality
• Increased stability and security

This module provides a great deal of improved functionality over the content management of CMSMS 1.x:

• The ability to expand and collapse the content list, as well as the ability to paginate
• The ability to quickly search for a page to edit by name or alias
• Cooperative locking so that one user cannot easily accidentally overwrite the changes of another
• More control over what columns are displayed in the content list
• Better control over default values for new content pages
• More information displayed in popup help

The Design Manager module

This brand new module serves the purpose of integrating the management of all different types of templates, style sheets and designs. This module has many features:

• Create, edit, copy, and delete templates
• The ability to set a template as the 'default' for its type
  (for use when a template is required for a specific action, but one is not explicitly specified).
• The ability to manage template categories.
• The ability to reset the factory default content for a template type
• Create, edit, copy and delete style sheets
• Create, edit, copy and delete collections
• The ability to filter and quickly find templates of a certain type, category, module, etc.
• Associate style sheets and templates with collections
• Export designs to an XML file for use on other sites
• Importing XML based collections
• Importing XML Themes from CMSMS 1.x
• Cooperative locking so that one designer cannot accidentally overwrite another's changes.

The Navigator module

The Navigator module is the new module use to generate navigations on the front of the website. Like the MenuManager module, it uses the content page tree as its basis for data, and Smarty templates to form that data into an HTML Navigation.

Unlike the MenuManager module, this module generates and provides to Smarty a hierarchical dataset. This dataset can be used recursively within Smarty. This makes the navigation templates more simple and more logical to understand. It also allows for advanced functionality like giving special classes based on the first or last child of an item, its index, and its depth.

This module does not have an admin interface. The Design Manager module manages the templates for the Navigator module, and there are no other settings. It supports the same options as the MenuManager module and provides breadcrumb functionality as well.

The AdminSearch module

As evident in the name, this module provides search functionality within the admin interface. It is extremely useful for identifying the template, UDT or style sheet that has a specific piece of text.

This module will make development and maintenance faster for all users of CMSMS.

The MicroTiny Module

This simple editor has been completely rewritten for CMSMS 2.0. It uses tinymce 4, has much more functionality, and is significantly easier to use. Additionally, a new media picker has been written for MicroTiny to make inserting images, links to files, or videos much easier.

The Module Manager

The functionality from “Extensions >> Modules” has been merged with the functionality from the existing module manager, and then that functionality expanded.

The new ModuleManager makes use of icons and colours to tell you if there are newer versions of an installed module available in the Forge, if the module is a system module, needs upgrade, if the module is deprecated or stale, and more.

The module takes advantage of a new config variable entitled 'developer_mode' to enable and disable functionality that is normally only used by module developers.

MenuManager, News and Search

These modules have been adjusted to take advantage of the design manager, and to eliminate Smarty variable scope issues. That means that there is no longer an interface for working with templates inside the admin panel for these modules.

  What hasn't changed

Adodb-lite

In 2.0 we still use the same (heavily trimmed, and modified) version of adodb-lite as the 1.x series. This is for a few reasons:

1. The core adodb-lite package has not had a new release since 2007, so we are the only ones maintaining the package.
2. The original adodb package is large and appears to be slow (according to our tests) and would seriously increase the size of the distribution package even though we would only support a small portion of it.
3. We must be extremely careful when playing with the database abstraction layer as introducing incompatibilities has the potential to break each and every module and each and every CMSMS website.
4. Due to time constraints there was no time to take on replacing adodb-lite with our own compatible layer.

Menu Manager

Though the admin interface has been removed from the MenuManager module in favour of using the new API's of the design manager, the MenuManager remains. This should reduce the problems with sites attempting to upgrade.

However, we have officially deprecated this module, which means it will not receive any more new features, and will be removed from the distribution at a later time.

News and Search

Although we have changed these modules to use the DesignManager for templates, the functionality of these modules has changed little. CMSMS based websites using these modules should have little difficulty with upgrading related to these modules.

  Requirements

CMS Made Simple 2.0 Now requires a minimum of PHP 5.4.11. However, we encourage you to take advantage of the bug fixes and security fixes in PHP and upgrade as far as possible.

PHP 5.5 introduces a new opcode cache which can reduce the load time on servers, and reduce the amount of time required to render pages by 50 percent or more.

  Upgrading

As previously mentioned, because there are so many significant improvements in CMS Made Simple, not every website will be able to upgrade to 2.0 cleanly.

Here are some of the things that we have encountered and some suggestions as to how to fix them.

CMSMailer

The CMSMailer functionality has been moved to the core. The CMSMailer module itself is only left for compatibility purposes. If your module still lists CMSMailer as a dependency, be sure to install that module.

Duplicate Template Names

Frequently, website developers would name page templates, global content blocks, MenuManager, and News templates, and the templates of other modules to match the name of the site, or theme that they were building. The Design Manager now requires that each and every template has a unique name.

The upgrade routine will enforce that every template has a unique name by appending an incremental number after the name. This could result in many exceptions where Smarty says that it could not find a template.

To resolve the problem you will need to modify the appropriate parent templates, and change the call to the template to its new name. This may require considerable testing.

Global Smarty Variables

CMSMS 2.0 introduces the concept of 'scopes' in Smarty templates. This version of Smarty does not treat each and every variable as a global. This will solve problems with Smarty variables being inadvertently overwritten, but will cause problems with websites that rely on some global variables.

Formerly, you could create a variable in a module template (for example the News detail template could set a canonical variable) and then use that variable in another template, such as in the portion of your page template. Though this is still possible, an additional step is required.

CMSMS by default splits the page template up into three “sub templates”; and therefore three different scopes:

1. The portion of the page template before the <head> section.
2. The portion of the template from <body> onward.
3. The <head> section of the template.

Now, variables created in one portion of the template will not automatically be available in the other portions. Similarly, some module actions may create new variable scopes. If you want to use a Smarty variable in different templates you must explicitly make those variables “global”.

This is simple to accomplish. All that is needed is to add the scope=global attribute to various assign tasks, e.g. from the news detail template:
{assign var='canonical' value=$entry->canonical scope=global}

  Resource Names

The 'template': resource which formerly referred only to CMSMS page templates has been removed. It has been replaced with 'cms_template', which refers to any template using the new scheme.

This means that any template using inheritance, or includes, may need to change their templates to use {include file='cms_template:template_name} instead of {include_file='template:template_name'}

Also, be careful of renamed templates during the upgrade, as mentioned above.

  Incompatible modules

Due to the aforementioned API changes in CMSMS 2.0 we have broken some modules. With very few exceptions the changes required to get a module to be compatible with CMSMS 2.0 are very minor.

Before attempting an upgrade you should ensure that the modules you are using are compatible with CMSMS 2.0. You may need to contact the module author or inquire on the CMSMS forum.

  Customer Editable GCB's

Because GCB's (Global Content Blocks) were essentially Smarty templates, the functionality of GCB's has been merged into the DesignManager. There is no longer any separate functionality for customers to be able to edit 'shared blocks' using a WYSIWYG editor.

However, with the assistance of the {page_attr} Smarty plugin that was enhanced in CMSMS 2.0, the same page template and content editing mechanism can be used to simulate the GCB mechanism:

1. Create a new, very simple page template that looks something like this:
   
   {content}
   {content block=foo} {* note, the label, tab, required etc. parameters can be used here *}
   {content block=gcb2}
   {content block=gcb3}
2. Create a new content page, and specify the page template you just created above. You can set this page to not show in navigations, set it to be non-searchable, and even set it to be protected. You can also set the owner, and additional editors for this page.
   Your editors can now treat the content areas in this page as 'shared blocks' or “Global Content Blocks”
3. Every place where you would like to use the content from one of these blocks, where you would formerly use:
   {global_content name='foo'}
   you can now use
   {page_attr page=”*page alias from above *” key=”foo”}

  {site_mapper}

The {site_mapper} plugin is now an alias for {Navigator template='minimal_menu.tpl'} and no longer uses the MenuManager module.

  Summary

CMSMS 2.0 is a renewal, a refactoring, and a re-generation of a great content management system making it even better. Thousands upon thousands of hours of effort have gone into development, testing, documenting, and supporting CMSMS 2.0.

CMSMS 2.0 cleans up much of the detritus left from earlier technologies and past mistakes, and creates provides a great foundation for building better websites and better applications. CMSMS 2.0 is simultaneously faster, lighter, more flexible, and more powerful than its predecessors.

Though there will be some adapting to learning the new tools CMSMS 2.0 provides, and web developers will experience some grief with upgrading websites to use CMSMS 2.0, we feel that the extra effort will be worth it.

CMSMS 1.x will continued to be supported for critical bugs and security issues one year (365 days) after the release of CMSMS 2.0. This will give you time to ensure that all of the modules that you use are ready for CMSMS 2.0 and to learn about the fantastic features of this new version on some new websites before you start upgrading. But don't wait till it’s too late!