XF 2.0 Backwards compatibility breaks in XenForo 2.0.0 beta 8

[Mike]

BB code context changes

The BB code system now supports extended approaches for allowing the renderer to know what entity it's rendering content from in most cases. This has created a large number of changes, but should make for a lot more flexibility with rendering. These changes include:

1. XF\SubContainer\BbCode::render() has had its arguments changed. $content is now the 4th argument and $options is the 5th. The content argument must be specified, though it can be null. If you pass an array as the 4th argument and don't pass options, we will log this so you can update your code. This support will be removed in the future.
2. XF\Service\Message\Preparer::__construct() now defines an additional $messageEntity argument that should be passed whenever using it.
3. BB code rule set contexts can now be defined in "context:subcontext" format to allow more specific rendering and rules control. The contexts are now accessible via getters, so renderers can modify their behavior based on this if needed.
4. The bb_code() templater function has renamed the $user argument to $content to represent that, ideally, it should be a content entity. If there isn't one, a user can still be passed as before. This argument must be provided, but can be null if there is nothing that can be given.
5. Templates now rarely pass options into the bb_code() function. Instead, if the $content implements XF\BbCode\RenderableContentInterface, the getBbCodeRenderOptions() method will be called. You can look at XF\Entity\Post as an example. Note that this will likely have broken some template modifications, but they can now extend that method instead.
6. The XF\EditHistory\AbstractHandler::getHtmlFormattedContent() signature has changed, adding Entity $content = null to allow passing content into the BB code renderer. This is an abstract function, so all edit history handlers will need to be updated for this.

XF\Service\User\Avatar::setUser() is now protected

This method generally shouldn't have been called after the class was instantiated.

XF\Service\Conversation\Creator::isAutomated() has been renamed

This method is now setIsAutomated() to be more consistent with similar methods in other services.

This method has also been added to the conversation reply and message editor services, along with support for disabling validations on the message.

 

[DragonByte Tech]

The BB code system now supports extended approaches for allowing the renderer to know what entity it's rendering content from in most cases.

Does this not affect custom BBCodes? I am looking in the options, and I'm seeing this text:

This callback will receive these parameters: $tagChildren, $tagOption, $tag, array $options, \XF\BbCode\Renderer\AbstractRenderer $renderer.

Which doesn't appear to have changed.

If these changes do affect custom BBCode callbacks, can you please produce a quick example for how I would detect whether the BBCode is being rendered in a thread (or a post, whichever context it receives)?

Thanks!


Fillip

 

[Mike]

Look at what is passed in via the $options array. This is the same way the user was exposed before. Now you may get an entity as well.

 

[DragonByte Tech]

Look at what is passed in via the $options array. This is the same way the user was exposed before. Now you may get an entity as well.

Beautiful, I see it, thank you SO MUCH for this change


Fillip

 

[HQCoder]

XF\Service\Conversation\Creator::isAutomated() has been renamed
i like it