Not all content management systems are the same; each was developed with a different goal and mindset in place by the original developer or agency.
Developed with a Purpose
Core Plus was developed to provide a stable, secure, and fast PHP platform for building web applications. This goes beyond most CMS platforms that are only created to manage content, in that Core supports custom applications to be built.
Dedicated Object Types and Business Logic
In Wordpress for example, virtually everything is a
post with corresponding
post_meta. If a site has WooCommerce installed, each product is a post. A page, a post. Navigation menu... a post. Calendar events, yup, just another post.
While this may make initial development simple as
wp_post can be used to return virtually any information on the site, it makes management and further development of the site rather difficult as any custom business logic must be patched in after-the-fact, slowing down the site and causing an overall worse user experience.
If a developer needs to migrate site content for new page content from a staging or development environment on an ecommerce site running Wordpress, it's not just a simple process of grabbing the content and content pages in a database export because that will include orders and order information, which certainly should not be overwritten in a production environment!
With Core, each "type" of information on the site is contained in its own dedicated space. Orders have their own database table with their own business logic. Calendar events have their own database table with their own business logic. Etc.
Separation of Functionality
For highly maintainable sites and applications, a separation of functionality between database logic, business logic, and template logic must be preserved. In Wordpress, a single file will serve as data lookup, business logic and permission checking, and output rendering. This makes changes and management difficult and costly, as a simple template change could break site data!
With Core, each distinct type of application functionality is contained in different parts of the component. Data lookups and data management is stored in a Model file, business logic and permission checks are contained in a Controller file, and templating logic is contained in a View file.
This separation allows developers to manage only the specific portion of the application they need to manage, allowing for faster development, less bugs, and a lower total cost of ownership.
Separation of Assets
Different storage mechanisms serve different roles in an application or site. The database is used to store data, filesystem used for storing files.
One popular feature of the CMS platform Drupal is the ability to edit template code from the administration editor. While this can be a useful feature, these changes are saved to the site database. Since templates can contain PHP code, this can make troubleshooting site issues very difficult and costly, as the code cannot simply be searched for.
With Core, templates can also be edited from the site administration, but these changes (being files), are stored on the site filesystem to make them easily searchable by developers AND exportable by simply copy/pasting the raw file.
If developers prefer, these modified files can even be managed by an IDE or simple text editor, simply by editing the template. Changes and revision control can even be supported by implementing
git or another versioning system inside the directory containing these modifications!
Developers and designers changing site templates is an important aspect for a business CMS, and with Core is easily managed. Since every template modification is stored in a separate location away from the source component, updates to that component can safely be performed without any concern of customizations being overwritten.
Migrations between environments is also simplified, as in order to install a custom template in a specific environment, all that is required to be done is to copy the file. This allows for easy backup and archiving of customizations for client sites, simply by zipping a copy of those changes.
Even site CSS changes are stored along with custom templates as a flat CSS file, easily editable by any file editor. (One note though, CSS files are copied and minified upon changing, so if you manually edit the custom CSS, please be sure to minify your changes manually too.
themes/custom/assets/css/custom.css is minified to
themes/custom/assets/css/custom.min.css for example.)