Wedge

OK, so I've spent most of my day thus far understanding WTF WordPress does. If I didn't already hate WordPress, I really hate it now.

What the fuck is the point of a publicly accessible API, that's in use every day, that doesn't have documentation?[1] That assumes, of course, I already had that information to hand, but no, a trawl through the source and eventually just doing a search on wordpress.org told me what I needed to start off with, the URL of the repository. Lots of Google searches and code searches ensued.

Of relevance, is http://markjaquith.wordpress.com/2009/12/14/excluding-your-plugin-or-theme-from-update-checks/ and as a bit more background, http://w-shadow.com/blog/2010/09/02/automatic-updates-for-any-plugin/ (I don't expect anyone to read these, they're pretty WP centric, but the point should be made that underscores the very concerns I have had here, that private plugin data could be submitted to WP's master servers)

Interestingly the performance aspect of dealing with all the requests[2] is ignored.

Anyway to recap. They consider it a problem that plugins could call home and ask for updates, and want an opt-out, whether that's for privacy or practicality,[3] and it would be nice to do it in a better form than having to write a several-line function to be called from a hook before doing an update.[4]

Now, several suggestions have been put forward in how this might be dealt with, including plugins specifying a 'home' repository but I think we have to do more than that.

The typical case is a plugin that will reside on Wedge.org itself in some fashion, and nowhere else, no mirrors, no private repositories etc. Since that's the default I see no reason to actually alter it, so plugins that are just bog standard off-the-main-site ones need do nothing. And come the daily check for updates, those should be requested.

The next case is a plugin that maintains a third party repository but is also distributed on the main site. In SMF's case, this is SimpleDesk, SimplePortal and others, projects that feel they are too big in size or scope to remain totally on the home site and form their own.

Now, in those cases, it's likely that they'll have updates ahead of the main site so the plugin can specify its own repository, but that it should not automatically use that; I think it should be opt-in to use third party repositories (unless you add them manually) and there are people who won't use plugins that aren't on the official site anyway, but if they opt in, it should use the third party repository in priority to the official site.

Then you have the case of plugins that might be available on third party sites, but that won't be on the main site for whatever reason. Again, I think the adding of details should be opt-in but the plugin itself needs to indicate an opt-out for the main site.

For example, there's no need for WedgeDesk to phone wedge.org for updates because it won't get any.

The last thing to note: if a plugin contacts a third party and a response is given for that plugin, it shouldn't phone wedge.org even if the opt-out isn't used. So if a plugin originally contacts a third party but the third party is defunct, it should query wedge.org for that plugin. If the opt-out of using wedge.org is specified, it should be made clear to the user that either they use the third party server or check manually.

It's tricky!

Heh just after I hit the post button, a separate thing occurred to me.

Instead of automating look-ups, we can indicate sources for plugins instead, and have an opt-out of updates for that plugin, and when opting-in or -out for updates for a plugin, it can indicate and sort out where the plugin should be queried for. That seems more practical to me, actually, because it gives users the control they want and doesn't seem to me to have any other problems.

1.	Go to http://api.wordpress.org/plugins/info/1.0/ and click on the link for "API Docs". I did, later, find some documentation on the API, on the blog of 'DD32' but that's another story.
2.	And by criminy there will be a lot of requests, as this happens every day or so from every outbound-calling WP install.
3.	And I just considered the privacy angle. There are practical angles too, such as modified updates that you wouldn't necessarily want to be notified about, but if you're doing that, you're aware of the implications of such.
4.	See the link to Mark Jaquith's blog, where he discusses doing that in WP. It's not pretty, and FWIW if Mark is saying it, it's probably the best there is for WP, I've encountered posts from him before. Note also that doing it from a hook implies the plugin is active, when it might not be.

Yeah, we need to do that, soon.

I just noticed it and thought I'd share. I didn't expect it to be greeted with mass enthusiasm, because it doesn't really work in our case, but I figured I'd share just in case.

Now you know why I made a more sane interface for them through the plugin manager :lol: And, yes, I did document the entire plugin manager's behaviour as far as managing plugins went because authors would need to use it. It's a biiiiiiig post.Better still, abstract it away. Mod authors should not need to understand what the mechanics are in order to use it. All they need to understand is what is needed to make a task, the system should deal with physical creation and management of that. The plugin manager in Wedge does this already, and I documented how it works from the user point of view but I'll just grab the content (it's already public, I'm just spotlighting the relevant bit)That's in our equivalent of package-info.xml. The plugin manager[1] adds the relevant row on enable, turns it off on disable, removes it entirely on uninstall. The mod author never has to worry or care about inserting a row, or cleaning up after themselves.


There is also a secondary subsystem in Wedge that is available to authors though not through this interface, whereby they can schedule future-dated one-off tasks to be carried out. Worth bearing in mind (and again, it's mentioned in the changelog, so it's not like I'm giving away any secrets)

1.	At the time the post was written it was still called the add-on manager.

The list of people who know and understand how to use the task scheduler is still in single digits, as far as I'm aware.

It also doesn't help that there's not a good, easy way to add scheduled tasks. (The only way to do it is a manual DB query during mod install, I did document it many months ago)

Still, there is a lesson to be learned and it's made me go back and think about other things too...

Works for me.I'm not fussed about smiley set,[1] though theme/skin would probably be better to keep out for reporting purposes.Timezone doesn't bother me, unless we want to do some kind of display of user timezones. Language, however, has other consequences, like when sending email templates, it actually tries to fetch the right one for the language of the user the email is going to.Offhand, I'm not sure where message_labels is evaluated in terms of how it figures out how to label a PM (given that it's essentially a rules filter)Not they're not. If you send someone a PM, do you really want to have to query their member rows, unserialize each one, increment, then update each row? If you send 10 people a PM, that's 11 queries. Now imagine sending a newsletter to each member via PM. As opposed to a single query that updates all of those things at once (which means only one table lock)Keeping the table lean is important, provided you don't end up compromising other things like above.The dump is from either mysqldump or phpMyAdmin (not sure which) which escapes everything, anything that's without quotes is one added manually somewhere.

It wasn't compatibility, SQLite and PGSQL got their own install SQL scripts.On top of that we were talking about using wesqlQuery with it too, which is probably why no-one did it, because it's hellishly complicated (and important to get right)It depends on your definition of strange. From my point of view, the majority of filesystems are strange :P I did consider avoiding the whole upload process entirely and forcing users to use FTP but that's not very nice, now, is it?

1.	Honestly, how many sites actually do the whole multi-smiley-set thing? Most people neither know nor care. But I don't have enough reason to remove that.

Technically, it's in loadMemberData where the join is. Hmm, lMD needs more branches than just minimal, normal, profile. Didn't we already talk about that before? :/The plugin management itself is pretty straightforward. It's all the crap that goes with it, like dealing with file permissions[1] and figuring out how the update process should work.

1.	Seriously, while I understand the principles and so on of the way Linux/Unix file permissions are done, the whole lot of having to use FTP to elevate permissions on most systems instead of allowing the PHP process to run as the right user is just so mindnumbingly broken...

Hmm, I think I found another bug, this time in wetem::layer. Just want to confirm I'm using it correctly or not as the case may be.

This one's from WedgeDesk.


It's a long story as to why that's a replace up in the first load call, but that's what it has to be for the time being until I fix other things. This is based against r1142, but I have something to add in a moment about r1143.

Anyway, my understanding is that I can dynamically create a layer through wetem::layer and have it positioned where I want in the list, and I want to add it dynamically based on a variable that I know to exist and be set correctly. Except that although the if() is executed, wetem::layer never adds ticket_replies as a layer before ticket_pageend, and do-replies is never added to the list.

I know I can work around it by declaring the layer up front in the main load call and then dynamically removing it if the relevant variable is empty, but that seems clumsy to me.

Also, r1143 will break any instance of array_insert; all places it was called (e.g. the template skeleton) relied on it modifying $array by reference but now it's returning a value - and wetem (amongst other places) isn't picking that up. I'll fix it tomorrow if you don't get to it first.