WordPress.org

Ready to get started?Download WordPress

Forums

Plugin Dependencies
conflict management idea for "Provides" (4 posts)

  1. David Dean
    Member
    Posted 2 years ago #

    Instead of disabling the conflicting plugins outright, can some variable or option be set, notifying the plugins of the conflict? That way, an author could disable the part(s) of his plugin that conflicted but let other parts continue working.

    If there are, say, two Facebook plugins - one providing login and one providing syndication - they wouldn't both try to add data to the header, and could potentially share other data.

    Maybe an administrator could even select which of the conflicting plugins should provide the feature in question.

    I love the idea of this plugin, and think it's something that could really help keep people from reinventing the wheel so often in plugins.

    http://wordpress.org/extend/plugins/plugin-dependencies/

  2. scribu
    Member
    Plugin Author

    Posted 2 years ago #

    Maybe an administrator could even select which of the conflicting plugins should provide the feature in question.

    He already can: by activating a conflicting plugin, he implicitly chooses to use that one.

    If there are, say, two Facebook plugins - one providing login and one providing syndication - they wouldn't both try to add data to the header, and could potentially share other data.

    If they define different "Provides" headers, say 'facebook-login' and 'facebook-syndication', they wouldn't be conflicting in the first place.

    Instead of disabling the conflicting plugins outright, can some variable or option be set, notifying the plugins of the conflict? That way, an author could disable the part(s) of his plugin that conflicted but let other parts continue working.

    I don't think that's a good idea. Plugins should be single-purpose or announce multiple distinct features that they provide:

    Provides: facebook-login, facebook-syndication
  3. David Dean
    Member
    Posted 2 years ago #

    I don't think that's a good idea. Plugins should be single-purpose or announce multiple distinct features that they provide:

    Provides: facebook-login, facebook-syndication

    What happens to the hypothetical plugin with a declaration like that? Would any plugin with EITHER facebook-syndication or facebook-login deactivate it? If not, how would another plugin that handles say, 'facebook-login' and 'facebook-comments' interact with it?

    If they define different "Provides" headers, say 'facebook-login' and 'facebook-syndication', they wouldn't be conflicting in the first place.

    Ultimately, the situation I'm trying to describe is that each is declaring something like:
    Provides: facebook-auth, facebook-syndication
    Provides: facebook-auth, facebook-og, facebook-login

    Users tend to want plugins to DO something, so they choose monolithic plugins over modular ones to get the marquee features. Deactivating either one of the above examples because of a conflict in facebook-auth is likely to confuse and frustrate the end user, who doesn't know about the building blocks, and just wants both features.

    That in turn will force plugin developers to either avoid the Provides line or create unique "feature" names, sacrificing modularity. Allowing plugins to strategically disable conflicting features without deactivating other features would, on the other hand, encourage modularity and adoption.

  4. scribu
    Member
    Plugin Author

    Posted 2 years ago #

    What happens to the hypothetical plugin with a declaration like that? Would any plugin with EITHER facebook-syndication or facebook-login deactivate it?

    Yes, it would.

    If dependencies were automatically installed, you wouldn't be asking for this.

    You could just build single-purpose library plugins and put them on wp.org. The only trick would be that the dependency name would have to match the wp.org plugin slug.

Topic Closed

This topic has been closed to new replies.

About this Plugin

About this Topic