Add-on Management Tools

TomTester

I just read this:
http://lussumo.com/community/discussion/4399/applying-extensions-to-multiple-custom-pages-with-ease/#Item_1

This actually bring up a topic that needs a more attention/better solutions...
ADD-ON MANAGEMENT

Vanilla is 'plain vanilla' (basic) on purpose. As Mark has mentioned in many posts
this is 'by design' and if one needs something else, 'write, download or install a plugin'.

This works very well. The community very responsive and there's a dearth of plugins
available these days... (150+), but... the Vanilla core is really not designed to handle
add-ons very well.

We're missing:
- add-on update tracking/notification mechanisms (email, etc.)
- add-on update installation mechanisms (non-FTP, one-click installs, etc.)
- add-on placement mechanism (which tabs to attach to, vertical plugin ordering, etc. etc.)

The latter, as the initial link shows, requires users to change the code of each plugin
to add/remove the add-on from tabs (especially when pagemanager is use) as well as
re-do's of code changes when newer add-on versions are installed. IMHO this negates
most of the benefits of the purpose of the plugin add-on mechanism.

So... let's discuss possible ways of implementing add-on management in general and
add-on placement in particular...

Minisweeper

#1 is in the works. Mark knows it needs to happen and one day it will. Patience is a virtue #2 has been discussed previously. While he's not entirely against the idea he's (rightly) concerned about security risks. I know other software does it and maybe Vanilla will too someday, but maybe not. Eitherway there'll be good reason for it. #3 I made an ordering extension (far from flawless but it has been known to work) - I dont know if Mark plans on building something like this into the core. Time (or the man himself) will tell. Changing extensions to only display on certain pages through a GUI wouldnt be massively complex but it would require some careful thought..maybe I'll give it a shot one day or someone else might.

TomTester

@Mini This is not meant as criticism towards Mark. Just statement of fact and something to discuss/solve
together. Let's gather suggestions in this thread (or links to other discussions on the topic(s)) for those points.

As your add-on proves the present ordering mechanism requires extension re-writes. That's not good.
With a bare core and add-ons simple things (like ordering) should not require code rewrites (manual or otherwise).

The conf/language.php 'override' stuff is so neat. I'd just like something like that for add-ons, pref. visual, e.g.
I really like the way WP handles the widgets (i.e. no position until assigned).

Without looking at the code, I guess a 'simple' change in the core could solve a lot, e.g. use each plugin's ranking
weight as a DEFAULT or suggestion, then allow the user to override the 'suggestion' with a user-defined value
(not unlike the way pagemanager re-orders the tab display, and who could not use a 'resync panel' option ).

Any comments on the feasibility of this by the code gurus?

Minisweeper

I dont know if it would be easier to change things in the core, or abstract the SelfUrl checker and Panel/Header inserter (or whatever) from the extensions and have them controlled centrally (which would obviously need some changes to the core anyway but in a different manner). I'm too tired and have other things on my mind unfortunately but I'll put some thought into it in the morning. Another thing which may be worth abstracting is roles/permissions/preferences. Whatever we do will need a very well thought out plan though.

kyu

...and I see another problem: while I, too, like the concept of a basic core system and a selection of extensions there is a definite downside to it. People who write extensions and add-ons and thankfully make them available to the community tend to, at some time, either lose interest in their project, lack the time to further pursue it, or otherwise become unwilling or unable to carry on with it. That is, of course, their good right, as they are doing it voluntarily and usually in their spare time and without any obligation to share their work at all. However, this leaves us with the problem that we may at some time be unable to continue using an extension that our users have become accustomed to, or an add-on that our systems even largely depend on. Example: I run a Joomla! 1.0.12 site into which Vanilla is integrated by way of the J!Vanilla bridge component. This works absolutely great; however, I am now stuck with Vanilla 1.0.3 as the bridge does not work with newer versions, its author has not been seen here for quite some time, and while I am usually able to do some patching to adapt my system, adapting J!Vanilla to the latest Vanilla version is beyond me. When the need arises to upgrade to a newer Joomla! version it is not unlikely that I am going to have a similar problem, so to say, on the other side of the bridge. This is just one example of the basic problem, and while J!Vanilla, being a bridge, is not a standard extension the same kind of thing may happen with many of those, too. I don't really see a fully satisfactory solution to the problem. One possible step might be to either equip the vanilla core with a standardized extension interface that will remain unaffected even when core-internal things change, or to run a separate interface layer between the core application and the extensions so that only this interface layer would have to be adapted to core changes. I'd be interested to see what others think about the problem.