Migration from 1.12 to 1.13
This page describes the changes that nave to be applied to your software (until release 1.12) that it can be run with release 1.13.
1. Pager
The pager was enhanced by Daniel Seemeier as discussed in the forum thread Pager -> Weiterleitung auf die richtige Seite (German). The changes include:
- Switching to page based paging instead of start index based
- Refactoring of the HTML markup
- Refactoring of the existing classes to have more functionality
Migration to release 1.13 includes the following steps.
1.1. Switching to page based paging
Instead of the
Pager.ParameterStartName = "start"directive the configuration section now has to define the
Pager.ParameterPageName = "page"configuration key. The latter one defines the url parameter that contains the page number to display.
1.2. New HTML markup
In order to restore the pager's visualisation concerning release 1.12 the additional stylesheet /apps/modules/pager/pres/css/pager_2.css shipped with the 1.13 release must be included in the website the pager is operated in. Due to the new HTML sructure, the pager is much more flexible in adapting the layout via CSS.
1.3. Security
Along with the refactoring of the existing 1.12 components, the pager now has the configuration key
Pager.AllowDynamicEntriesPerPage = "true|false"defined. In case it is set to false the pager does not accept dynamic page size definition via url. By default, the value is set to false. This means that you have to set the directive to true manuylly to activate the feature as it was in 1.12. In case the feature is not activated, the template pager_2.html will not display the entries/page bar.
1.4. Statement configuration
To be able to handle statement files as "normal" configuration files the statement handling was changed to have it's own ConfigurationProvider during a bugfix. This enables you to save the statement files using the storage scheme of the new configuration feature.
Nevertheless, the changes applied to the source code are not transparent. It requires changes to the configuration of the pager. According to the configuration provider mapping, the extension of the statement (.sql) file must be passed explicitly. Thus, the values of the directives
- Pager.CountStatement
- Pager.EntriesStatement
must be changed upgrading to 1.13. To restore 1.12 behaviour, the values must be added the suffix .sql (=extension of the SQL configuration files the provider uses). Sample:
; before 1.13
Pager.StatementNamespace = "modules::comments"
Pager.CountStatement = "load_entries_count"
Pager.CountStatement.Params = "CategoryKey:standard"
Pager.EntriesStatement = "load_entry_ids"
; since 1.13
Pager.StatementNamespace = "modules::comments"
Pager.CountStatement = "load_entries_count.sql"
Pager.CountStatement.Params = "CategoryKey:standard"
Pager.EntriesStatement = "load_entry_ids.sql"2. Front controller
2.1. Configuration namespace
Including version 1.12 the front controller performed a re-mapping of the configuration namespace. The applied namespace was synthetically added the "::actions" sub-namespace. This behaviour has been removed to follow the default APF configuration file scheme that expects the file beeing located under the namespace and context path directly.
In order to migrate the existing configurations all folders names "actions" must be deleted and the content must be moved one level higher within the directory tree. Here's an example:
Before:/apps/config/{namespace}/actions/{context}/DEFAULT_actionconfig.ini/apps/config/{namespace}/{context}/DEFAULT_actionconfig.ini2.2. Output control
To easily allow unit testing or to be able to redirect the front controller's output for any other purpose the front controller now returns the generated HTML core calling the start() method rather than flushing it directly.
Thus, the
$fC->start('my::namespace','main');call must be changed to
echo $fC->start('my::namespace','main');3. Url rewriting
Since different applications are used to use "query" as a url parameter's name, the rewrite rule that enables the slash url layout was changed. The "query" parameter invoked by the rewrite input filters is now named "apf-rewrited-query".
For this reason, the existing rewrite rules must be adapted to
RewriteRule !(\.php|...)$ /index.php?apf-rewrited-query=%{REQUEST_URI}&%{QUERY_STRING} [NC,L]4. CacheManager
The CacheManager was added the functionality to handle more complex cache keys in 1.13. This means, the the getFromCache(), writeToCache(), and clearCache() methods now take implementations of CacheKey interface as cache addresses.
Cache manager calls like
$cache->getFromCache('my-key');must now be changed to
$cache->getFromCache(new SimpleCacheKey('my-key'));This is also true for writeToCache() and clearCache() calls. In case you intend to create more complex cache structures, the AdvancedCacheKey can be used. Details can ve taken from the CacheManager page.
5. Contact form
During refactoring tasks, the configuration files of the contact module were renamed. The recipients are now configured within a file called recipients.ini instead of empfaenger.ini. The content of the configuration is still the same.
6. Form validators
The DefaultSelectFieldValidator form validator was remove in 1.13 since the functionality is already included within the SimpleSelectControlValidator. Thus, all occurences within form definitions must be replaced.
7. GORM
Within a discussion about MySQL indices, we have found an inappropriate usage of the indiced of the relation tables. For this reason, the definition was changed from
CREATE TABLE IF NOT EXISTS `ass_group2user` (
`ASSID` int(5) UNSIGNED NOT NULL auto_increment,
`GroupID` int(5) UNSIGNED NOT NULL default '0',
`UserID` int(5) UNSIGNED NOT NULL default '0',
PRIMARY KEY (`ASSID`),
KEY `JOININDEX` (`GroupID`,`UserID`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8;to
CREATE TABLE IF NOT EXISTS `ass_group2user` (
`GroupID` int(5) UNSIGNED NOT NULL default '0',
`UserID` int(5) UNSIGNED NOT NULL default '0',
KEY `JOIN` (`GroupID`,`UserID`),
KEY `REVERSEJOIN` (`UserID`,`GroupID`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8;This ensures, that the optimizer uses indiced for both JOIN directions.
The setup and update tool have been adapted to this new structure, but existing tables must be updated manually using the following statements (example):
ALTER TABLE `ass_group2user` DROP `ASSID`;
ALTER TABLE `ass_group2user` DROP PRIMARY KEY;
ALTER TABLE `ass_group2user` ADD INDEX `JOIN` (`GroupID`, `UserID`);
ALTER TABLE `ass_group2user` ADD INDEX `REVERSEJOIN` (`UserID`, `GroupID`);ass_group2user, GroupID and UserID have to be replaced by the appropriate table name and the names of the object ids of the related objects.
8. ConnectionManager
The changes to the statement file loading described in chapter statement configuration affects all software components that make use of the executeStatement() and executeBindStatement() of the appropriate datenbase connection implementation. Calling one of these methods, the extension of the statement files must be explicitly applied. Example:
// before 1.13
$conn = $this->__getServiceObject('core::database', 'ConnectionManager')->getConnection('...');
$conn->executeStatement('my::app::namespace', 'load_entries', ...);
// since 1.13
$conn = $this->__getServiceObject('core::database', 'ConnectionManager')->getConnection('...');
$conn->executeStatement('my::app::namespace', 'load_entries.sql', ...);Comments
QUICKNAVI
JetBRAINS supports the development of the APF with PHPStorm licenses and we feel confidential that PHPStorm strongly influences the APF's quality. Use PHPStorm!
Proud to useIntelligent PHP IDE for coding, testing and debugging with pleasure