Wedge

Ah, The Rocky Horror Picture Show.

Watching the movie is fun, but the live version is so much funnier, assuming you've been/are going with a group of people who understand the culture and have no qualms whatsoever about adding your own dialogue at the proper time.

This is, for example, the opening song. Typical additions added in italics. It's NSFW like most of the rest of this show. Spoiler for consideration.


I'll spare you the rest of the lyrics, but needless to say there's a new addition every few lines or so.

Of course, when performed live, there's always the opportunity for imagination. At one point, bad stuff has happened, and the narrator breaks out, "But what, exactly, was over?" As well as "What further indignities were they to be subjected to?"

Depending on who the narrator is, all *kinds* of amusing comments come from the theatregoers. My particularly memory of the above was with Michael Aspel as the narrator. What was over? Cue: "Your career!" from the crowd. Further indignities? "Antiques Roadshow!"

You have to understand, the humour in RHPS is basically English humour, even though the cast isn't what you'd call English.

Well, it's not that it's too complicated. I can't see how it's any more or less complicated that FB Connect, frankly - however it's sliced, it's still the same basic process: throw some data at an external source and use that to authenticate, creating a user account if necessary.

I'm inclined to agree about PMs, but memberlist I really don't have a problem with it being pushed to a plugin. If it isn't pushed to a plugin, it needs an overhaul in terms of what's displayed and possibly the general look of it.

Revision: 1109
Author: arantor
Date: 11:41:34, 14 October 2011
Message:
! No need to update the calendar_updated variable if a user changes their DOB; this is done by the birthday plugin all on its own through the change_member_data hook. (Profile.php)
! Add a hook for deleting topics en masse. (Note that merely moving to the recycle bin, as it stands, will not trigger the hook - but then it's not supposed to. This hook is for clearing out any topic-related data on topic deletion.) (ManagePlugins.php, RemoveTopic.php)
----
Modified : /trunk/Sources/ManagePlugins.php
Modified : /trunk/Sources/Profile.php
Modified : /trunk/Sources/RemoveTopic.php

Yeah, it's all going to go into the calendar plugin. Essentially a case of throwing divine lightning at them and letting $deity sort it all out :D

Going back a few posts, the question came up about plugins and turning originally core features into plugins.

Now, PMs and the memberlist were candidates (and of course the calendar will be), but I'm wondering about the print-page option and OpenID.

I know we talked about OpenID before, but I'm just wondering how important it really is; it's not like a lot of sites use OpenID - how many sites do you know that allow you to sign in with it?[1]

In short, is it worth the effort required to make it a plugin?

1.

It should be no surprise to note that it's primarily technical sites. SourceForge, StackOverflow and all its related sites and LiveJournal are the only consumers I actually know of outside of SMF. MyOpenID and LJ are the only providers I know of. Then you have PHPClasses and family that adopted the OpenID protocol but only from their own server, defeating the point.

OK, let's recap.

.zip vs .tar.gz.
There are more rugged solutions than read_zip_data() out there, one of which is ZipArchive. It's not the only solution, however, and it won't be that hard to find such a solution.

My theory of using only one file type in general just means that it simplifies the process and the code, and minimises the overall number of hassles people have, IMHO.

Should uploading plugins from your computer be a separate page to downloading from a plugin server?
I'm thinking that getting from a plugin server would be a 'Find' page, and uploading from your computer would be an 'Upload' page, as Plugins > Find and Plugins > Upload.

Should a plugin be able to list the plugin server or servers where it can be found?
This one is totally dependent on the expected prevalence of plugin servers. There are worryingly few for SMF, which has pretty much always amounted to people running their own for large projects. I think it's still in single digits.

If there's a (relatively easy) way to specify a plugin server it would help matters, but the more I think about it, the more I think a plugin shouldn't specify its home as a target for lookups, not directly. (As in: we can't expect plugin authors to expressly put in the Wedge plugin server generally, but the plugin system can query all the servers it knows for updates)


I think I almost have to just go away and start building before I can really answer some of these questions, that I won't answer them ahead of time.

(Just a quick note, I took a look today at how WP handles plugin updates on the fly. Interestingly, it's practically the same as I'd outlined Wedge would have to be doing, that the download occurs, the old plugin is disabled, the new one enabled, and the old plugin then deleted. I still think the user should perform those steps, though, rather than entirely automating it. I don't know. Might have to experiment with how well that works out for us.)

Oh, and I'm going to have to write a plugin server of my own before long, as I've always (always!) kept my webserver's folder as a copy of the files, rather than directly hosting SVN files. In this case, C:/Dev/wedge_plugins currently holds all my plugins as a SVN tree, but C:/Dev/public_html/smf/wedge/ is where my testing site is... would be nice to have a solution for grabbing plugins that was quicker than just copying folders (and, as a side matter, didn't include .svn folders)

foreach ($array as $k => &$v)

$k and $v are still set after the loop finishes, and $v is still a reference. Normally it isn't too much of a problem because it's within only the scope of the current function, which means at the end of the function, it's going to fall out of scope and becomes available for the garbage collector to free up.

If $v happens to be a reference to something that might remain in scope after the function ends, it might still be GC'd, but then you garbage collect something that wasn't supposed to be, and boom, segfault.

References are voodoo when you put then inside recursion. They're powerful but dangerous if you're not careful.

It is a bit more than 10K but a decent amount of that is language strings.

It is also interesting to note that I've rewritten the way birthdays are cached, and a few other things, which is why it bulked out a bit.

Using <URL> is fine with me :)