PlugIn Conflicts

Thoughts on "PlugIn Conflicts" are invited from respected developers.

I have some ideas on how this may be handled and am interested on other's contributions.


  • Don't PlugIn conflicts buzz us all every one now and then ?

    Not one human being has ever back posted here !!

    But everyone has problems that really relate to PlugIns conflicting with each other in some manner depending on how they they are php-coded.

    I have the basic concept / design of an Elgg PlugIn compatibilty / conflict detector ;-)

    69 days ago...

    not even 1 single response so far...

    BUT a trillion problems ;-(

    smile and you will smile with universe...

    cry and you will cry really alone with your plugin conflicts..


  • here, here, all hail the cheif.

    @Dhrup2000  I for one will remember thank you for reminding us.

  • @ALL

    My thoughts are....

    a "parsing" technique to look conflicts w.r.t. for variable naming, function naming, views overrides / extensions, etc....

    ahhh.  I have written so many compilers ;-) i am sick of the code but not the theoritical computer science... my first love !!

    compile, decompile.... obfuscate, encrypt, byte-encode,..... pseudo-compile...

    it is achievable....

  • That was actually a major question I had for you during skype but forgot to ask.

    I was wondering what kind of 'check n balances' there are in the plugin system to let me know when I either have plugins in the wrong order, so far just guessing on that one, or if naming overides etc...

    I just assumed it was built in somewhere and would warn me if something was wrong when I enable the plugin.

    Seems kinda 'wrong' to be able to just 'throw' a new plugin into the folder and have no 'system status/confic system' in place.

    sad to hear the bad news on this one...

  • It is not the exactly simply the "plugin order" that will matter... in the end...
    Considering the parsibility of the funcitons, classes, var names,,....
    We all can **accidentally introduce some serious "bugs"

    The science *is and has to be *more involved than simplistic, straight forward "php" script coding ability.. let us be serious for a few seconds... PHP is so easy to learn to code with and produce some fanstastic code with.... but when we meet some heavier concepts.. e.g. lexical analysis, token parsing -- only about  20% of the PHP buffs  will understand and follow the real THREAD.

    If 2 PlugIns accidentally name their functions with the *same name.. --> havoc happens !!!

    PHP var naming.. the same havoc...

    The PHP engine will "freak out"... and chunder.... and throw up !

    More notes later.....


  • Hi Dhrup,

    I haven't encountered problems with functions, since the really good plugins are well aware of the errors. Like Vazco, always adds Vazco_ to his plugins. So they rarely have any conflict.

    Most of my problems have been CSS design. Those are much more tricky. But i have no idea how to solve this, since each plugin has its own needs, and again, developers who are good, are concious of these pitfalls.

    So, using nicely coded plugins, from experienced developers, its not so bad.

    Uddhava dasa

  • This is what the concept of namespaces is supposed to solve. Currently though, because my host isn't using 5.3+ in PHP, I'm using static classes as the namespace

  • Elgg's views overrides / extensions, etc.. go a little beyond what PHP offers to encapsulate.Elgg has no way do the same enacaps. I have a funny feeling that some / many plugins conflicts occur because of Elgg related stepping on each others' toes. ==> because no matter how well the PHP is coded - if 2 PlugIns both want to override, overload (e.g) the **same event.. what happens next ?

    If 2 diff PlugIns are "well coded", BUT  both override the same CSS ? We're up the provebial creek and drowning ;;; It is issues of this (Elgg) natute.. I was thinking that needs addresssing.

  • Ah! I see what you mean now. Sorry, I misunderstood.

    This will definitely require some thought, especially since it will be different for different things (e.g. CSS would be different than events); but an easy naiive solution would be to introduce a default flag that would override the view. 

    Assuming the developer is aware of this, they can do somethign liek this:

      * @uses $override overrides view if true, if false, appends to an array list and is chained

    register_elgg_event_handler('init', 'system', 'someplugin_hook', 500, $override = false); 

    OBVIOUSLY, this won't work if a bad programmer overrides the same event and sets $override = true.

    Just a thought, definitely not well thought. What are your thoughts?

  • ;-) AT LAST.... some real comments....!!!

    I have some too many thoughts inside my small head. I do actually get real migraine headaches! If you're comfortable with the concepts of lexical analysis, etc relating to grammars and compiling methods.. you will see that *some of those techniques or algorithms styled in a similar manner might be used to analyze code within Elgg, including Elgg's core and pre-packaged PlugIns as well.

    So for example, it would be nice if a 'Conflict Detector" can say:=

    • Both PlugIn A and B are trying to override views/default/header_contents.php
    • You are gonna have problems !!!

    Of course the same applies to the PHP related areas, such as PlugIns not handling encapsulation properly.. Just have a read read thru some any of the PlugIns code and you will see...


    re "..definitely not well thought.." => I'd not blame the PlugIn writer in a hurry because -- who has time to study all existing PlugIns and read over the code to determine that the one event they want to trap already has another 1 or more PlugIns trying to do the same !!! ;-)

    Remember those posts where people install a few too many PlugIns and suddenly ==> "pooooofffff!!!!" their Site is gone into the Blank Page of Death Cloud ;-(

    I think some and a lot more study is needed to determine how to avoid Elgg conflicts - if this can be even be done..?