I could have toned this down, but I really hate code residing in the Concrete CMS /application/ directory. When I work on a Concrete CMS site, I implement everything in packages, including the theme and any application specific block templates.
Application
- Theme and application are all mixed up.
- Management is at the level of individual files, not combinations of files that work together.
- It can't be easily separated into functional components which can be installed and worked on independently.
- /application/ code is usually sprawling and disorganized.
- The only practical configuration management is by individual file, but that is complicated by many files which do not need to be managed.
- The /application/ directory is also the home of file manager files and the cache.
Packages
- The theme and each area of functionality can have their own packages. Development of functionality can be decoupled from the theme.
- Packages can be version managed (in addition to any configuration management of individual files within packages).
- Packages can be tested, distributed, installed, updated and removed as self consistent entities.
- Packages can be delivered to sites and customers as discrete entities.
- Packages are convenient units to distribute work between developers.
- Packages facilitate further reuse.
- Packages can't be accidentally mixed up with file manager files or cache files.
When code absolutely has to be placed in /application/ because that is the only place it can work, then I make it no more than a minimal wrapper for calling back to the actual code in a package. Don't let an exception to the rule become the thin end of the wedge.
This enables developers to easily move code between staging, production and each developer's development sites and avoid discontinuities between them.
If you like to work with Git, a Package is a natural item to manage as a Git project. With everything in packages, then for most web site projects any global Git across the whole project is unnecessary.
Keep theme and application code separate
A theme should be a generic package for a design. Application specific code should be in one or more other packages. If a theme developer is creating some simple generic blocks, they can go in the theme or in a block specific package. As soon as a block begins to provide application specific functionality, it is better in an application specific package.
When in trouble, swapping a site theme or marketplace theme for Atomik, or applying the site theme to a set of standard content, enables half of the problem to be quickly eliminated.
Use standard theme area and template names
Conforming to the standard names for areas and templates is a prerequisite for the above. Without standard names, swapping a theme will lead to zombie content.
For site owners
If a developer knows what they are doing, packages are a benefit to them and to you. If a developer doesn't know how to work in packages, should they really be working for you?
Topics and Tags
Discussion
If you would like to discuss any of these thoughts, please start or continue a thread on the Concrete CMS Forums.