TAG | gjPositionsPlugin
I work for a publishing company so I am concentrated on editor work flows a lot. With this in mind I implemented the gjPositionsPlugin. Using it you can easily compose a homepage from multiple design elements.
This is often used to display lists of articles, dossiers and other contents. But sometimes you want to override the headline or title of an article when it appears on a homepage. This makes sense for SEO reasons as this article then becomes much more interesting for Google.
This is now a build in feature!
Next year I will be starting on a new project which could be awesome. The plan is to roll it out in several countries and languages and to keep it skinnable to some extend. The site itself will be editorial for the best part but with the participation of its community.
I’m not going to tell more about the project itself but I present the current technology setup I am thinking about which will very likely be reflected in next years posts. Maybe you can add some experiences and thoughts?
The aim of this plugin is to give the user (i.e. admin or editor) full control about the structure of any type of aggregational page like a homepage, indexpage, categorypage or an element like a sidebar.
One of the many things I really like about doctrine is the data type Array. On the database level it is a serialized string representation of a plain PHP array while on the record level it is PHP array.
You can use it to store more complex data with a changing structure per record. But how do you maintain this in a symfony form?
Sometimes you might be tired to use the same behaviour on all your models with all the same options littering your schema.yml.
This is where I started and this is what I found.
End of last week and this Monday I finally had a chance to do what I planned for quite some time now. I refactored parts of gjPositionsPlugin.
The result of this is the second beta version with the following changes.
When my team laid their hands on the plugin they almost instantly found some nicely hidden bugs so I had to get busy again which proved a quite intense experience.
In the end result the plugin also gained an option to dramatically reduce the number of queries in the admin modules of your composition-able models.
When presenting it to the team I realised that I have to clarify the question of usage.
Often when you have a new toy in your hand you want to use it for everything just because you can but this is rarely wise.
So when should you use it and when shouldn’t you?
Today I am happy to announce that this plugin is now available in its first beta version!
Not only I managed to implement the basic idea of composing design and content elements on a canvas; by now the plugin became completely independent from your models and database structure!