Developing for Fork CMS 3.5
- Written by Dieter Wyns on Tuesday 19 March 2013
- 3 comments
Like you could read in a previous article on our blog the 3.5 release of Fork CMS has the first components of Symfony: HTTPKernel, HTTPFoundation and Dependency Injection. Switching to Symfony brings a lot of new functionality but also means that some things have changed while developing a module.
Changes
- PHP Version 5.3
With the switch to Symfony comes new minimum requirements too, one of the new requirements is php 5.3. So you can safely use all PHP 5.3 functionalities now in your modules. A complete overview of the changes can be found on php.net. E.g.: It's now possible to use namespaces.
- Accessing the database
While testing an 3.4.* (or older) module on a 3.5 setup, the chances are that you encounter an error which looks like this:
Fatal error: Call to undefined method BackendModel::getDB() in /path/to/script.php on line 666
It occurs because of the new container that has to be called before getting the database. It is simply resolved by replacing the methods:
BackendModel::getDB() -> BackendModel::getContainer()->get('database');
FrontendModel::getDB() -> FrontendModel::getContainer()->get('database');
As an example, in the banners module:
/backend/modules/banners/engine/model.php line 332:
// get empty standards?
if($getEmpty) return (array) BackendModel::getDB()->getPairs(
'SELECT i.id, CONCAT(i.name, " - ", i.width, "x", i.height)
FROM banners_standards AS i'
);
becomes
// get empty standards?
if($getEmpty) return (array) BackendModel::getContainer()->get('database')->getPairs(
'SELECT i.id, CONCAT(i.name, " - ", i.width, "x", i.height)
FROM banners_standards AS i'
);
And
$db = BackendModel::getDB(true);
becomes
$db = BackendModel::getContainer()->get('database');
You have to do this everywhere you use the database, but if your module is well written this will only affect your models:
- /backend/modules/yourmodule/engine/model.php
- /frontend/modules/yourmodule/engine/model.php
- Globals
For future support we suggest to stop using the globals like before 3.5. The globals that are not related to an application are moved to a yaml file and require a new approach, the config parameters need to be get from the container.
Before | After |
SPOON_DEBUG | FrontendModel::getContainer()->getParameter('fork.debug') |
SPOON_DEBUG_EMAIL | FrontendModel::getContainer()->getParameter('fork.debug_email') |
SPOON_DEBUG_MESSAGE | FrontendModel::getContainer()->getParameter('fork.debug_message') |
SPOON_CHARSET | FrontendModel::getContainer()->getParameter('fork.charset') |
PATH_WWW | FrontendModel::getContainer()->getParameter('site.path_www') |
PATH_LIBRARY | FrontendModel::getContainer()->getParameter('site.path_library') |
SITE_DEFAULT_LANGUAGE | FrontendModel::getContainer()->getParameter('site.default_language') |
SITE_DEFAULT_TITLE | FrontendModel::getContainer()->getParameter('site.default_title') |
SITE_MULTILANGUAGE | FrontendModel::getContainer()->getParameter('site.multilanguage') |
SITE_DOMAIN | FrontendModel::getContainer()->getParameter('site.domain') |
SITE_PROTOCOL | FrontendModel::getContainer()->getParameter('site.protocol') |
SITE_URL | |
FORK_VERSION | FrontendModel::getContainer()->getParameter('fork.version') |
ACTION_GROUP_TAG | FrontendModel::getContainer()->getParameter('action.group_tag') |
ACTION_RIGHTS_LEVEL | FrontendModel::getContainer()->getParameter('action.rights_level') |
You'll have to replace FrontendModel by BackendModel when working the backend.
The globals are a work in progress, so there is legacy code in app/appKernel.php that still defines the globals. If you are experiencing difficulties, just keep using the globals for now.
- getUTCTimestamp()
If you use a custom function for getting a timestamp in your frontend, it is recommend to replace it by the new getUTCTimestamp() method. It's available in the FrontendModel and works just like the one in the backend.
- Every application through the front controller
Like the comment in the new .htaccess file states, all requests will be handled by the front controller. This won't affect your regular workflow, but will only be visible if an error occurs.
E.g.: If during the install the .htaccess file doesn't load like it should, the browser will redirect you to /install where no index.php file is present. See a related forum topic.
Further reading
The documentation of each specific Symfony component is a very interesting read:
Questions
Please use our forum if you have any questions, this article will be updated with the most frequently asked questions about upgrading a module for Fork CMS 3.5.
Frederik wrote 11 years ago
SITE_URL will become FrontendModel->getContainer()->getParameter('site.url') I suppose?