Are clashes between Addons/Plugins less likely with Xenforo ?

Status
Not open for further replies.
That is not a clash. This is one mod breaking the class extension system... which makes all bbcode extensions fail. It is not XenMedio's fault, XenMedio completely follows the class extension system or XenForo. It is ParseHTML's fault.

This, at the time I couldn't find a realistic alternative to let me do what it does, may look into it again soon
 
I am against frameworks that have to be installed to use certain things. I do use a framework but it is more of a helper library which works with all mods the same and can't have problems with other addons. It will be released and I expect it to gain traction with certain developers.
 
This, at the time I couldn't find a realistic alternative to let me do what it does, may look into it again soon
Have you considered increasing the Callback Execution Order of your mod? So that it lets other BBcode Class Extensions run BEFORE it breaks it?
 
Have you considered increasing the Callback Execution Order of your mod? So that it lets other BBcode Class Extensions run BEFORE it breaks it?

Wouldn't make a lot of difference, it replaces most of the bbcode code from viewpublic onwards to pass the poster's user id through to the bbcode formatter. A horrible solution, I know

But yeah it probably wouldn't be too hard to integrate the hook system so it doesn't break everything else, I'll look into it
 
sorry my english not good
the author said. he build this mod for XF version 1.00. He don't know it work or not.
Then the other guy test it work. But i think its too old to support XenForo Enhanced Search (this is new addon)
last time i try it not work with XenForo Enhanced Search. It cannot find any exist thread.
 
I don't think clashes are less likely with XenForo when you have different Mod installers being created by people to auto install their mods. How can one persons auto mod installer keep track of another mod using a different Mod installer platform?

There should be one global mod installer only (used for all mods), that installs and un-installs them, keeping track of changes each mod installed makes to code, and can take that into consideration when another mod editing the same template around the same area is added.
 
I don't think clashes are less likely with XenForo when you have different Mod installers being created by people to auto install their mods. How can one persons auto mod installer keep track of another mod using a different Mod installer platform?

There should be one global mod installer only (used for all mods), that installs and un-installs them, keeping track of changes each mod installed makes to code, and can take that into consideration when another mod editing the same template around the same area is added.

Are you not contradicting a man who authored, wrote and developed XenForo? I never knew you were considered a XenForo expert :)
 
Did you even bother reading my reply proper and what it said? Obviously not, otherwise you'd know I was talking about when different mod releasers create their own auto install/uninstall "framework" for their own mods - installing them automatically so no manual template edits are needed. My point was, if a person installing different mods is also using more than one mod framework to install them automatically, how can one mod framework keep track of what another mod framework altered?

Hence why I said, you really need one global framework for installing all mod to keep track of changes made between them all. Done to check for any possible clashes with different mods and this is nothing new, sites like phpBB have been using this method for donkeys years with ModX.

http://www.phpbb.com/mods/modx/faq/
 
Oh I definitely read what you wrote. :)

I don't think clashes are less likely with XenForo when you have different Mod installers being created by people to auto install their mods.

I also read what Kier wrote too :)

To answer the question though, yes, collisions are far less likely and better handled by XenForo than by the vBulletin plugin system due to the fact that XenForo's plugin system has strict control over the data exposed to each callback function, whereas vBulletin's hooks for the most part exist in global scope, allowing them to modify just about anything at will. While the approach we took when we wrote vBulletin's hook/plugin system allows for great flexibility, it has the caveat that it's virtually impossible to avoid collisions, or to ensure backward compatibility through newer versions. Hence why we did it differently for XenForo.
 
I don't think clashes are less likely with XenForo when you have different Mod installers being created by people to auto install their mods. How can one persons auto mod installer keep track of another mod using a different Mod installer platform?
If there was a "database of what each addon changes" ?
Would TMS help here ?
There should be one global mod installer only (used for all mods), that installs and un-installs them, keeping track of changes each mod installed makes to code, and can take that into consideration when another mod editing the same template around the same area is added.
Anyone with experience here can suggest something ?
 
Clash between Minorin toolbar and Waindigo Library.

Hi Darkimmortal,

I have found an issue with your code that causes the minorin toolbar to throw errors in loop when the 'editor' template is called by another addon. In my case, it is with the Waindigo Library addon, which pops up an editor overlay for editing article pages.

The following lines in minorin.js cause a rapidly growing number of Uncaught: TypeError: Object [object Object] has no method 'minorinSetup'.
PHP:
if($("#QuickReply > div:first > textarea").minorinSetup(true).length == 0)
    $("#ctrl_message").minorinSetup(true)
Eventually, the toolbar doesn't even show up.

There is no quick reply textarea on Waindigo Library article edition pages. I believe this happens because the jQuery selector does not return any element. Maybe you should modify your code and add a foolproof test for the selector output?
 
Why do you post those here? No one is going to read it. Tell the authors and leave it at that.
 
Ahhh so that's why most modifications don't break after we upgrade unlike vBulletin. Interesting. I used to dread upgrading when I was on vB.

Hopefully they built the system all wordpress like. I can find some very old and dated wordpress plugins that still work great even on the latest version years later with no bugs.
 
Status
Not open for further replies.
Top Bottom