Wedge

And I rewrote so much of your code, it feels like Aeva Media all over again, don't you think..? I hope you're not upset by that. The fact that your code both times managed to draw my attention long enough to make it me work weeks on it (even years, in the case of SMG), should be enough, eh eh. I mean, I suck at 'starting new features', but you're good at that, and I rock when it comes to making them shine :P

Still, there's at least one of your WIPs that we need to determine whether it makes it into the main code: properly saving the avatar and member ID... Currently, Wedge uses a modified version of the original code, that dates the member data and loads it 'manually', but it would definitely benefit from taking the member ID from a dedicated field in the notifications table, which your WIP had, and Wedge doesn't (for now). I've always wondered whether I should take your patch and try to put it into the Wedge codebase, or if I should wait for you to take the Wedge codebase (which hopefully on your side has the very code we're looking for), and trim the elements that are no longer necessary once your code is taken into account...
What do you think..?

Since we're planning to release a public alpha this spring (yeah, one can always hope :P), it would be nice to have the notification code 100% complete before we do that, so that people can start writing notif plugins if they want ;)I don't use Facebook (much), so I wouldn't want it core, and generally anything that interfaces deeply with another third party is a no-no for core, but as a plugin it'd be cool, yeah!

Just like I still have that 100-year old to-do entry, "allow reposting thoughts to my Facebook/Twitter feed"... :lol:

rev 2115
(41 files, 15kb)

* Updated parse_bbc() params to look like this: message, then type, then options array. Among the options, 'parse_type' is thus removed, 'parse_tags' becomes 'tags', and 'owner' becomes 'user'. Both type and options are optional, the first will fall back to 'generic' (should it be 'post'..?), the second to the default options. (41 files)

! The Welcome parse_bbc calls had their user param set to 'id_member', rather than $row['id_member']. (Welcome.php)

* The Display parse_bbc, out of all parse_bbc calls, is one that 'missed' setting a 'post' type. Lulz. (Display.php)

! SSI had another missing type, as well as an incorrect option array (it just had a string, without a key.) (SSI.php)

! unparsed_equals handler didn't use the rewritten parse_bbc format. Hopefully I didn't mess it up. Wondering if it's worth transmitting the 'parent' parse type to children, but my guts say it is... (Subs-BBC.php)

Still, as far as "half-season epic fail" go, Doctor Who has nothing against the last few episodes of Once Upon a Time... :^^;: Now that was some failure. They pretty much jumped the shark with the Pinocchio episode... Hopefully the writers were drunk, or something.

Well, my gut says that most parse_bbc calls from plugins will relate to a post, so it's best to make their life easier. I'm not documenting the tweak in the function header, only in the place where I'm doing the permutation, so if they don't know about it, it's not a problem. ;)

Done with the conversions, 40 files total. All 'parse_type' are now a parameter, all 'owner' are 'user', and all 'parse_tags' (only a couple..) are 'tags'.
Will commit later tonight; I'll be offline for the evening, unfortunately, and already late... :-/
Plus, I don't want to rush, I'll check them manually again.

Ah, yes, that was one of the words used by Pete in the language files, if I'm not mistaken (along with Infraction, Sanction and Warning -- the latter referring, apparently, to the action of 'sending a sanction notification', but I'm not sure at this point, because some strings seem to see it as a synonym to 'infraction'... I told you, I'm lost!)

I'm fine with Penalty, or anything else really, anything that makes Pete happy ;)

Yep, I only figured out after I changed it ;)Yes, but as I explained somewhere else, simple function () {} declarations don't require a semicolon, only var func = function () {}; (i.e. anonymous functions, or closures, or whatever) require one. This isn't related to Packer in itself, it's what JavaScript engines expect to see when everything is tightly packed. Either a semicolon, or a linebreak. Packer does semicolons, so we do semicolons. Plus, semicolons are safer in the long run -- there are instances where using linebreaks instead of semicolons will generate bugs (although they're clearly documented.)


Considering it's stored as linebreak-separated variables, why not just do an explode() on these..? Or even get rid of array_filter and array_map, as I don't see many reasons for this variable to be modified by anything else than Wedge..? And we could do the checking at save time in ModifyPostEditorSettings.

Do you see any uses for disemvowel and scramble functions? Maybe just copying their single-line contents into the main codepath would be enough? I'm not worried about disemvowel(), but scramble() might conflict with other functions with the same name. You never know -- adding an encryption library, or something like that...?

I don't know if it's a bug or something I understood incorrectly, but this infraction point system... When I'm giving someone a sanction, I find myself with having to determine a number of points to give... Why should I, when I can just select a list of pre-defined sanctions, such as hiding the signature...? Or maybe it's admin-only and I should look at how it works for mods?

Done with the checks. Overall, great work! :)

Yes, parse_type is definitely buggy; it should be 'type', as per your parse_bbc code.

Tell you what... I'm seeing that most of the parse_bbc calls (about 90+ out of ~125) include a parse_type, which I think is good.
I'm thinking that, given how we'd both obviously like it to become a second nature when calling parse_bbc, we should have it outside of the array...

parse_bbc($message, $type, array(...)) or parse_bbc($message, null, array(...)) if no type is defined, which would be illogical...

There are about 30 calls with an owner ID in them, so it's about a quarter of all calls, which isn't enough to justify adding a specific parameter for user ID. I would, however, suggest looking into renaming it to 'user' or just 'u' (as in profiles), probably 'user' is better for readability; 'owner' is fine, too, but it's one extra character, and apart from thoughts and profiles, it's not a terminology that's used a lot, at least less than 'member' or 'user'.

Thoughts..? :^^;:

(I'm volunteering to change parse_type to the parameter style if you don't mind, and if you accept the change, of course.)

rev 2110
(3 files, 3kb)

! Fixed JavaScript errors in Thought threads, when at least one of the thoughts in the thread was deleted. Wedge was showing an action menu for these... (Thoughts.template.php)

* Finished translation... Phew! I hope I didn't forget anything. Also fixed a typo in the English version. (ManageInfractions.english.php, ManageInfractions.french.php)