Ideas of the community to change plugin system to enable plugin fixes
Caylus
✭✭
See https://open.vanillaforums.com/discussion/comment/251825/#Comment_251825 for full comment chain.
TL;DR description of the problem: Lots of addons are subtly broken. Of the older addons, the original authors can't be contacted anymore, which means they will stay broken unless uploaded with a new name.
This topic is intended to facilitate a discussion how to best fix that issue issue.
I've assembled the relevant ideas from the other thread here:
@x00 said:
I think right now just being able to mark an addon as deprecated, unmaintained or remove it would be useful. Perhaps including version in the search.I think there is an issue with other user taking over other's projects, really this is a fork and should be mark as such. A project may have a certain scope. If someone wants to go outside of that it should be a fork. In order not to cause issues, in that respect it should be uploaded as a fork and marked as such.
I like the idea of it being github driven as was discussed before.
@Caylus said:
Because my personal idea was that if A ) The last update to a plugin is > 3 months, B ) community has indicated it's broken (through the existing "It's broken" button), C ) you have a custom PluginFixer permission (to prevent scammers), you're allowed to contribute to a plugin even if you don't own it (There will also of course be an option for the plugin owner to disable this update functionality entirely).Then if a user clicks the big "download now" button they'll get the latest version, but there will also be a list available with different versions of the plugin (grouped by author/minimum Vanilla version).
So if user A owns a plugin that requires Vanilla 2.2, and uploads a new version that requires the same version, it simply gets overwritten. If user B would upload an update to user A's plugin, both A's and B's version are available, but if one clicks download now they'll get user B's version.
If user A then subsequently uploads a new version, their version gets overwritten and will become the default to download again (B's version will still be available).
If user A uploads a new version that requires Vanilla 2.5.1 though, there will be three versions available: User A's 2.5.1 one, User B's, and User A's original one for 2.2.
In that way, as a plugin author you also don't have to be backward compatible as much. If a new version doesn't work with an older version of Vanilla, people can still download the old version anyway.
I hope this image helps illustrating what I mean:
@River said:
Probably be better to get a trusted volunteer to upload fixes to an authors plugin, if the author agrees. there are moderators here, there are admins, there could be a plugin fixer.
Some fixes of plugins are already provided but the author doesn't have the 5 minutes to upload the fixes to the plugin and update the plugin for whatever re4ason, so the plugin fixer could take the 5 minute job to assemble the provided bug fixes.If this idea has merit and you guys are open to alter the design in the manner I described above, I'm willing to work out a first version. But to be frank, I'll need help polishing the code I crap out to make it up to par to the rest of the code of Vanilla. Which practically means I'm going to need help from either @R_J or @hgtonight since as far as I can see from the Vanilla Github they're the two open source people who have experience contributing to the Vanilla core.
So... would you guys have time to check my code if I get the go ahead to write it? O:)
Of the 800 themes and plugins in the add-on section, probably less than 50 are bug-free and work with vanilla 2.5.1. Many probably haven't worked in years from the comments
Maybe all of them should default to broken. Despite bug reports with corrections, the downloadable code often remains unchanged by author. It would be advantageous if a simple update to downloadable plugin could be made with bug fixes, if the plugin author didn't have the 5 minutes to make the provided bug fix changes that were tested, the new position of "plugin fixer" could update the plugin.
I see a lot of potential abuse when multiple authors beyond plugin authors start adding mods instead of plain old bug fixes. willy-nilly versions and questionable improvements that might break more in the future.
Addons on github have a lot of discussion...
https://github.com/vanilla/addons/issues/537
with diverging opinion gridlock.
from github ....
linc commented on Jul 16 2017 • >What would be a reason to remove one of the plugins? •Addon has become obsolete by core changes, another addon, or exterior changes. I think the two 'compatibility' addons may fall in this camp, now. •Addon is broken and no one cares enough to fix it. I suspect Mollom falls in this category. •Addon has issues that are not resolvable or experience has taught us it wasn't as good an idea as we thought. Example: CustomizeText, Whispers. >And it could still serve a) as an inspiration and b) as a code example.Dead code should be used for neither, IMO. Our ecosystem is already littered with examples that are the opposite of a good idea and/or full of illegible code. Our examples should be our best curated work, not the junk heap.
probably the same standards should be true for addons here
To respond to River's idea, "Probably be better to get a trusted volunteer to upload fixes to an authors plugin, if the author agrees. there are moderators here, there are admins, there could be a plugin fixer.", that's what I intended to say with the custom PluginFixer permission you'd need to fix a plugin: A.k.a. you have to be trusted and promoted by a moderator to become a pluginfixer that can upload fixes of plugins that are not yours. The problem with requiring permission from the author is that for the plugins where it's truly necessary for someone to take over, the author can't be found. That's why I added the requirement that to be able to update the plugin, it had to be at least six months old, and the author can't have logged in for that period either. That at least guarantees that it's an "abandoned" plugin.
Re: "I see a lot of potential abuse when multiple authors beyond plugin authors start adding mods instead of plain old bug fixes. willy-nilly versions and questionable improvements that might break more in the future.", I'd say that if the plugin is broken, any change that makes it work is an improvement. But we can also draft a guide of best practices, which PluginFixers are supposed to follow if they want to stay PluginFixers.
That leads me to x00's comment: I feel with a best practices document, most of your concerns about project forks will be met right?
If the scope of the project is altered significantly, it should be uploaded as a different plugin. If not and the scope stays relatively the same, then people can upload a fix, and the old plugin will still be available for those who don't want the extended functionality.
I like it being github driven too, but I'll say that for the current problem of abandoned plugins it won't help that much. Authors will still have to approve merges of branches on github, and won't do that if they've disappeared completely.
Comments
Here are my visions...
As a Developer
As a User
One of the biggest challenges is how to communicate which plugin "is working" and which is not. By now this is a flag, which is the worst solution in my opinion. That is misleading and insufficient, even worse than having no indicator at all.
I would like to see the number of people saying it is working and the number that is saying it is not working. That is far more relevant. This information should be shown consolidated for all versions but should be available on a version level. Maybe showing only the information directly connected to the most recent version would be better...
One important thing for me would be to still have access to all plugins, even if they are broken, insecure or whatever. those could be marked with tags such "caution!" and this tag could be highlighted red to give as much feedback as possible. But even those plugins can serve a) as an inspiration and b) as an example
I agree with x00 that an altered plugin is a new plugin. If there would be a special tag "outdated" combined with a list of alternatives, it would be easy to find fixed versions. Plugins which are only fixed versions of other peoples work could use a special tag "bugfix" to show that they are nothing new.
Maybe there will be some kind of naming convention come up like "PluginName (fixed by AuthorName for 2.5.1)" and so when "PluginName" is searched the search result would show:
PluginName
PluginName (fixed by Author1 for 2.0.18)
PluginName (fixed by Author2 for 2.3)
PluginName (fixed by Author3 for 2.3)
PluginName (fixed by Author4 for 2.5.1)
That would make it easier for users to find "duplicates". All those fixes should be linked as alternatives, anyway.
Following process for "alternatives" would be great: when a plugin is uploaded, addon.json should be parsed for
"alternatives": ["pluginkey1","pluginkey2",...],". This information would automatically make the plugin show up as an alternative on the page of the mentioned plugins.Additionally moderators should be able to mark alternatives manually, so that a user could ping a moderator saying: "hey, plugin this seems to do the same as plugin that, would be cool if you could connect them. thanks."
response to you vision through my lenses...
reasonable
you can - add a url to your profile page. it may not be clickable but it is a url.
pie in the sky questionable
absolutely correct, the broken flag is absolutely the most worthless piece of junk code added to the addon section.
exactly makes no sense.
great idea - probably more useful than anything else.
huh
leads to the problems of social rating plugins. meaningless palaver quantification.
whole concept is meaningless. a meaningful comment is meaningful, a number is a meaningless number posing as a statistic.
clutter
ok developer comments as a separate category of discussion.
maybe 3 categories or tags for each plugin discussion.
"positive feedback" "problems or bugs" "suggested improvements or mod requests"maybe "I'm using with the users name and sent directly to the author without it becoming a popularity contest with friends repeatedly pressing button.
meaningless see above regarding numbers. if 10 users don't know how to change permissions correctly or adjust .htaccess and then report a plugin broken, it becomes meaningless because the user may be "clueless" or "challenged"
you mean more clutter. change one line and claim it as one's own.
yes. some developers don't understand the concept of screenshots
vanilla version compatibility is ridiculous - since within a month or two of a new version of a security update and you should promote use of using an secure version of vanilla. NOT use AN OLD INSECURE VERSION.
TRUE!!!!!!!!!!!!!!!!!!!!!! once again a poorly thought out idea by the addon coder.
clutter
clutter
ALL plugins should be moved to a category called "under development or unproven" and then after being tested by someone other than author then it can be moved to working category.
AUTHOR should not be allowed to vote on their own plugin.
PLUGINS BROKEN FOR TWO YEARS should be removed completely, a new rewrite from scratch would probably be better anyway.
instead of have 20 broken alternatives, one working plugin would be better and more dependable, users already can't figures things out why add clutter.
see github for another discussion about broken plugins, with vanilla comment.
https://github.com/vanilla/addons/issues/537
Pragmatism is all I have to offer. Avoiding the sidelines and providing centerline pro-tips.
I couldn't upload a Vanilla 2.5+ only app to the directory due to a bug, but hope it gets fixed so we can get updated addons out to the community.
Add Pages to Vanilla with the Basic Pages app
Few initial thoughts:
1. I couldn't handle others playing with my code. All too often I have moved forward with plugin code (WIP for the next version) and I'd hate to have to merge versions.
2. Backward compatibility is ideal but we've all seen how Vanilla versions have deviated from that principle and if you add to that the desire to utilize new version functionality the developer is facing a difficult choice of which versions to support. With that in mind I'd like to be able to indicate _both _the lowest Vanilla supported version and the highest it proved working with.
3. I'd take with a mountain of salt users' claims on broken plugins. Sometimes the user did something wrong, sometimes it has to do with the particular user environment (and changes users make), sometimes with other plugins in the environment, and indeed sometimes with the plugin itself. So I find the existing "working with" designation useless and would stay away from anything similar in its stead.
4. All for screen shots, I'd make these manadatory... Would like thumbnail too for the directory (two different things).
5. Tagging - great idea. With appropriate set of tagging there is no need for alternative/similar plugins. I'm in favor of a preestablished set of tags under moderator's control. If a developer seeks a new tag, the moderator's community can decide.
6. I like Joomla's addon directory (or to be honest, the way it used to be a while ago) - a grid-like presentation filtered by search words/tags (no need to mimic their categoriazation).
7. I don't trust ratings, likes, dislikes, numbers, etc. See it as unreliable noise carrying forward legacy values.
8. Really like to be able to know who is using my plugins. Would be helpful to be able to reach out for beta testers, solicit feedback on new features, etc.
9. Agree on not requiring github. I only use it as a store area (I develop plugins in my intranet which cannot access github).
That's my initial reactions/list.
^^ I like this idea!
^^ This seems quite doable. Although slight detail, I'd say the check happens when someone opens that plugin page after X time, not that after X time all plugins in the addon section are refreshed.
Would also solve the problem of the "plugins mantained by the Vanilla staff" automatization.
^^ I disagree with this vehemently. Maybe with better docs this might be an option, but to me it seems that if you delete broken plugins without making sure there's an alternative available, it will actually be nigh impossible to create one from scratch for an amateur.
I'd personally say the broken flag has value - as long as it's also visible how many people say it works for them and how many say it doesn't. If the people having problems outnumber the ones for who it works 3 to 1, then it's clearly broken and it should be flagged as broken IMHO.
In general I agree and I think it's just a misunderstanding in the wording. When speaking of a broken flag I mean a boolean value for broken or not broken and that is what I call irritating and useless. Seeing the numbers of peoples who reported a plugin as broken or working would be a useful information.
I think that must be anonymous in order to show relevant values.
As a user I would like to be able to judge which of 5 similar plugins might be best. I personally think that the best way to get that information is by looking at some kind of rating system. What's your opinion on that?
I see the voluntary list of users independent from any counts/reactions. Just another thing I think is valuabe.
I think that as Vanilla progresses with newer releases plugins slowly break until a new plugin version is published. Now, how are we to correlate ratings across plugin versions vis-a-vis the version that the rating user happens to use. That's what I meant by "legacy values" - values posted some time ago reflecting a likely unknown plugin version and definitely an unknown Vanila version used by the user. This will be excacerbated by Vanilla's plans to have more frequent releases. I also think that users may try a plugin, have some issues (possibly due to reasons unrelated to the plugin), downrate a plugin and move to another alternative. That downrating will be carried on. There may also be a downward bias -- users may downrate something but may not pay enough attention to uprate (How many times have you seen someone asking a question, a volunteer spend time to help, and then the original user disappears never bothering to note whether the solution worked, not to mention to thank the volunteer?).
My bottom line recommendation - don't bother with rating, go simply with tagging and hopefully plugin developers (and occasionally moderators) will correctly tag their plugins and users will be able to have choices.
I (as a developer) would like to be able to mark two version parameters - the lowest Vanilla version the plugin works on (this exists today) and the highest version the developer tested it on (I'd be OK with other developers/moderators change that value as well).
As you narrow down specific issues or goals, I recommend filing an issue for each separately on the
communityrepo for further narrower discussion of proposed fixes before you start coding.