lol, it's cool :-p

By the way, I'm going to sleep before editing actually works yet, so don't be disappointed when nothing happens! :D

Where, well, honestly i don't think old versions are that important so i'm sure you could put it above those, or somewhere.
It's not really that important anyway, most plugins don't have much to show, i just thought about the few which add hud related stuff.

As for description getting 'misused to provide instructions', i don't see anything much wrong with that, in fact a separate place for it could be useful too :P
I mean if plugins have their own page, using it just for a list of old versions seems rather a waste, might as well put other useful information there.
But it is not needed that much.

Instructions should come in a ReadMe file, not on an overview page. I'll see about adding a small gallery, (like 3 parallel screenshots right before the version list) after I get editing and adding managers working, and then we can see how it looks.

Why exactly? The most accessible place is best.
I don't really mind if it's not there tho.

I figure you don't need instructions unless you've downloaded and are using the plugin, in which case the ReadMe is probably the most accessible place...

Changes:
*Plugin managers can now edit their plugins

maq: Sometimes the old versions are kinda nice to have; I've had some plugins where the most recent version wouldn't work properly on my hardware, but the version one or two back worked just fine. I think it's just nice to have an index of them.

Also, we ought to be getting this out there and letting people know that they can upload their plugins at VOUPR, so we can get a larger collection up there :-)

Sorry, I've worked on too many open source products not to be obsessed with the keep-everything mentality. And the versions will actually serve some purpose other than that. To simplify plugin maintainers jobs, I was thinking each version of a plugin would include a script to upgrade user settings, (if the format has changed at all) just from the last version, and the auto-updater would handle sequentially running each update for you.

As for getting people to start using it, I might make a post in the general forum once I've got my to-do list finished up, but right now it is still very much in testing. In fact, if you visit at the right time, you can probably see me periodically screwing up and fixing pages with each successive save. ;-)

To-do list:
*Manager addition/removal
*Links box
*Full descriptions
*Try screenshots

I'm not saying you shouldn't have old versions, just that they don't need to be on top of the page :)

As for updating settings format, unless everyone uses the updated one would need to have plugin itself run that anyway, which is not much of an issue.
There are things automatic updater would be good for but this isn't that one of more important ones.

Good thing would be some api to upload stuff (tho i expect one could easily enough do so as is), packaging things up gets annoying after a awhile and if i ever start writing anything i'll likely make some automatic deploy script anyway. (was intending to make one before too but never got to it)

Hmm, that's an interesting idea, and if you want to write it I'll try my best to provide whatever kind of API you're looking for. I have to admit I'm not very knowledgeable about how HTTP POST form submissions work, but I would assume it can be done by Python's urllib module. If that works, would that fulfill your needs?

As for the auto-uploader, you would still have to enter version number and changelog so the only thing I could see it saving time on is compressing the plugin folder and removing the user data folder, I guess. What were you envisioning it doing?

Changes:
*Plugin managers can now add and remove themselves and other managers

I meant just something for me really, pull from svn, zip and put version number in name, upload to ftp/website.
Doing it manually gets old fast. Especially if you are like me and have to do a few minor bug fixes after v1.0 ;)

Oh, the file doesn't need to be named anything in particular if that saves you any time. When it's uploaded it gets automatically renamed to "<pluginname>-<versionstring>.zip" and placed it in the downloads folder.

Changes:
*Plugin managers may now upload up to three screenshots per plugin
*A screenshots box will now show up on each plugin's page if any screenshots have been uploaded

Edit: I just moved the site to http://calder.byethost8.com/voplugins/ after luckily running into horror stories about 000webhost before it was too late!

Changes:
*Plugin managers may now add important links (can be website, email, wiki page, or thread)
*Links now appear (for plugins that have them) below the info-box

This is opt-in, right? Because I'd like to decline having TCS listed anywhere near or on that site and would be pretty upset if you went ahead and uploaded it there without my permission.

Not to knock your project, but it doesn't look like you're willing to put forth the resources to make it succeed and I'd rather not have my plugins languishing there.

(I'm also against having it listed on a site with an acronym that's too close to VPR for comfort, but that's a fairly minor point)

This is opt-in, right? Because I'd like to decline having TCS listed anywhere near or on that site and would be pretty upset if you went ahead and uploaded it there without my permission.
I'm not sure I understand your sentiments. You offer it for free in one location, so what's wrong with placing it in another centralized and dedicated location where it will be easier for people to find?

Not to knock your project, but it doesn't look like you're willing to put forth the resources to make it succeed and I'd rather not have my plugins languishing there.
Thanks for the encouragement. I've written 2,500 lines of code in one week in the hopes that it will be useful to the community, and because I haven't bought a domain name or paid hosting yet you refuse to use it? This is also why I haven't prematurely spent a bunch of money; if people aren't going to use this then I'm not going to waste money on an unused domain name and hosting package.

(I'm also against having it listed on a site with an acronym that's too close to VPR for comfort, but that's a fairly minor point)
Uhm... Ok. That's just a little sad.

I'm not sure if you read the thread title before clicking on it, but the "Early Test" part might help explain a few of your woes. Once I've finished up the last few features and everything has been extensively tested then I'll look into a more permanent hosting solution and transfer everything to that. Until then, comments and suggestions are helpful but preemptive incensed complaints are a just a bit rude.

Anyway, thanks to everyone else for what have thus-far been very constructive suggestions.

Changes:
*Added 'Remember me' option to login page

I will be performing a password reset once I've added a change password form to the Settings page. This is to switch all passwords in the database over to MD5 hash so it is statistically impossible to get a password from the stored entry. Right now, I'm using the basic MySQL PASSWORD() function to hash passwords, but it's not compatible with cookie storage, hence the switch to MD5. Anyway, if you can't log in tomorrow then try entering six spaces as your password and changing it back through the settings page once you've logged on.

So, Person, it's pretty abundantly clear that your acronym is a bad choice (as I pointed out earlier). Why don't you man up and admit you were wrong, and change it before it's too late, eh?

Lol, anyone who can't distinguish between a the pronunciation o "voo-pur" (as skelbley pointed out) and "vy-per" probably shouldn't be playing a T rated game. Besides that, anyone who cares shouldn't be either.

That said, I'm still open to suggestions, but the only thing you've given me is PMS, and that's not going to work for multiple reasons. What would you seriously call it?

-Calder

EDIT: Passwords have now been migrated to MD5 hashes. Please log in and change your password when you have time.