Technical shit

1) Add gzip as option (some autodetect - most servers run Linux)
2) Rather try to connect to SVN or even open a new repo on bzr or mercure and try to pull (and auto commit?) there. I feel you want that kind of functionality and you're never gonna get it if you build it yourself.
3) Rather use the README.html that a coder can provide with his plugin. A changelog and more could be provided there. Write a generator/editor for that file. The idea is that the README.html is closer to the plugin coder. If only the coder knew how to use it. A long time ago I proposed an XML file for certain (plugin) settings.
4) See 3
5) YES and perhaps a special area in forums only for announcement of plugins.
6) I'd like a repo for skins as well.
7) Please do, but it's not my priority.

BOPIT rocks. It will rock even more if you could turn it into an auto-upgrader. Keep up the good work and I may consider donating to Kiva again

Oh crap you've been drinking FG kool-aid

Automatically shoving crap down my installation is a great way to get cut off at the knees. Let the user decide if they need/want to upgrade! Information is the key there eh? Meaning if you tell me something can be upgraded and you tell me why then I might. But if you force an upgrade on me I'll dump bopit like a ... like a thing you would dump quickly.

I think Afwas is both on to something and revisiting something long gone: a file the plugin author can update as part of the zip. The problem is that means bopit has to always go look to see if new stuff is out there. Maybe a combination method will be cool? Like an XML file that I include in my pathetic excuse for plugins, then a trigger that I have to pull at bopit that tells bopit "go grab that zip and read the xml file" so that bopit can tell users the world over "udpate FOO because of BAR or die you daughterless bastard".

Skins are a waste of time. In the entire life of b2evo how many skins have been updated as a percentage of skins that have been released? Plus it's all a waste of time given how b2evo thinks it owns the widgets. More FG kool-aid eh?

My last thought here: a checkbox for "this is security stuff" is a good idea. Adding any more layers than "security" is silly because you already have a place where I can say why the upgrade might matter to each user.

Oh wait my other last thought is why worry about the plugins page? Would you refresh the date stamp to move an old post to the top of the list? Would submitting there be required, and if so why not move bopit there entirely? I do the plugins page once and never look back. If I have cause to update then I visit bopit and share my reason with the world.

@¥åßßå: Okay that makes more sense. The user triggers automagically putting the new files on their server - if their server can handle it. Smart!

BTW I kinda thought "reply to {{name}} would go inline. I'll find out in a moment eh?

Moving the mechanics of upgrading into my webspace would be cool. It's not a big issue to me that I have to visit another web page though. Like, doing the upgrade itself then zipping it and replacing it on my server is more work than going to bopit and editing a post.

Anyway to me it's already as cool as it needs to be so I'll just butt out until I finish this silly little project of mine. Not gonna do a "users manager" or a "groups manager" because wasting keyboard time on it is counter-productive at this point.

It does. I believe what happened was that "preview" lost track of the fact that I was replying to Afwas. My reply followed his post only because his was the last made. But it didn't indent is the thing.

Life is good. Building a custom hook now. Why is it every time I go to add a new bit to my overly large plugin I realize I don't have enough bits stored in the tables it made?

EdB if you didn't know. Don't recall why formica but there you go. Skins get customized. Not upgraded. Francois claimed the last time was the last time they'll need a gross overhaul, so why bother? I mean, if "Not having that hinders upgrade" and we allegedly won't have to upgrade skins again where is the gain?

Like someone finds something "wrong" in the skin they chose, so they figure out how to fix it or ask and get told how to fix it. Done. Plugins are very different. The plugin author is generally the one who will "change the guts". So most users will either ask for features instead of try to hack them in on their own, or give up on the plugin. It's the feature creep (or enhancements if you prefer) that make bopit so cool for plugins.

My useless opinion eh? I still find no value in the subjegation of skinners to the almighty will of the core. Stupid damned calendar has no business existing let alone ALWAYS being part of a skin!

Friend if you see a need to improve it then go for it, but yeah keep it simple. Green is good, yellow is pay attention, red is you need this. Adding shades of green and blue is just complicating the heck out of a good tool. And *everything* except a gross failure correction or a security issue should be yellow, where "gross failure correction" is a bug fix that the average user with an average installation might experience.

So a new feature like more settings or a language pack is yellow. Recently I had to update my silly little "forumlatest" plugin. Gross fail, but only on initial installation. So to me that one would be yellow because a "user" doesn't exist until they actually use the thing. Peeps what didn't experience the bug won't experience the benefit is what I mean.

Something I noticed in my BOPIT that reminded me that I don't like: it mixes uninstalled plugins with the ones the user actually has. So if you're going to tinker with this I suggest you consider a top table of bits the user has (installed/uploaded/whatever) and a second table of plugins the user doesn't have. That way I could see at a glance what I need to consider updating, and scroll down if I'm looking for a plugin I might need.

Maybe add a field when plugin authors are adding to BOPIT for the short description and use that in the "reason" column?

it is fiine.. dont play with it