Please note that this article was not written by me. Back when it was published this blog had a co-author called Watson. You can find his blog here.
Why to wait for October when Prototyping your next PHP-Application? Right, it doesn’t make sense at all and you shouldn’t. Instead using the October CMS right now however could blow your mind - or drive you crazy.
In this article we will take a quick dive into the OctoberCMS. Even if it calls itself a CMS it feels more like a PHP application platform underlying to your application. This is a fact that we are going to understand and also where the differences between these two terminologies are.
We will also have a look at the single features that make app-prototyping a charm and where the pitfalls are.
October is still not released yet but has reached it’s first release-candidate. So you might still experiencing some bugs as I did while testing and working on my first project with October. I wasn’t approaching any deal-breaking bugs, just to reassure you.
What’s special about October?
Content-Management applies insofar as it features a Content-Management-Functionality right backed in. The term “More like a application platform” comes from the fact, that October is based on the PHP-Framework Laravel. Thus it is highly extensible and comes with many proofed concepts and components like Extensibility, MVC, Events, Security, Authentication, Database-Management and much more. With features as Laravel Routing and the Twig Template Engine October also keeps the frontend in mind.
With all those core-features and a powerful plugin interface (which also supports inheritance) it feels more like using a rich-client-platform to me then using a simple CMS.
Get back to basics
With the maxim “Get back to Basics” in mind, the creators of October build a System mainly oriented on developers although it also has easy access for designers and creators through plugins. Within this article we focus on the developer-view of things and discuss the opportunities in application prototyping.
You might notice if you have experience with the Laravel-Framework, that October in many cases is just taking over core principles of it’s underlying Framework - with some modification.
OctoberCMS | Models on the runway
October implements the current standards of object-oriented PHP and uses a modified version of the Model-View-Control pattern. The October-Plattform organizes it’s database data in models which are organized by controllers. The functionality and front-end access to those models is managed by so-called components.
Models are described with YAML configuration files and implemented in PHP classes. Those YAML files are parsed by the controllers which bring up backend views for insertion, updates and removal. Components are then used to wrap the functionality and data of the models within twig code and make it accessible in the front-end.
Those concepts make a faster prototyping possible through design. As we will realize soon October has more features to further improve development speed. This is where the Builder-Plugin jumps right in.
Going nuts about Prototyping
The so-called builder plugin by the developers of October features a backend drag-and-drop interface for creating database tables, model-classes with their YAML configuration, menu-entries, controllers, permission-levels, versioning and localization.
The “only thing” that’s left to-do after the setup of the above components of a plugin is
- Assure validation
- Implementing Relationships between models
- Implementing functionality
- Inheritance and Extension
- Customization of CSS-Styles
All these annoying steps in application development, the bootstrap, are handled by the builder plugin.
With the CSS-Bootstrap Framework the developer has a simple way of giving the components and features of the plugin a basic look and feel. Because the functionality is passed to the front-end development through components this is handy way of giving your data and logic more significance.
As of the time writing this post there are several bugs in this plugin which are noticeable to a certain degree. No real deal-breakers though. E.g. the DELETE-Button of Controllers is missing, so you have to delete them with the editor.
My experience with October
Currently I’m working on a port of an open-source Event-Management Software written in older PHP without those shiny new insights of computer science and software engineering.
The core problem was a missing open Community and straight access to the code and development through e.g. GitHub and a missing documentation.
My first impression after 24 hours of using October was “wow - it simply handles about 70% of the old code by design.”. Things like database access, extension and view are simply accessible through a higher abstraction coming with the framework. The “only” thing to do, was implementing logic. In other words: the interesting stuff.
Downside of this comfort functionality could be the performance, but this has still to be tested when the system is running and comparable. Also working with a Team in this environment has to be tested.
Another drawback some could argue is the need of learning many of the software development patterns and paradigms. Although they assure performance and stable plugin development.
The documentation is quite awesome and seems really complete by now. There was nothing until now which couldn’t be resolved by utilizing the documentation. On the plugins repository there is a documentation section on each plugin page. So it is easy to understand the functionality of each plugin - if this is maintained properly.
The only thing I missed in the docs of plugins was a separation between docs for front-end integration and development. Issue still pending.
October is based on the PHP-Framework Laravel and should not easily be called a CMS but rather a PHP Application Platform. It comes packed with many features and a high level of abstraction.
In fact the well-conceived use of patterns and paradigms speed up the development process although this is a matter of taste. Not anyone may be happy in October.
Sometimes it feels way more complicated as it should to solve a problem. E.g. the querying of data through the model class can be easily achieved with plain SQL-Queries, which feels more powerful and a bit simpler. Abstraction can simplify things but also strip functionality so solutions can become more complicated.
Nevertheless in my experience application development got boosted in speed and reliability. Most of all when it comes to backend access, testing and business logic. The high level of abstraction simplifies many things and helps understanding and implementing more complicated concepts.