Fixed [1.2-beta1] Colliding XML parents tags with TMS

[HWS]

XF 1.2 uses the same XML parents tags as TMS uses but with a different syntax.

This does not allow to create add-ons which can be installed at 1.1 with TMS and also at 1.2 with integrated template system. This is very inconvenient and can easily be solved with a simple change of the XML parents tag used by 1.2 integrated template system, before too many add-ons are released for 1.2.

 

[Jeremy]

This shouldn't be considered a bug. XenForo develops with naming conventions for what it needs and requires. Add-on developers should utilize some sort of standardization (prefixing) to avoid conflicts as such, but it shouldn't be up to the XenForo developers to work around add-ons.

 

[Paul B]

Indeed.

I would of course also use this time to note that add-on devs may want to make sure that they use a unique prefix for tables, options, templates, etc to ensure they don't conflict with potential changes in the future. This is especially important when you're extending core features (forums, threads, posts, templates, etc) rather than entirely new systems (galleries, etc) though it's probably a good idea there.

It is up to third party add-on developers to work around XenForo, not the other way around.

 

[HWS]

There are hundreds of XML files out there using the syntax of TMS already. Even if guitar changes his parent tag (which I am sure, he will) all of them will be broken! This will lead to massive support requests and errors for several months, if not years. Almost all XF 1.1 users have TMS installed.

It would be MUCH easier if XF changes the tag BEFORE to many XML files using its new syntax are out there. @Mike please rethink this decision.

It is also a polite and not unusual action by developers to not reuse tags already used by other developers.

 

[CyberAP]

Almost all XF 1.1 users have TMS installed.

Bzzzzng...Wrong!

 

[Andy.N]

I will uninstall TMS and make my template edits other ways.
Problem solved.

 

[Jeremy]

Never had TMS installed and never used it in an add-on. TMS already plugs into the the add-on install. A craft developer will be able to support both formats. No software should work around a 3rd party plugin.

 

[HWS]

Never had TMS installed and never used it in an add-on. TMS already plugs into the the add-on install. A craft developer will be able to support both formats. No software should work around a 3rd party plugin.

While this is true generally, I think this is a case worth an exception.

Simply because there are really many XML files with TMS syntax out there. And, most important, because of the huge amount of time and ressources potentially saved for the support team of XF and most add-on creators.

And -no offense @King Kovifor - if you never used TMS neither in your forum nor in your add-ons you don't know how important this small change would be.

 

[Jeremy]

You make the exception now you have to make the exception later. The opinion still stands, XF shouldn't change because of an addon.

 

[cclaerhout]

There have only been almost 2000 downloads of that addon. That's all.

Let's add that Guiltar was there when XenForo had problems and when many have left. He created, alone & for free, a tool that became a reference and certainly has drained some traffic here.
Let's also add this addon has been used for more than 1 year here, so I really don't see how a developer could be retroactively blamed for a syntax that didn't exist before and why users should suffer of such a decision.

I was really happy to learn than XenForo developers had the idea to create a template modification system "before" TMS existed, even if I still don't see why it was more important to mention this than to have the courtesy to mention the name of the addon developer instead of only the name of his addon. Of course many will tell me it's a detail, sorry but I don't think so. May be a cultural difference then, who knows.

When a potential customer arrives here and asks for a discount if he translates XenForo, he's been replied that the product is a bargain (which is true), that the community is really dynamic and contributes a lot. You can't smile at customers saying "oh look at our community of developers how dynamic it is" and act like this. It's rude and, even more serious, it is technically a problem to maintain the addon compatibility between XenForo addon versions. And why is this technically a problem? Only for a xml syntax! Come on, why was it so important to use exactly the same syntax?

Now I've almost no illusion that this thread will change anything, but there's a problem here.

 

[Jeremy]

So far, there have been 2 add-ons that have conflicted directly with XenForo: TMS and [bd] Forum Watch. Both could have been avoided by using a proper prefix in anything they add. Its really just common sense to prefix items (tables or xml).

 

[Chris D]

Cedric,

You seem to be implying that Mike deliberately set out to clash with a highly respected add-on. Have you not considered that perhaps @Mike just built the feature he wanted to build with the syntax and other naming conventions that is most consistent with the rest of the software?

It probably didn't occur to him that he should pull someone else's code apart before he built an important feature for his software.

Why should it?

Calling it a bug is far fetched. This is a suggestion, at best, and ultimately that the add-on developer should resolve. If there's still a place for TMS within XenForo then I'm certain @guiltar would be more than happy to adapt to the core software. That's what skilled add-on developers do.

 

[James]

If these addons are using the same parent line but different syntax, couldn't the TMS addon just check the file on import for its own syntax and then alter the opening line before importing the XML?

I've never used TMS so I'm not sure if what I'm suggesting is even feasible.

 

[HWS]

We all know that it is no problem to provide 2 xml files for 1.1 with old TMS and 1.2 with TMC (and, maybe, updated TMS). It also is no problem to update TMS to use another parent tag.

But doing so will BREAK many add-ons which maybe will never be updated for 1.2, but can be used perfectly for 1.1. And it will create confusion and a high amount of support cases for sure.

What WE should have in mind at first place is the customer using XF. The most compatible and useful solution should be done to make it as easy as possible for the customer (who mostly doesn't know anything about XML) to use his Xenforo software. Even if a "general rule" will be broken.

 

[cclaerhout]

I personally don't care the causes, I see the effects. Some basic communication would have avoided this. But may be there have been; after all that "what skilled developers do", isn't it? In that case I will of course take back what I've said and will apologize.

 

[James]

I personally don't care the causes, I see the effects. Some basic communication would have avoided this. But may be there have been; after all that "what skilled developers do", isn't it? In that case I will of course take back what I've said and will apologize.

Aren't there other people arguing that if guiltar had properly prefixed his addon this could've been avoided also?

It seems the blame can be passed between the devs and guiltar, but at the end of the day it was stated back in 2010 that all addons should use their own prefix.

 

[HWS]

You cannot change anything that happened back in 2010. But you can change a simple thing now to help endless of customers, support people and add-on developers to make all their life easier.

To find out who has caused this is simply not important.

 

[Pereira]

I've never had TMS installed either. I don't see why the XenForo devs should have to download and go through add-ons to see if they conflict with what they are doing. It should be the other way around.

Add-on devs should be doing everything to anticipate conflicts, not the XenForo devs.

 

[Mike]

I am making this change as a one-off simply because TMS applies to many other add-ons. If it just caused the problem with one add-on, the situation may be different. In general, I don't look at the technical implementation of any add-ons (similar features or not) so I couldn't tell you what incompatibilities our features may have with particular add-ons.

However, this generally emphasizes that, as add-on devs, it's important to prefix things whenever possible, particularly when integrating deeply into the core. This probably something that we haven't made obvious enough until now (with this really only being the second opportunity for it really to rear its head).

Add-ons for 1.2 that use the built in modification system will need to be re-exported in beta 2 to get the updated XML name.

 

[guiltar]

@Mike , I've changed the prefix (also route and navigation) so, there is no need to change core.
The TMS parent is now tms_mods. Addon devs just have to reexport the addons with new TMS.

Users, please test new version from github
It should be compatible with both 1.1 and 1.2.

Also I will write the importer TMS->Core.
But core does't support style modifications.
So maybe TMS will be extension of the core system for style mods.