XF 2.0 Backwards compatibility breaks in XenForo 2.0.0 beta 5


XenForo developer
Staff member
Entity value formatter system changes

There are a number of related changes here. Many of the aspects of validating and working with entity values have been split out into a new XF\Mvc\Entity\ValueFormatter object. This is exposed to the dependency injection container via em.valueFormatter. (This is not directly extendable at this time, but it could be overridden explicitly in config.php for extension.)
  • XF\Mvc\Entity\Manager's constructor has changed. The second argument is now the value formatter (moving extension to the third argument).
  • XF\Mvc\Entity\Manager::getEntitySourceValue has been renamed to encodeValueForSource (and just calls the same method in the value formatter).
  • XF\Mvc\Entity\Entity::_decodeColumnValue has been removed. Use the value formatter or \XF\Mvc\Entity\Manager::decodeValueFromSource.
  • XF\Mvc\Entity\Entity::_verifyValueConstraints has been removed. Use applyValueConstraints() in the value formatter instead.
  • While not explicitly removed, XF\Mvc\Entity\Entity::_castValueToType now passes all of its work onto the value formatter's castValueToType() method.
This refactoring was primarily to allow easier reuse with the importers (which in many cases do not directly use the full entity objects). However, this also uses object composition rather than including most of this functionality in a large base object so it should allow easier extension/adjustment over time.

App::getGlobalTemplateData now receives the controller reply object

This is a new argument (should you be defining your own app object). The reply object contains details about the results from the controller call. We will now expose some of these details to all templates in $xf.reply.

Note that this is also passed to templater_global_data now.