Don't repeat yourself
Pragmatic Programming
In this chapter, we will see how we can leverage the extensibility of the eZ Publish CMS to create an extension that can make our project reusable and easily portable to other installations of eZ Publish.
We will now learn how to create an extension for our project in which we'll put our new features, such as design, operators, translations, custom class definition packages, and everything else that we will build in the next chapters.
In eZ Publish, an extension is like a plugin through which you can add new functionality to the CMS without changing the standard software kernel. The eZ Publish extension system is very powerful, as it allows the CMS to be extended in different ways, such as adding new features, or changing the standard behavior of the system's basic functionality.
With this system, you can keep the CMS constantly upgraded to the latest version without the fear of losing your code. In fact, in most cases, the extension will continue to run and in the worst case, you should also upgrade the extension to make it compatible with the new version.
It's possible to create different kind of extensions, such as:
- Operator: This extends the standard template operators. (We will talk about them in detail in the next chapter.) For example, we can make new operator that can work with a string, or that can connect to external web services to perform some routine such as downloading content from an RSS feed.
- Design: This extends the standard design to customize content template with HTML and CSS, and make it easily reusable.
- Translation: It extends the standard XML translation files to add custom translations.
- Workflow event: This extends the standard workflow event, by adding a new one.
- Module: This extends the standard kernel modules by adding new custom modules with your own actions and views. In the custom module, it is always possible to use the powerful eZ Publish API to manage document objects and a document object tree. For example, we can make a statistic module, or a module that integrates with legacy external software with eZ Publish.
- Fetch function: This extends the standard fetch function by adding new functionality to implement custom queries in additional database tables.
- Datatype: This extends the standard datatypes with new datatypes to make the custom class more expressive.
- Login handler: This extends the standard authentication behaviors, by providing the ability to authenticate with external systems or legacy systems.
- Bin: This extends the standard shell scripts with new custom scripts.
- Cronjob: This extends the standard cronjob scripts with new scripts.
The extension folder needs to use a standard structure to be integrated in the CMS.
In the following table, we can see the complete structure that accommodates all types of extensions:
|
Extension subdirectories |
Description |
|---|---|
|
|
New actions for forms |
|
|
Definitions of new template operators or template functions |
|
|
Custom shell scripts |
|
|
Custom PHP classes for modules, template operators, template functions, and cronjobs |
|
|
Custom cronjobs scripts |
|
|
Definitions for new datatypes |
|
|
Files related to the design |
|
|
Custom workflow events |
|
|
One or more modules with views, template, and fetch functions. |
|
|
Custom class packages |
|
|
Configuration files |
|
|
Translation files |
The directory structure shown above is a complete structure, but the structure that we will use will depend on the type of extension that we need, so some directories will not be necessary. For example, a Template Operator extension only requires the directories autoloads/ and settings/ in a module extension. A module extension, instead, only requires the directories modules/ and settings/, and maybe the design/ directory.
For our project, we'll make an extension for extending the standard design, standard operators, standard translation files, and standard classes.