Today I would like to discuss one of the new features our development team is currently working on: easy modifications while maintaining upward compatibility (meaning you can safely modify the application and safely apply our official SB Pro / Pagestead updates).
After our official launch in May, it quickly became apparent to us that a large group of customers is looking to, in one way or another, modify SB Pro / Pagestead to suit their needs and make it their own. We love this and actually encourage buyers to do this. It does, however, create a problem when it comes to official SB Pro / Pagestead updates. If you have modified a bunch of views for example, after which an auto update is applied which includes modifications to the same view files, then… ouch! Your modifications end up overwritten by our update.
The only decent solution we currently have to this problem is only available to our Enterprise customers; they are allowed direct access to our Github repo and with that access, they can clone the SB Pro / Pagestead repo and make their modifications inside that cloned repo. This allows those users to merge official updates from the main SB Pro / Pagestead repo into their cloned repo. Using this process, Git will deal with making sure your modifications remain intact while applying our official updates. Although this solution works, it’s not available to the majority of our users. Hence the search for a new, better solution!
The proposed solution
After lengthy discussions about possible solutions to the problem; we arrived at the following : a safe way to modify views would be a great place to start (since we believe a large chunk of modifications are done in the view files) and once we have the views covered, we’ll implement a way to safely hook into the controllers without having to modify them directly.
Dealing with views
The first phase will involve implementing a way to safely modify/extend existing views without having to modify the original view file. The way this will be implemented is as follows: the default view will be used unless there’s a modified version of that view present. The modified version of a view file will have the same name as the original view file, with an underscore (“_”) tagged on. For example, let’s assume you want to implement a customized version of the following view: /application/modules/sites/views/sites.php. You would create a copy of that file, in the same folder, with the name “_sites.php” (so the path to your new file would be /application/modules/sites/views/_sites.php). Now, SB Pro / Pagestead will automatically use the modified view file instead of the original one.
Dealing with controllers
The next step will be implementing a way to safely hook into controller functions. We will be implementing hooks, which allow for modifying a controller function’s behavior without having to modify the function itself. CodeIgniter comes with hook functionality built into it and by extending this functionality, we will be able to add hook points at crucial points inside controller functions. This will allow developers to manipulate data and flow without having to edit the controller functions. This functionality will resemble the WordPress plugin infrastructure; we will designate a folder in the application in which developers can add their plugins which will be automatically loaded into the application.
We are currently working on the first phase which we’ll release shortly (in the next update). The second phase will be significantly more work, so we’ll be looking at at least an additional month, possibly longer, for the second phase of this endeavor.
Other upcoming features
Next to the functionality described above, we have a few more things in the pipeline:
- A whole bunch of UI changes to the page builder
- Better image handling (resizing, cropping, etc)
- Cleaner source code for published pages
- And much more!