Read more about this book |
(For more resources on Content management, see here.)
CMS Made Simple is a powerful system for creating websites. Even the base install enables you to easily produce sites with many sophisticated features. There are times, however, when you need to be able to do things that are beyond the basic capabilities. You can often find pre-made extensions on the official CMS Made Simple sites: Tags and Modules in the Developer’s Forge (or directly through the Module Manager), and examples of User-Defined Tags on Wiki or posted in the forum.
What are these different kinds of extension? This article will answer that question in greater detail. However, we will define them briefly here. All three types of extension share some things in common: they are PHP code which can be embedded in site pages, templates, or Global Content Blocks, or may be called by other code. A User-Defined Tag is distinct in that you can create and edit it through the CMSMS admin area. A Tag is similar, but must be placed as a file on your server, and provides more information to the site administrator. A module has available to it the rich functionality of the Module API, and enables the creation of much more complex applications.
As mentioned before, there is a wealth of pre-made extensions which are available to you. But even if these pre-made extensions don’t meet your needs, all is not lost. You can jump in and create your own extensions! You will discover that the power of CMS Made Simple is only limited by your imagination.
In this article, we will learn how to approach the problem you’re trying to solve. Is it something that can be solved without writing an extension? Would you be able to use or adapt an existing extension? If not, what conditions will the extension need to handle? The requirements that you think of will help you determine what kind of extension you should implement.
There are three recipes here that will help you to identify which kind of extension is appropriate for a given problem, and three recipes that go over the basics of creating each major type.
You have reached the point where you know you need to extend CMS Made Simple to solve some particular problem, but you may not yet know what approach to take. Your options are to create a Tag, a User-Defined Tag (UDT), or a Module, but which will be best to solve your specific problem?
This recipe will help you examine your problem and consider whether creating a UDT is the most appropriate solution.
First, we determine if the problem you want to solve is one that will require you to write some custom code. This is the easy part. You’ve already considered whether or not an existing solution will suffice and have decided that it will not. So the next step is to figure out whether or not a User-Defined Tag is the correct approach to solving the problem.
Go through the following list, and for each item, determine if it applies to the problem you are trying to solve. Feel free to write down a list of your answers (yes/no).
If you answered “no” to all of the above questions, a User-Defined Tag is a good candidate!
A User-Defined Tag is a way to connect a tag, that will be recognized by Smarty, to an arbitrary bit of PHP code. That PHP code can do anything. While there are very few things that cannot be done in CMS Made Simple using UDTs, it doesn’t necessarily mean that a UDT is the best approach for everything. Because User-Defined Tags are so versatile, the best way to determine if they are the ideal approach is by disqualification. We ask questions about the few things for which UDTs are less optimal, to see if any of those things match our requirements. If none of them match, then a User-Defined Tag is probably the best approach.
If we do find that our requirements include functionality for which UDTs are not ideally suited, we should consider using a Tag or a module instead.
For now, let’s look at those qualifying questions again and examine why they would encourage us to use a different approach.
Disqualifying Question | If you answered “Yes” |
Can the problem be solved by simply using Smarty? | We don’t need to write any PHP code at all! |
Does your problem require multiple actions? | It is, in fact, possible to handle multiple actions using a User- Defined Tag, but it is not elegant. If you need to support multiple actions, the CMS Made Simple Module API has extensive support for doing so, as well as conventions that will help keep the code separated nicely into maintainable chunks. |
Do you need localization or internationalization? | Again, this would be possible to do in a User-Defined Tag, but you would have to do all the work. The Module API provides utilities for simplifying this enormously. |
Will you need an Administration Panel? | There is no easy way to implement an Administration panel in a UDT, so this would strongly push you in the direction of using a Module, where a rich set of functions make the task easier. |
Will you want to share your code? | While nothing would stop you from sharing the code you write as a User-Defined Tag, there are neither facilities for making the process simple nor standards for documenting the UDT. Furthermore, UDTs exist only in the database, as contrasted with Tags and Modules that exist as files, so they are not as easy to simply package up and share. |
Do you need to create database tables or preferences? | You could write logic into your UDT to check on the existence and conditionally create database tables or preferences, but it would be easier to use the Module API that has specific support and standards for doing those operations. |
Do you want your code to display help text in the Admin area? | As mentioned before, User-Defined Tags offer no facility for displaying help text to the Admin. Both Tags and Modules, on the other hand, have standard methods for doing so. |
Will your solution serve as a Smarty modifier? | User-Defined Tags cannot natively work as Smarty modifiers, while Tags can do so easily. |
As in the previous recipe, you know that we have three different possibilities for extending CMS Made Simple and solving a problem: User-Defined Tag, Tags, and Modules. Deciding which of these is the best approach, however, requires additional knowledge about the strengths and weaknesses of each technique.
This recipe will help you examine your problem and consider whether creating a Tag is the most appropriate solution.
The criteria for deciding to use a Tag to extend CMS Made Simple are quite similar to the criteria for a User-Defined Tag.
To figure this out, consult the following list, and determine if each item applies to the problem you are trying to solve. Feel free to write down a list of your answers (yes/no).
If you answered “no” to all of the above questions, either a Tag or a User-Defined Tag would be a viable approach. To decide whether a Tag would be better than a UDT, consider the following questions:
If you answer “yes” to any of these three questions, you should write a Tag instead of a User-Defined Tag.
A Tag is a way to connect a Smarty tag to some PHP code. The PHP code can do anything. Like in the case of User-Defined Tags, there are very few things that cannot be done in CMS Made Simple using Tags.
Because Tags are so versatile, the best way to determine if they are the ideal approach is by disqualification. We ask questions about the few things for which Tags are not ideal, to see if any of those things match our requirements. If none of them match, then the problem could be solved by either a Tag or a User-Defined Tag. To make the decision between those two approaches, we consider a few other criteria that will steer us in the right direction.
Let’s consider the disqualifying questions again and examine why they would encourage us to use a different approach. The first five questions are the same as they were for User-Defined Tags.
Disqualifying Question | If you answered “Yes” |
Can the problem be solved simply using Smarty? | If this is the case, we don’t need to extend CMS Made Simple at all! |
Does your problem require multiple actions? | It is, in fact, possible to handle multiple actions using a Tag, but the CMS Made Simple Module API has extensive support to simplify multiple actions, as well as conventions that will help keep the code separated nicely into maintainable chunks. Thus a Module would be a much better choice. |
Do you need localization or internationalization? | These features could theoretically be implemented using a Tag, but there is no built-in support for either. The Module API, on the other hand, has facilities specifically to simplify those tasks. |
Will you need an Administration Panel? | There is no easy way to implement an Administration panel in a Tag, while the Module API has numerous methods specifically for this purpose. |
Do you need to create database tables or preferences? | You could write logic into your Tag to check on the existence and conditionally create database tables or preferences, but it would be easier to use the Module API which has specific support and standards for doing those operations. |
Now, let’s consider the three things that differentiate a Tag from a User-Defined Tag:
Tag Qualifying Question | If you answered “Yes” |
Will you be sharing this solution with other people? | A Tag is stored as a file on the server, which makes it easier to share with other CMS Made Simple users, since they can simply place the file in their own installation. A User-Defined Tag, on the other hand, is stored in the database, that adds extra steps if you want to share it. |
Do you want your code to display help text in the Admin area? | The structure of a Tag has a special method for presenting information to the site administrator, while a User-Defined Tag has no such mechanism. |
Will your solution serve as a Smarty modifier? | There are several kinds of Tags, including Smarty modifier tags. There is only one kind of User-Defined Tag, and it will not work as a Smarty modifier. |
The previous two recipes have shown you how to assess two possible types of CMS extension, and to see if they are optimal for any specific problem. This recipe rounds out the analysis and shows you how to determine whether creating a Module is the most appropriate solution.
By examining your requirements, and comparing them to the strengths of the Module API, we can figure out whether or not a Module is the best way to implement your extension.
To do so, consult the following list, and determine if each item applies to the problem you are trying to solve. Feel free to write down a list of your answers (yes/no).
If you answered “yes” to any of the above questions, a Module is going to be the best way to implement your extension—with one possible exception. If you want to write an extension that you can apply to Smarty variables within a template to reformat their output (that is, a Smarty modifier), you will need to use a Tag. However, outside of that one case, a Module will be your best bet. If you answered “no” to all of the above questions, you could still use a module, but you might want to consider using a Tag or User-Defined Tag, as you will still be able to solve your problem with less complexity and overhead.
A Module is PHP code that extends the CMSModule Class, which means that you start with a rich API that will save you a great deal of work. Module code can do virtually anything that PHP can do. The only thing that Modules cannot do (and which Tags can do) is act directly as Smarty modifiers.
Modules are extremely powerful and versatile, but that power comes with additional complexity. If you find that it would be possible to solve your problem with a Tag or User-Defined Tag, you should opt for the simpler approach. If, however, your requirements go beyond the capabilities of those extensions, there are very few limits to what you can accomplish with a Module!
I remember deciding to pursue my first IT certification, the CompTIA A+. I had signed…
Key takeaways The transformer architecture has proved to be revolutionary in outperforming the classical RNN…
Once we learn how to deploy an Ubuntu server, how to manage users, and how…
Key-takeaways: Clean code isn’t just a nice thing to have or a luxury in software projects; it's a necessity. If we…
While developing a web application, or setting dynamic pages and meta tags we need to deal with…
Software architecture is one of the most discussed topics in the software industry today, and…