Wedge

I'm thinking ZipArchive ;)

So, this is one of the things I've been thinking about lately, is how to make plugin servers work, on a technical level.

This is going to be something of a stream of consciousness rather than a focused discussion, to start with. It's more about trying to make sense of all my thoughts, and if you have anything to add, please do.

Let's look at what SMF has (not what it actually uses). It's all in the Packages > Download Packages page.

Up front that's stupid. You click a page called Download, so that you can upload something. It's almost as backward as the logic of clicking a Start Button to shut down, though at least they have the argument of 'starting the shutdown process'.

Idiot question of the day... should uploading plugins from your computer be a separate page to downloading from a plugin server? Gut instinct says yes, it should, because they're totally different options and processes.

That also leads in nicely to something Dragooon mentioned, about plugins having an 'app storefront' kind of deal. I've mentioned before that I'd like to be able to support the environment where creators can publish paid plugins, and still make use of something like the package server facility, currently not possible in SMF. (Incidentally I was thinking about that almost 18 months ago, if not further back)

Hmm. Seems to me that the actual process of getting a list of plugins is at least as dependent on what interface to use to display, as anything else. SMF provides the ability to accept a list of plugins, and/or a list of categories, wherein you can browse categories. Thing is, that most people don't realise, is that you can also segment the package server list by category so you only need serve a list of what categories there are, then what's in each one - as opposed to the behemoth served by SMF currently that actually breaks some installs with low memory limits.

Then again, that's when you have a public list. If the list is potentially private or semi private, or in any way filterable, it needs to be accommodated by the server, not the client, which means that just serving a packages.xml type file isn't an answer. Hmm. I'm sensing that you'd make a request on a given page much you do with feeds, and make it essentially similar to a RESTful style implementation, that the URL http://example.com/forum/index.php?action=plugins would provide a list of plugins available for download, and adding ;cat=x would filter the list by the specified category. Of course, that would be a detail provided by the server.

I'm a little wary of providing something that amounts to a storefront structure but I'm OK with the architecture providing lists of what's available and so on, especially as for anything that's premium, you'd have to be a member of their site anyway and have access to the relevant downloads.

Hmm. Should a plugin be able to list the plugin server or servers where it can be found?

Also, what exactly is the process for plugins requesting updates? I'm sensing it would be a daily process job, where the system goes to all the plugin servers it knows, with whatever credentials it has, and supplies a list of plugins. (Active plugins, all plugins?) The server itself should be doing the work on filtering down plugins, not the client. Though, if the plugin itself indicates a server or servers where it can be found, presumably only those need to be queried?

One last thing. Do we really need to support both .zip and .tar.gz? Gut instinct says no, just zip will cover the bulk of what's actually needed? (even if it does provide a shade of inconvenience for those who use *nix / OS X that write plugins... which is going to be a limited enough group anyway?)

Nothing. Just that there's the risk of gradually moving towards it.

I like all the ones you posted earlier; but I have no specific preference or bias about any individual one.

There's no real hurry, just that it's something that needs to be fixed prior to release.The only guaranteed ones are <, > and & - plus apostrophes and quote marks if we leave ENT_QUOTES in (as opposed to ENT_COMPAT)

It is a bit ugly, but I don't really see an alternative, other than leaving everything how it is currently.

That certainly works for the building of arrays for caching, but += is suitable (with aforementioned caveat) for loading language strings from cache.No. The change log was updated by hand with more than one commit because a previous committer had forgotten to update it.

I'm also thinking this might be useful for simple plugins to extend the admin search interface. I find it stupid that I have to declare a function just to put one line in it.

e.g.


Hmm. It's time for bed, I'll sleep on it and see how I feel about it in the morning as like the above it has to be stored somewhere, you can't just keep hammering the XML on loading the admin (though it's marginally easier on searching because it's not every-single-admin-page the way the main admin areas list is.

OK, so I tackled that, and have refined the structure into something usable (and cut the code down in various places)

Right now, it's just a case of taking a machete to the core code to strip it of birthdays stuff, so I can put it in to the plugin. (In other news, there's various ways that things need to be extensible in the calendar that currently aren't. There's no reason, for example, why any arbitrary events shouldn't be able to be added to the calendar. I could envisage it in WD for example for ticket deadlines to be embedded into the calendar.)

But if I don't do things as plugins, I can see them sitting there as red-headed stepchildren, and no-one wants that.

Also, please note that the little thing of leaving a cake image in the user's profile if it's their birthday, that probably should stay core for the time being.

I really don't want to add a hook that can cope with that, that would be inappropriate IMO. (Or we can remove it entirely, not fussed, and have something add to the user's profile underneath or similar. Don't really mind.)

Mind you... when I spent a little while looking last night for a suitable cake image, I found the image used in SMF, and I don't think it's actually compliant with the licence for it... it actually says 'free for desktop use', nothing about distributing it. Though I would hope they asked about it.

Hmm. Do I commit this or do I leave it just removed while I work on things? (Using the power of diff to see the code itself, at least what I haven't just copied over to the new plugin. It does have to do other things that the original code doesn't)

That's a sure sign I haven't had enough tea, if I have to ask such philosophical questions.

Meh, committed. If I broke anything (which I don't think I did) it's a revert away. Meantime, I'll crack on with the plugin.