CMS Made Simple has undergone many changes in this version. We have added lots of new flexibility, power, and improved usability. With these big changes there is always some breakage, but for most users it should be minimal and easy to fix. The beta program is the opportunity to review all of these changes, and test your apps when time isn't an issue while simultaneously contributing back to the CMSMS community. It is also the time for module developers to make the necessary changes to their modules and release new versions so that their code remains relevant.

Our goals

Goal 1: Separate business logic, configuration, and design into files as much as possible. Keep core files separate from third party code.

Whether a professional is building a simple static website where the content does not change too often, or complex, dynamic, business applications, there are some questions often asked:
- How do I use my favourite tools so that I can develop quickly and easily?
- How do I easily save my work, track what I've done over time, and easily revert my work if I need to?
- How can the team work on the application simultaneously?
- How can i integrate other third party tools and libraries into my workflow?
- How can I easily separate development work from testing and live, and move changes back and forth?

To address these concerns, the primary answer is to store as much as possible in good old fashioned files. When business logic, configuration, and design is in files, developers get to use their favourite editors to edit them, even over the internet. They can use tools such as GIT and Subversion to save their work, track and merge changes, and revert work if necessary. Multiple editors can work on files (maybe even the same files) at the same time. And since only data is stored in the database, managing separate development, testing and live installations is much simpler.

Additionally, separating 'core' files from 'developer' files is one step further along that process. Allowing developers to keep their work separate from the 'core' and from data.

These concerns, if addressed well, make development faster, and simpler. That's what CMSMS is all about.

Goal 2: Make building web applications with CMSMS simpler and faster for developers

"Simpler" is a subjective term. It means different things to different people, even in the context of a simple web application. So for this release we took "simpler" to mean, in a nutshell: "going forward there should be fewer problems, gotchas, and caveats."
To that end, we have focused on improving the templating and module development processes to remove many of those 'gotchas' and caveats.

Goal 3: Ensure that CMSMS is fast, flexible and secure.

Performance and security in a web application are always concerns. In 2.3, we continue to analyse and optimize the code to ensure that web applications perform well out of the box and continue to be secure.

Goal 4: Simplify and clean-up CMSMS. Upgrade our dependencies and clean up the code.

Code gets old over time. Technologies change, and lessons are learned. So in 2.3 we took the opportunity to clean as much of the code as possible to allow us to grow in a forward direction, while always keeping in mind maintaining as much backward compatibility as is reasonable and maintaining performance. Cleaning up the code also allowed us to remove more of those problem', 'gotchas', and caveats.

Goal 5: Improved error handling
Another goal was to move to a state that if there was a serious error in the application, either from a configuration error, an error in the code, or a syntax error in a template that the error was displayed in a way that was easier to detect through scripting, to identify, and for a developer to fix. This is opposed to generating weird display artifacts or hidden error messages.

Goal 6: Power to the professional, Simplicity for the end user.
We keep this mantra in our minds at all times when developing. CMSMS 2.3 has new features to make managing content easier for end users, and improved functionality for developers to improve the experience for end users, while getting out of the way of the development process.

The big picture

Here's a brief list of the major changes in CMSMS 2.3. As mentioned above, there are some things that will be broken on upgrade and developers will need to make some changes. You can read more about breakages below.

1. User Defined Tags are now Simple Plugins
This is perhaps the most controversial change. User Defined Tags (UDTS) are business logic code. They are part of the application, and as such they should be kept with the rest of the business logic. As well, because they are stored in the database it complicated factors to maintain different development, staging, and live installations. Not to mention the fact that because UDT's use the problematic and insecure eval() methodology, they caused confusion when errors occurred.

So we have migrated to something we called 'simple plugins' (it is a boring name, we know) that stores the same code as files. Now this business logic is kept with the other business logic code, is more secure, and because it uses the normal php include process they are faster and less problematic. We have also removed all user interface for managing UDT's from within the CMSMS admin console. Developers can use their favourite editor for these and store them in their source code repository.

2. Support for file based themes.
Allow themes containing templates, stylesheets and other assets to be located entirely in the /assets/themes directory. Adds new cms_theme Smarty resource and companion plugins {cms_set_theme}, {cms_theme_path} and {cms_theme_url}.

3. Dropped the News module from the core distribution, added PressRoom as a core module
The News module was always intended merely to be a sample module for other developers to use as a reference when developing their own third party code. Over the years it got new features, and bug fixes but was never really maintained as an ideal example module. We determined that there would be a significant amount of work involved in converting this module to work for it's original purpose, and that doing so would still probably break installations for those that are using this module in production.

So a new module was written, called PressRoom. Though this is a similar module in purpose, it has different features than the News module and is not compatible with the data stored in News. This new module takes advantages of new functionality in 2.x such as the File Picker, has less interface and the code is much simpler. Going forward, PressRoom will serve as a better reference module.

The News module continues to work in CMSMS 2.3, and there will be no data loss. We are merely no longer shipping it with the CMSMS Core. It will now be treated as a third party module that happens to be owned and maintained by the Dev Team.

4. Rewrote all internal logging and added the new AdminLog core module.
Until 2.3, the only functionality developers and managers had for keeping track of a history of things was the AdminLog functionality, and a single companion API function. This functionality was not powerful enough and the code was old and ugly. So 2.3 includes several new api functions for logging, a flexible logging mechanism and the new AdminLog core module to better manage a history of recorded things.

5. Dropped the MenuManager module from the distribution
The MenuManager module was deprecated from CMSMS as of version 2.0 when Navigator was introduced. We now no longer distribute the MenuManager module with the core. For upgraded installations it continues to work, and will continue to operate for some time.

6. Dropped Events, migrated to hooks
Like UDT's, Events were part of business logic and were stored in the database, which was unfortunate. In 2.3 we have removed all UI for events, and moved to hooks. A new file in the assets directory will allow connecting hooks to simple plugins.

7. Replaced the core OneEleven admin theme with an updated version called Marigold
The updated theme is lighter, cleaner, and uses better open source icons.

8. Removed all internal use of Smarty caching
The Smarty caching functionality in CMSMS was problematic with respect to dynamic applications, and it was hard to use well. For 2.3 we have removed all of the functionality related to Smarty caching. Third party tools such as varnish or other other proxies serve this purpose in a much better way.

9. Numerous improvements to the Content Manager
Keeping in mind the content editor or administrator several new small but significant features have been added to the Content Manager.

10. Removed the ability to have individual pages as 'secure' or 'not secure'
Back in the day when SSL was new and SSL certificates expensive and often shared it made sense to allow some pages to be secure and others insecure. Now the tables have turned, and recommended practice says that all applications should be entirely served over HTTPS. We have removed the option to mark pages as secure or insecure, and changed the appropriate config entries.

11. New and improved 'simplex' theme for new installs that demonstrates the new modules and new principles
The improved simplex frontend theme demonstrates many of the new plugins in 2.3, and advanced topics like Smarty template inheritance.

12. Added a new 503 System Page type for when the 'site is down for maintenance'
Now when your installation is down for maintenance it can generate a 503 response code, and you can customize the HTML.

13. Refactor 'non pretty' Module Action URLS to be secure by encoding and signing them.
Now, by default when generating a URL to a module action (such as a PressRoom detail url) the system will encode the parameters and sign the result. This makes module action URLS harder to forge. This does not affect mod_rewrite urls or internal pretty urls. For new installs, internal pretty urls are now enabled by default.

14. Moved third party modules into the /assets/modules directory
In order to keep 'business code' separate from 'core code' we have now moved all core modules to /lib/modules, and all third party modules to /assets/modules. This may break some installs that use modules that do not use the proper API functions to determine paths.

15. Improve page template processing. No longer parse top, body and head sections separately by default.
With the addition of some of the new plugins we no longer need to process page templates in any special way. We no longer need to process the top, then the body and then the head as separate templates and then glue them back together. This removes a lot of 'gotchas' and caveats from the templating process. If you wish to continue to use the old technique, there is still a config option for that.

16. Removed the {cms_jquery} plugin
This plugin has always been problematic, and because of the new {cms_queue_script} plugin and other third party plugins, this function became redundant and not worth maintaining.

17. Now try to fail instead of generate obscure embedded messages.
In the development of 2.3 we have endeavored to make things more testable. To that end we have made numerous changes to ensure that when there is a problem we throw an exception and bring up that 'Oops' page that is all too familiar. Then developers can track down the error and fix it. This is much better than generating HTML comments or other error messages that pollute the display. Therefore, some plugins that were 'stubbed out' for backwards compatibility purposes have been removed. Installs using those plugins will now generate errors until they are removed from the templates.

18. Large cleanup and refactoring of many APIS
In order to trap bugs, and move towards the future we have gone through a massive cleanup of our API. This includes removing singletons, renaming some classes (mostly internal ones), utilizing namespaces, implementing type hinting, removing deprecated functions etc. Though most common modules should not experience much breakage due to this, there could be some.

19. Improve internal caching
As part of the cleanup and refactoring we were able to significantly clean up the caching mechanisms. This should lead to a noticeable performance increase in many apps. Additionally, this allowed us to add the ability to optionally use APC functionality for in-memory caching for those hosts which have it available.

20. Better handling of javascripts, standalone stylesheets, and meta tags via Smarty plugins
The new Smarty plugins {cms_queue_script}, {cms_render_scripts}, {cms_queue_css}, {cms_render_css} allow queuing and rendering scripts and stylesheets. The appropriate tags are rendered in the order that they were called and use hooks so that they can be called from within module actions as well. This simplifies the issue of utilizing different scripts and stylesheets in different pages, and rendering the tags at the template bottom.
The {cms_pagestr} plugin and class similarly add the ability to create and edit meta tags in the page template, and in module actions and to render them in the head. This reduces much of the need for 'global' Smarty variables.

21. Refactored admin login functionality
The CMSMS Admin login functionality has been refactored and improved, primarily for security purposes, but also to provide the ability for third party modules to add functionality.

22. Improved security for cookies and cache files
All cookies stored by CMSMS now are encoded and signed to minimize the risk of cookie corruption or MITM attacks. Additionally, the built in filesystem cache mechanism signs all files and verifies the signature on read to even further reduce the possibility of hacking.

23. More...
Although the major changes in CMSMS have been outlined above, there are many new significant changes in version 2.3. The changelog is detailed and extensive. Please read it. You will be surprised at how busy we have been.

Stuff We Broke

As described above there are some breakages in this version. Some installs may not work until various things are fixed. Here's a list of most of the major breakages

1. The location of modules.
Third party modules are now installed into /assets/plugins. Core modules are now installed to /lib/modules. Some modules do not use the provided API functions (they have existed for a long time) and assume that modules will always exist in /modules. LISE and Guestbook appear to be two of these modules.

2. Removed the {cms_jquery} plugin
Developers will now need to embed script and stylesheet tags for these libraries on their own. See the new {cms_queue_script} and {cms_queue_css} plugins.

3. Changed template processing order
The new template processing order is to not split up page templates, and to not process mact requests until they are called. Some installs may need to
change the 'content_processing_order' config entry.

4. Removed the secure option from content pages.
Installs must now be either entirely secure, or insecure. HINT: LetsEncrypt certificates are free.

5. Module's use of deprecated API functions and properties
Some modules that use API functions that have long deprecated may now break. Encourage the developers of these modules to fix them.

6. We no longer handle the {$actionid}showtemplate=false get parameter
Formerly this was one way to disable template processing. Though "showtemplate=false" still works.

7. The params array of module action calls no longer includes the 'id', 'returnid' or 'action' entries.
These are available as variables in module actions
These parameters existed in the past but were never supported or documented.

8. Admin theme API changes
Because of code cleanup and other improvements, third party admin themes may need some minor adjustments.

9. Removed stub plugins
The {breadcrumbs} stub plugin and others have been removed. If page templates still use them they will now generate errors.

10. Upgraded jquery and jquery-ui libraries
Any modules or code that depended on the old versions of these libraries may experience problems.

11. Modules that register new content types can no longer be lazy loaded.

12. Some methods of the Events class has been removed (particularly those that create or delete events)

13. The Content classes got some refactoring to remove database functionality.
Some code that directly called these methods will break. Should use ContentOperations instead.

About the Beta

We expect that the beta program will last a few months as users report issues and they are fixed. New beta releases will be created periodically as important issues are fixed or as numerous minor fixes are accumulated. Probably every few weeks. We will announce every new beta in the CMSMS forum.

The production release of v2.3 will be made at the discretion of the dev team when it appears that the number of bug reports has declined, that the package appears stable and it is logical to release.

Where can I get it

CMSMS v2.3-beta is available directly from the CMSMS Core downloads page. Or you can visit the CMS Made Simple project on the forge.

What we need you to do

This is a beta release. The features for this release, and all of the major functionality changes are done. We have undergone a fair bit of internal testing, and are now ready for others to help us to make this software 'production ready'. We expect that there will be some problems, and maybe a few minor things missing or still to be done. But it should generally feature complete, and functional.

Because you will always use CMSMS in ways that we have never thought of, we encourage you to download it, install it and test it. Play with the new features, read the documentation and see how it will work for you. We also encourage you to try upgrading some installs (keep the described breakages in mind) and report the problems you have, and your questions.

This goes without saying, but we'll say it anyway: Please do all testing on development servers with reliable backups. Never install a beta version on a live site.

How to report issues

We have created a new board on our forum entitled "v2.3-Beta" that is intended specifically for talking about and reporting issues related to v2.3. Please use this board to inform us about your issues.

Please also provide enough information so that other developers may easily reproduce your issues in their environment. Also include any relevant messages from your error logs and your system information.

Fin...

Have fun testing the beta. We look forward to hearing from you.