XF 2.0 Backwards compatibility breaks in XenForo 2.0.0 beta 3


XenForo developer
Staff member
I meant to post this a yesterday but didn't get a chance.

Rich text editor dialog changes
RTE dialogs are now built off the XF.EditorDialog class. You can see editor.js for some examples. Individual dialogs now need to be registered into XF.EditorHelpers.dialogs manually.

Captcha changes
  • User::isCaptchaRequired no longer checks the option value.
  • <xf:captcha> and <xf:captcharow> now check User::isCaptchaRequired unless the "force" attribute is true.
  • New Controller::isCaptchaValid method that checks User::isCaptchaRequired before checking Captcha::isValid. Can also "force" to bypass the user check.
  • Captcharow will no longer output an empty row if no captcha is required.
  • Controller::captcha no longer exists as you'll generally just use isCaptchaValid now. App::captcha can be used if needed.
XF\Error::logError no longer supports sprintf arguments
You should do this outside the method if needed. If now supports a second argument to force logging even if upgrades are pending.

Schema manager: alterTable, renameTable, createTable and dropTable always apply
You can no longer just get the query from these. The changes will always apply when the closure ends

setTarget and setUser removed from some post and thread services
In situations where setTarget was basically just setting the thread, this is now done in the constructor. In services where the user doing the action doesn't have any real relevance beyond controlling whether mod alerts are set, we no longer have a setUser method.

(Note that if you need to do something as a different user, you should generally use XF::asVisitor to change the visitor user.)

Order no longer passed to some ban related methods
In the Banning repository, findEmailBans, findIpBans and findDiscouragedIps now set default orders and do not pass in an order value explicitly.