Wedge

Yeah, that's because we've implemented a lot of the fun stuff and bug fixing is the bit no-one likes doing.

That's... interesting. And unexpected.Well, we could do that - we do still need to give them some CSS because some of them do do site caching (especially the likes of the Internet Archive, which doesn't have a 'bot' username)

Hmm, I don't know. I'm still a bit spaced out from the visit to the dentist...

That is truly strange. But it sounds to me more like it's a bug of the plugin than of execution as such. Need to double check - but I wasn't able to get it to misbehave myself locally when I wrote it.

Wait... actually... I can imagine one case where it might - if it ever has to play switcheroo on languages, which it can do under certain circumstances of merging. The plugin is a bit cheeky, it just fudges the language strings.

No visible difference for me on iOS 5 w/Safari...

(4 files, 8KB)

Revision: 1873
Author: arantor
Date: 24 January 2013 22:28:19
Message:
! Banned users could throw an error if they had made a post previously. (Display.template.php, index language file)

! More of the ban UI, it can now pull a ban in the DB into the editing form. Just saving to go, really. (ManageBans.php, ManageBans.template.php)
----
Modified : /trunk/Sources/ManageBans.php
Modified : /trunk/Themes/default/Display.template.php
Modified : /trunk/Themes/default/ManageBans.template.php
Modified : /trunk/Themes/default/languages/index.english.php

It is a valid way to go but it is also a source of much complexity :/

Ok, this huge size isn't a quirk just for Retina iPads. I will screencap it later though, time for bed now.

I should add, I split this off from the plugin interfaces topic, it's more relevant here.

I can see it both ways, but I sort of need to make the decision now because it's all part of the DB structure.

On the one hand, pre-review means there is a better than nothing chance of preventing nasties. It also creates more work, primarily for me. But I know how long it takes to vet plugins, and there's all kinds of neat tricks that can be done to help with that. We can do all kinds of fun like validating plugins on upload, checking the plugin-info.xml file is valid, we can check the hooks that it requires, we can check the files for syntax errors, you name it, it's all doable.

And that's before we even get to human review. In fact, I think I'd be inclined to enforce that even if we go to post review so that nothing appears on the site to regular users if it hasn't at least passed a basic validation.

Pre-review does also put some weight on whoever is reviewing to do a decent job, but it does require also discipline in doing it regularly, not to mention having naturally high skill requirements.

Post-review lowers the workload considerably, of course, plus removes the liability ("but the team should have checked for that") but it raises the chance of someone getting something nasty through the doors.

I'm reasonably amenable to either, though in the case of post-review, I would make it clear that I would be moderating after the fact and reserve the right to remove plugins that are dangerous, and I suspect I will even be doing some post reviews at some point myself, to validate what's going on. Of course, that leads to having some kind of badge related to 'vetted by' status to provide some kind of stability to people who want that kind of thing.

Of course, plugins pushed out under the team banner (i.e. official plugins) will automagically have something special to indicate it.

OK, so let's go with the theory of post-review rather than pre-review. What should happen with beta plugins? Plugins that people want others to test prior to going live, that is - should they automatically just push them to the main repo, but perhaps with a 'beta' tag on them?