Different ways that Mods will break on 1.2

Rigel Kentaurus

Rigel Kentaurus

Well-known member
I can see it now.

XF 1.2 beta unleashed. Then, a smart guy goes by the thread of the Add-On X and asks
"Is this compatible with XenForo 1.2?"

One must resist the urge to respond in an snarky way "How would I know?" "XF 1.2 has only been out for 5 minutes, nobody has tested this".
The same keeps happening all over the place, with each mod. Everyone is lazy, "might as well ask", they think, "why test? Maybe somebody else tested it already".

..... I have been keeping my list of things that could make Mods break

  • Anything requiring the editor, or including the default editor. How will your mod behave with the save draft functionality? Is just including the template good enough? Is it even the same template? Do you need to apply extra attributes in the view? Who knows. At least not until inspecting the code
  • And what about that auto-upload if you don't have attachment support in your content, huh?
  • jQuery has been upgraded to 1.10, might as well check the upgrade guide if you have javascript (http://jqueryui.com/upgrade-guide/1.10/), did you use $.bind() ? you are out of luck. Time to start rewriting all of those to .on() since the method was deprecated on jQuery 1.7
  • You had template hooks? They are deprecated but still there, but might as well start writing them as xen:callback and TMS rewrites. The prepared developer could already start doing their TMS edits right now so they can just re-apply them in the new system
  • Thropies are quoted to have "speed improvements", for me that means "check that your custom thropies were not messed up"
  • Do you send email on your add-on? There is a new mail queue system. Better check that.
  • Do you have a content handler for reports? Better check that the new reporting system is handling your content type gracefully
  • Did you integrate into the stats? (I know I have summaries for entries posted in blogs and comments), will the summary by week and month work? Who knows. Will have to check.
  • Is the responsive design messing up your templates?

That a short to-do list for all the add-ons developers once XF 1.2 beta is available. Me ? I'm preparing my Zen and rehearsing this phrase: "I don't know if the add-on is compatible with 1.2 yet, please wait a little longer".
 
I'm hoping that i can resist the urge to upgrade right away to prevent these types of issues. But i'm sure that will be much easier said than done.. I'm already kind of chomping at the bit..
 
VonDoom said:
I'm hoping that i can resist the urge to upgrade right away to prevent these types of issues. But i'm sure that will be much easier said than done.. I'm already kind of chomping at the bit..
Click to expand...

I think if the 1.2 beta is given with enough time in advance, that will give the add-on authors the opportunity to test them and have them ready for the gold release. If that happens and the add-on developers live up for the challenge on the official 1.2 release day most of your add-ons most likely work.

Of course an ideal situation would be to even give a pre-release version to the top add-on developers (XenPorta, BD Widget, etc), so they can test their add-ons even before 1.2 beta is made available, but I have the feeling that might be asking for too much.

To complicate things further, the responsive layout will probably generate as much trouble for the designers as the code changes generate work for the add-on developers.
 
cclaerhout said:
jQuery bind will still work, the template listeners too, so these two points shouldn't be a problem.
Click to expand...

That was just an example on top of my head. The point is that all JS needs to be checked, since a lower dependency (jQuery) changed, and jQuery is not hot about backward compatibility. Depending on the add-on this could be trivial or a lot of work.
 
Rigel Kentaurus said:
That was just an example on top of my head. The point is that all JS needs to be checked, since a lower dependency (jQuery) changed, and jQuery is not hot about backward compatibility. Depending on the add-on this could be trivial or a lot of work.
Click to expand...

The main points to check with jQuery will probably be the "data"/"attr"/"prop" commands and the lost of the browser detection. The major task has already been done by XenForo developers by upgrading their framework and jQueryTools to the last versions of jQuery.
 
Note that we're using the same RM here without any changes.

We still use the jQuery migrate plugin, so that makes that part easier, but if you used custom data attributes and relied on standard-breaking camelCase for them, you'll need to change the code. Similarly, plenty of attr vs prop changes. So yes, custom JS will need to be combed through.

If you use the standard editor stuff, you'll be fine, you just might not get things like draft saving as you need to explicitly write code to handle that. The upload stuff in it depends on the uploading options in the form so it just shouldn't appear -- you can double check in conversations here though.

Mail queuing is entirely in the background - there was a function around to "queue" the mail in the past; it just sent it immediately though. If you use that, you'll silently be using the queue now.

I don't think there are any report handler changes. When there are handler changes, they're not new abstract functions so they should fallback gracefully.
 
You must log in or register to reply here.
Back
Top Bottom