• This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn more.

XF 2.0 Backwards compatibility breaks in XenForo 2.0.0 beta 7

Mike

XenForo developer
Staff member
#1
$visibilityLimit / canViewModerated changes
The changes involved here are pretty extensive, though the ultimate effects on an individual add-on are likely to be small.

Generally, these changes are to support control over whether listing pages look for content that may be awaiting approval for individual users. The absolute vast majority of users won't have anything pending and this check is not good for performance. We will now only look for pending content for a user in this queries for a limited time after they have submitted content awaiting approval.

Any methods that received a $visibilityLimit parameter (generally in a repository) now receive an array in it's place to allow multiple limits to be applied without adding arguments. Out of the box, most cases know 2 options:
  • visibility - this is what the boolean $visibilityLimit used to represent
  • allowOwnPending - this controls whether we include content awaiting approval for this particular user (when they can't view all pending content)
If you've extended a method like this, you can likely just update your method definition and how you call the parent method.

This also means that canViewModeratedX methods in entities now always return booleans, rather than true/false/int.

Tracking when a user submits pending content
This isn't a BC break per set, but related to the above, if you change your custom content types to use the above approache, you will want to be calling XF\Session\Session::setHasContentPendingApproval() when a user submits content which needs moderator approval. To check for this (to pass into a method that uses it), you can call XF\Pub\Controller\AbstractController::hasContentPendingApproval().

XF\AddOn\CheckRequirementsInterface deprecation
This interface has been deprecated and will be removed for the stable release of XF2. Any Setup classes that implement this interface will error after it's removal. As of beta 7, its use will trigger a deprecation warning.

The interface is no longer needed. An empty method is now defined for XF\AddOn\AbstractSetup::checkRequirements.

XF\Tfa\AbstractProvider::generateInitialData signature change

In order to make implementing TFA providers that require additional configuration easier, the signature of this abstract method has changed. Any custom TFA implementation for XF2 will need to change the definition of their method.

It now receives a second argument, an array of config data that may come from the new requireConfig()/handleConfig() methods. These can be implemented to allow initial configuration to be handled before triggering the test/setup TFA request.