Plugin XML format, RFC from dev/plugin authors

[tamarian]

Hi folks,

I think the plugin XML file could be greatly enhanced with a few new fields and some extra functionality.

There's already a couple of hacks to enhance it, but I really think it's best done from the source (vb.com), otherwise upgrading would be complicated if plugin authors and users need to keep porting those hacked plugin changes with each upgrade.

Please add any fields you think are useful, or any comments. Who knows, it may show up in the next beta :)

Proposed new optional fields to the XML file format:

Plugin Description: With so many plugins listed, it would be helpful to the users to have a summary of what this is for. Already avaialble as new hack (https://vborg.vbsupport.ru/showthread.php?t=82893)

Plugin version: Would be a good reference for support from the author. Already available as new hack (https://vborg.vbsupport.ru/showthread.php?s=&threadid=83107)

Plugin version check: This offers the option of checking for the latest version of the plugin. Already available as new hack (https://vborg.vbsupport.ru/showthread.php?s=&threadid=83107)

Plugin author: Author's name or username

Plugin source URL: Mostly the plugins's support thread

Plugin credits: For earlier version if ported, or any co-authors.

Plugin License: Useful if there are any special terms.

etc...

Plugin group: This would identify the main plugin, for multiple plugin hacks and would help organizing the hierarchy for plugins (like template groups). It can also be useful if vB implements an "all or nothing" option for large plugin sets, that have to be used together (a single On/Off-Switch for one hack - even if it uses multiple Hooks.). This, of course, is not just a format change :) I just have the feeling vB will do soemthing like this anyway.

---

Any way, that's a draft. What do you think?

[Andreas]

All of these things are useful.
IMHO the most important thing would be the possibility to have a single On/Off-Switch for one hack - even if it uses multiple Hooks.
Currently it is a real PITA having to disable/delete a hack that uses multiple hooks.

[tamarian]

IMHO the most important thing would be the possibility to have a single On/Off-Switch for one hack - even if it uses multiple Hooks.
Currently it is a real PITA having to disable/delete a hack that uses multiple hooks.

That what I meant by "all or nothing" option. But I like the way you put it better :) So I add it.

[Marco van Herwaarden]

This should really be posted at vb.com.

There is a thread about hook enhancement requests there.

[tamarian]

This should really be posted at vb.com.

That was the intention, when the input is collected from plugin authors. At the rate things are going, we'll end up with 10 different hacks for these fields.

There is a thread about hook enhancement requests there.

That thread is for "hook location requests", but I posted a link there anyway. If they say it's off-topic, I'll rat on you ;)

[Marco van Herwaarden]

hehe, i am used to being used as a scapegoat, no problem.

I don't even know how that thread is going atm. So much short on time right now, that i haven't even had the chance to have a decent dive into 3.5. :(

And then to know that the month before 3.5 came out i had all time of the world.

[eXtremeTim]

I dont ever see them making a plugin version checker. I could see them doing the plugin version stuff.

[Paul M]

Version check, credits and licence do not worry me, the rest seem useful.

I really would like the group facility to tie plugins together, like styles and child styles.

[Marco van Herwaarden]

In my opinion a group function is really a must.