$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:
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\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\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.
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 representallowOwnPending- this controls whether we include content awaiting approval for this particular user (when they can't view all pending content)
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.
