Before we even start building our theme or the custom functionality it contains, let’s create that package I mentioned earlier.

The concrete5 package format is a way to bundle most aspects of concrete5 functionality together, so that they can be easily distributed, installed and uninstalled. The package format is used by the concrete5 marketplace, but can also be used without connecting to

This isn’t strictly necessary -- concrete5 lets you group custom functionality in the application/ directory without forking the core -- but it’s a process we like to follow. It forces us to keep code clean up and well separated, and the built-in version number and upgrading of packages makes it so that we can add functionality over time more easily than we might if things were just in the application/ directory.

Packages consist of an outer directory, an optional icon image (icon.png), a controller.php file immediately within the directory, and then a files and folders that map to concrete5 components. The controller.php specifies the version of the package, defines an installation and uninstallation routine, and specifies any custom code that should be added to the concrete5 startup routine when that package is installed. In general, the filesystem of a particular package's contents will match the filesystem of those contents in the concrete/ directory, if they were to be installed by the core.

Was this information useful?
Thank you for your feedback.

Could this page use improvement? Edit it!

Edit Page