Plugin mods

This idea just popped into my head about 5 minutes ago. Please tell me if I'm being stupid

I looked at all plugins that somehow modify the standard groups plugin, and I realized that I want to get the functions from a lot of them, but they don't often work well together. 

So what about this way of doing things? A plugin itself can have mods. A mod allows certain functions as any current plugin does, but it works in a kind of different way. Mods are simple 1 function codes that fit inside a plugin. In my admin backend I go to plugin list and open settings I can see all the mods I've uploaded into that plugin folder. I can set this one on, and that one off as I like.

This way we as admins can get the best of all worlds.

Example:

Admin 1 wants to extend groups in the following ways:

 

  • Way 1
  • Way 2
  • Way 3
Admin 2 wants to extend groups in these ways:
  • Way 2
  • Way 3
  • Way 4
Both admins can upload all the mods they can find for groups if they wish, but in the backend they can enable different ones.  Let me explain further:
Current groups extended alters groups in say 5 ways. But I don't want all 5 ways, only 4 or perhaps 3. Do I upload it? No I perhaps create an ulterior plugin that does what I want. But if in backend I had a way of turning some of those 5 ways off I wouldn't need to create my own plugin, just use the current one.
Further, a developer wants to create a new function for groups. He doesn't need to create a whole new plugin that might collide with other current plugins. Just make the new function and upload it into the groups plugin /mod folder. This way, it would be a lot easier for devs to compare their code for clashes with other devs' code on a particular plugin because they don't need to sift through endless code. Just a few functions.
This method would allow admins to fully customize their plugins in all sorts of ways and reduce incompatibility/clashes as they can find out exactly what function is clashing with what. (instead of which huge plugin is clashing with which)
Am I making sense?
So in essence for groups we could have the following mods:
  • Group Custom Layout (enable/disable)
  • Group Admin Transfer (enable/disable)
  • Group River (enable/disable)
  • Group Moderate (enable/disable)
  • Move Forum Post (enable/disable)
  • AU Group Notifications (enable/disable)
Looking back over this, perhaps it seems like a complete waste of time as all it's doing is adding another level to the plugins. Perhaps all it would do is group together all the enable/disable functions relevant to groups in the same place for easy finding. 
I'm not really sure, but I do get the feeling that perhaps it would be easier to some degree. Then what can be done, is a groups bundle with all of these mods. I can just set the ones I want on and leave the others off. 
Am I stupid? (Be nice it's been a long day ;p)
  • As a by thought, search 'group' in plugins directory gives me 6 pages. Making it a 'group bundle' and allowing to enable the functions that I want would make it much easier (in my opinion) to do this and that.

    More of a team effort from devs so to speak instead of an ad hoc upload this plugin then spend x days testing against all other group type plugins out there as complaints come raining down from y users about incompatibility.

    Perhaps a lead dev (not necessarily a core dev) for the groups plugin team who helps to organize new mods for it and test it against current mods in the bundle? Community dev teams would make things work out really well I think. Give us some organization, cohesion and direction. That way we don't end up with 2 devs releasing a similar plugin within days of each other. Waste of time in my opinion. People making new mods for the group plugin could communicate with the lead dev to find out what other works are in production at the moment.

  • @ Trajan excellent suggestion.

    Thanks

  • Trajan, I was interrested by your ideas since we just finished a huge plugin for groups and we've encountered a few problems with making it compatible with all other widely used group plugins.

    We've finally decided to use the views system, detect which plugins are installed and serve views from different plugins based on this. We've also included a number of views to make the plugin easily extendable. This way each plugin creator can easily add a widget in his plugin that will be supported by the system.

     

    I'm affraid your solution won't work, since most plugins that extend groups also implement other features. They're mostly task-oriented, not group-oriented.It's easier to keep functionalities that do one thing in a single plugin, than to write two plugins for one feature.

     

    From the experience with groups plugin, I think you can archieve the same result with the views system. In case you create plugins with a few simple rules,  users later can decide which functionalities should be used simply by ordering the plugins. In case you want to have one of the functionalities out, you can always overwrite the view. It's also not so hard to find the code responsible for extending groups, as you can always search for views/default/groups, or groupprofile_xxxx.php in the plugin.

     

    If there is however a chance of building a system that would simplify extending groups and managing extensions and won't add extra complexity, I would gladly include it in our plugin.

  • (This is the 5th time I've tried to write this...chrome is annoying)

    @Vazco - your plugin is a great idea.

    As to my thoughts above I understand what you mean. I guess what we could get out of it all is the need for a self-aware dev community. Devs need to be aware of what others are currently working on so that we don't overlap and can accomodate each other in our separate works.

    We are after all a 'community' so working together and creating complimentary work would benefit us all in the long run. Right?

  • Adding loosely coupled features is exactly what plugin hooks are for.  A good example of this is the search plugin, which allows any other mods to respond to a hook for search types and register their own search.

    Groups sort of use this feature, but not as much as it should.  

    Another thing you can do is to create a separate plugin that overrides certain views and actions of its parent plugin.  Cash mentioned he's using this approach for some changes they've had to make on their Elgg install.  It's a great way to implement new features without re-writing or changing core plugins, which makes upgrading a lot easier!

  • Trajan, you're right - more information is always better.

    When it comes to Elggdev, you can always check the big projects we're working on on our plugin idea pages. It could be good to have a similar list on Elgg.org too.

     

  • There was but no one used it so we removed the link from the wiki: http://docs.elgg.org/wiki/Under_Development

  • @Brett, perhaps having a group in the community, not on the wiki. Or if there's time throwing together a quick plugin (simple form saying username, date started, name of plugin, concept) that people can see.

    Keeping it on the community would make people more likely to spot it. Add a little box on community/homepage or plugin repo homepage for awareness etc. 

    Finally, perhaps a community user or 2 together could try to manage this to keep it all going. I would be interested in helping out for it if a partner came forward.

    Thoughts?

Feedback and Planning

Feedback and Planning

Discussions about the past, present, and future of Elgg and this community site.