OXID eShop version 4.6.8

General hints for this package

  • Runs on PHP 5.2, 5.3 and 5.4
  • This patch is marked as end of lifetime of the 4.6 series. Originally, 4.6.7 was declared as EOL patch of this series, sorry for possible confusions. But it was a desire to fix #5568 and #5582 before the end of lifetime was reached, and at this occasion built in the SEPA validation (slight template changes for this reason exceptionally in this patch). For those who have already installed the SEPA hotfix offered before, can simply install this patch.

Installation

See http://www.oxid-esales.com/en/support-services/documentation-and-help/oxid-eshop/installation/oxid-eshop-update-installation.html

Templates

Some front end and admin templates were changed slightly due to the SEPA implementation and some bug fixes. Please also check the changes in language files, you’ll find detailed information about these changes in “templ_docu_admin/index.html” and “templ_docu_azure/index.html” of this package and a tutorial about the template hierarchy and the override system here
http://wiki.oxidforge.org/Tutorials/How_template_hierarchy_and_override_system_works

This system will help you saving a lot of time and work while updating your system.

Fixed Bugs

https://bugs.oxid-esales.com/changelog_page.php?version_id=249

New Features

  • SEPA validation is already built in, no additional hotfix needed.

Important information for developers

  • With the bug fix #5582, a former behaviour was changed so the error messaged leads to offline.html in case the database cannot be reached for some reason. This goes for OXID eShop in productive mode; in development mode, the regular error message will appear.
    The method _handleDbConnectionException was introduced for this reason and can be overloaded by a module if you’d like to implement a different behaviour. Please also see this comment in the bug entry:
    https://bugs.oxid-esales.com/view.php?id=5582#c9379
  • The fix for #5568 shall be seen as a security tweak: only public methods can be triggered from outside the shop framework, protected functions can’t any longer. This is an important information especially for module developers. This way, we streamline the restrictions for module writers and care that the shop cannot be attacked even if a module was coded an insecure way.