Already read this, click here for part two.
Laravel is bloody great! I think most people who have ever had the pleasure to use it for a project have realised that. There's just one big sticking point that means it's just not suitable for a lot of small and medium-scale projects: it's a clean slate framework. Enter October CMS, a Laravel-based CMS platform. At its most basic, it's a reshuffle of Laravel with a lovely CMS section added which allows you some control over some settings, a media manager, user management tools and a 'CMS' section to give you some control over your views.
Getting Started
Well there are several more differences beyond that. Immediately, the folks at October CMS ask you to use its installer rather than cloning from the git repo. Installing is a quick and painless process that takes a couple of minutes and, once done, you're offered the option of a clean install or of starting with some standard themes and plugins activated. Immediately you're beginning to feel like you're in more a Wordpress than a Laravel world.
And therein lies the most profound difference; you can be up and running with a fully working site with October CMS in the same amount as it might take you to write your first migration in Laravel. This is big news for anyone who has ever had to ignore their better judgement and head to wordpress.org because the time you have to set up a site is pretty negligible. With a theme and a handful of plugins (a blog, static pages, users) you've basically got Wordpress functionality from the off. There's even a shop plugin.
With Laravel, it's always tempting to fall into the classic developer trope of wasting time doing it yourself. That temptation is immediately gone with October.
Directory Enquiries
Immediately you'll probably notice that, unlike Laravel, there's no separation between the public assets and the general application structure. All files are in the public directory structure. This is an issue the guys at October have justified the decision from a security and assets perspective. When you realise the reliance October CMS has on plugins, it makes sense. And that separation of production assets and development assets in Laravel caused occasional issues for me from a resource management perspective.
Despite that fairly significant difference, the directory structure is fairly similar to Laravel 5; there's bootstrap/, config/, storage/, vendor/ and some new additions in modules/, themes/, plugins/ which reveal a little about how they've built the rest of the application. Missing, though, are app/, database/ and resources/ files...
Plugin Baby
October is built on the powerful Eloquent, but where do you put your application models? There's no Laravel 4 models/ directory, no Laravel 5 app/ directory...
For anyone that's familiar with Jeffrey Way's generators, you'll be familiar with the following command to get yourself a migration and a model:
php artisan make:migration:schema create_users_table --schema="name:string"
That command will build a migration to create the table as well as place an empty User model in your app/ directory. October has a similar command:
php artisan create:model pluginCode modelName
It takes two arguments, pluginCode and modelName. I'm sure most can deduce what the modelName needs to be, but the pluginCode? Before you can add any models you need to have a plugin to add the models to. You can do so with the following command:
php artisan create:plugin RainBlog.Blog
Without getting into too much detail (SitePoint has a good article on building a basic plugin) you'll get a Plugin.php file - mostly for definitions and permissions - and an updates/ which will only contain a yaml file at the moment but that directory is where any database updates will be kept, with the yaml file being used to what database changes need to be run between versions, including data seeders.
Calling the create:model command will add a few new files to your newly-created plugin's code. A models/ directory containing a familiar Eloquent model class and some more yaml files - which are used for defining the attributes of your model for the CMS - and a create table migration in the updates/ directory.
A quick peek in the Model reveals it's not exactly the same, mind. Your model relationships were defined before with:
public function type(){
return $this->belongsTo('App\ProjectType');
}
Whereas now you define them with some public arrays:
public $belongsTo = [ 'type' => ['Archybold\Projects\Models\ProjectType'],
];
More details on that syntax can be found in the documentation.
But Why?
Looking beyond the different relationships syntax, at this point you might be questioning why would the October chaps force you to build on the their application with plugins. And the answer is simple, they want to nurture a community of developers who think in a modular way. And not because they want you to build better applications, but because they'll only succeed if they have creators on board, who are building more and more plugins for the rest of the community.
The best way to change how people think or act is to make it easier for them to think or act in the way you want them to. Which is a bit manipulative-sounding but think of the music industry; people are now paying for music (discussions aside about how much they're paying) through streaming platforms where before they were downloading music. And why? Because the streaming platforms realised that people would pay for music if it was genuinely easier to listen that way. And why did everyone move to downloading in the first place? Because it was easier than buying a CD.
These tools make it easier to create migrations and models in the way that Jeffrey Way's generators did. But they also force you to stick to their methodology of building plugins. The alternative is to pick apart the directory structure perhaps, or maybe write your own autoloader but that's far more difficult.
And with that, they immediately force you to start thinking of building your application in a modular way. I've already extended this site with a couple of modules. One of which is a simple contact form that's probably not to everyone's needs. But for the first time, I've found myself giving back to the community. And I'll probably find ways to improve and reuse that plugin going forward. This is where I think the guys at October CMS deserve a lot of credit.
The only issue I can see with this is that it might not be ideal for larger scale applications, where plugins could get bloated as it will get more difficult to separate certain applications into smaller chunks.
So It's Pretty Good, Yeah?
Yes, it's pretty good! But this is the tip of the iceberg; I've not yet managed to cover themes and the view-based stuff, such as templating and components for your plugins.
It feels like these guys are banging on the door of Wordpress and, finally, there could be a CMS out there to knock them off their mantle. It's easy to setup but exciting for developers to work with. I know they've convinced me!
Finished up and got more left in you? Click here for part two.
Discuss This
blog comments powered by Disqus