DRE
Well-known member
Maaaaan it's not truly wordpress-like until you don't actually have to use a FTP program just to install a plugin. Xenforo still has a long way to go.
Are clashes between Addons/Plugins less likely with Xenforo ?
- Thread starter Digital Doctor
- Start date
- Status
David_
Active member
+1
tenants
Well-known member
This is an old thread, but I've now learnt the hard way the importance of what ragtek mentioned (and his text may have been overlooked)
If you override a function, make sure you call the parent (and then use that), this should avoid many potential clashes
I spent 2 days setting up different test environments and testing, and then realised if I changed the "Callback Execution Order" of 2 plugins only one of them works at a time *depending which had the highest value ...
This meant a clash... originally they had the same callback executions order and were sometimes working.. sometimes not (making it very hard to detect what was going on)
.. but this was due to a plug-in clash
If the overridden threads had simply used
parent::myFunctions($bla);
at the start (and then used this through out, and returned related to the parent) I would have avoided banging my head against the screen, and prevented the clash
Re-quoted what ragtek said, since I wish I reialised the importance of this earilier
Digital Doctor
Well-known member
conflict between:
(1) http://xenforo.com/community/threads/better-blogs-paid.36836/page-18#post-444334
(2) http://xenforo.com/community/resources/self-delete-by-waindigo.791/
Fatal error: Access level to Waindigo_SelfDelete_ControllerPublic_Abstract::_preDispatch() must be public (as in class XfAddOns_Blogs_ControllerPublic_Abstract) in library/Waindigo/SelfDelete/ControllerPublic/Abstract.php on line 30
(1) http://xenforo.com/community/threads/better-blogs-paid.36836/page-18#post-444334
(2) http://xenforo.com/community/resources/self-delete-by-waindigo.791/
Fatal error: Access level to Waindigo_SelfDelete_ControllerPublic_Abstract::_preDispatch() must be public (as in class XfAddOns_Blogs_ControllerPublic_Abstract) in library/Waindigo/SelfDelete/ControllerPublic/Abstract.php on line 30
Looks like a problem with BetterBlogs. Access level for *_ControllerPublic_Abstract::_preDispatch should be protected, not public. It is protected in the Self Delete addon.
This is already a sore subject for Waindigo.
Unfortunately most of Jaxel's add-ons make the same mistake.
As well as the function being protected in Self Delete add-on, it is also protected if the abstract class and every single controller used in XenForo. Quite an easy mistake to avoid. It seems to be taking forever for both developers to fix this too. Even though it's a very easy fix.
Digital Doctor
Well-known member
Volion
Active member
While I really appreciate the time and effort it takes for developers to produce and release mods and extensions to the platform. Lately I am having to spend hours on end debugging or having to disable one or several other paid for add-on's to use a newly purchased one.
It's to bad there is not a mod site were developers could submit their work to have it checked and authorized as clean and friendly, award them a badge to display. I for one would be far more inclined to purchase those products and enlist the developer for work.
It's to bad there is not a mod site were developers could submit their work to have it checked and authorized as clean and friendly, award them a badge to display. I for one would be far more inclined to purchase those products and enlist the developer for work.
Digital Doctor
Well-known member
Authorizing addons as clean and friendly ? Interesting idea. I suspect it's not possible at some level and beauty is in the eyes of the beholder. I'm sure it could be a good way to pick out the really bad coding habits.
Have you seen any coding community do this successfully ? which one ?
Digital Doctor
Well-known member
clashes might be more uncommon that we think !
Look at this number of addons installed !!
Look at this number of addons installed !!
MOZ
Well-known member
Has been fixed in the last version, use TMS instead and the fix was mentioned in the thread.
There is an issue with how Poke Forum Members retrieves user model, author has been informed.
Digital Doctor
Well-known member
Conflict is a bit of a strong way of putting it.
It was pretty much a very edge case.
First, it only happened if Debug mode was enabled which, arguably, it shouldn't usually be. Second, the cause was due to an improvement added to an existing XenForo function which TMS was extending.
Basically the error would normally be suppressed, but having Debug mode meant that the server was being overly strict over something that wouldn't normally be a problem.
Moral of the story is: Don't run debug mode if you don't need to (and if you need to, you'd know how to rectify it pretty quick anyway).
Digital Doctor
Well-known member
Digital Doctor
Well-known member
Deeming = Fastest Coder ever ! (but still slower than Lily)
- Status
Similar threads
