This is a quick overview of some new things that are introduced in XOOPS 2.5.9 that Theme Creators should know about.
Form RendererIn XOOPS 2.5.9 we have added a XoopsFormRenderer class, and a XoopsFormRendererInterface interface. The XoopsFormRendererInterface defines the final stage of form rendering, allowing the elements to be tailored to better adapt to the theme. XOOPS 2.5.9 ships with two implementations, XoopsFormRendererLegacy which matches the traditional XOOPS form rendering, and XoopsFormRendererBootstrap3 which uses Bootstrap classes to declare the form elements.
By default, XOOPS 2.5.9 will use the Legacy renderer. A theme can choose to use the Bootstrap3 renderer by including a file named theme_autorun.php in its top directory, as is done in the xbootstrap theme, containing the following:
xoops_load('XoopsFormRendererBootstrap3');
XoopsFormRenderer::getInstance()->set(new XoopsFormRendererBootstrap3());
New Smarty variables added in XOOPS 2.5.9
$xoops_page contains a condensed version of the current page name. For example, for
http://myurl/index.php, $xoops_page would be "index". For
http://myurl/modules/profile/edituser.php, $xoops_page would be "profile/edituser".
$xoops_startpage contains the module configured as the start page, or "system" if no module is selected.
A "rendered" key is now set by XoopForm assign() methodSome scripts use the assign() method as an alternative to the display() method. This method assigns the form details to a stem variable named with the form's name. This assignment is done with code that looks like this:
$form->assign($GLOBALS['xoopsTpl']);
This technique has often been done to give the theme more control over the display of the form. It requires the template to loop through the individual form elements, and decide how to display it. This level of control is good if you need it, but can be a nuisance if you just want to position the form inside the page, and you would prefer the system to handle the details.
As of XOOPS 2.5.9, when the program uses the $form->assign() method, an additional stem variable, 'rendered', will be available. Instead of iterating over the 'elements' portion to build the form from pieces, you can simply display 'rendered' to use the system provided rendering:
<{$form_item.rendered}>
Compatibility BreaksChanges needed to existing profile module override templatesIn the profile module, the profile_userinfo.tpl template creates an entire form to provide an activate/deactivate user button. Unfortunately, this form should have a security token. You can see an example of this in the XOOPS 2.5.9 htdocs/modules/profile/templates/profile_userinfo.tpl file at line 54:
<{securityToken}>
Without this change, the button will not work in XOOPS 2.5.9. We try to avoid this kind of compatibility break, but in this case it is necessary.