Wedge

Anyone else..?

I didn't test before committing but iirc the reason for the bug was obvious (a theme removal collateral) and the fix was crystal clear. I'm curious as to whether I did another last minute blunder or you did. :P

You should post screenshots of your latter errors.

Tipping @TE.

wedge_* was the old name. I suppose I renamed the keys while you were translating the language file, so you missed it maybe..?

Well, or maybe it's time for me to get started on that automatic DB update script... :P

Something like, in index.php, if ($db_version < 123) update_database();, and then increase that integer by one each time I'm doing a database change... Then, in that update_database() function, I'd simply go through all tests geared towards $db_version < 123, and call the database update accordingly every time.
That's how I have it in my mind, but I couldn't bother with writing the whole damn thing.

Okay, I've reverted the files here because there's no point in storing more variables I'll never be using (and a visit = a variable for life... I'll probably need to clean up the DB), but I'll still need to determine whether I add one or two columns.

hey = 'not,pm' indicates both the notifications button and pm button should be orange.
Or,
hey_not = 1 (bit) indicates the notifications button should be orange.
hey_pm = 1 (bit) indicates the pm button should be orange.

First solution is easier for plugins to add more choices without having to add more database columns. (Just do an explode, then array_merge or array_diff, then implode.) Second solution takes a bit less space in the DB, and will make it easier to mass-update the rows (multiple recipients for pm, etc.)

Second, I guess..?

I want to make that table shorteeeeeeeeeeeeeeeeeer...... >_<
Same goes for the topic and message tables, of course... Oh well, they're not as aggravated as this one, really.

Bed time!

[Commit revision 9de68b7]
Author: Nao
Date: Wed, 12 Feb 2014 23:33:24 +0100
Stats: 3 files changed; +4 (insertions), -3 (deletions)

• Added a 'style' variable to admin setting lists. It will basically allow you to customize the <dl> that encloses your setting. I needed it in one place, but I suspect it might be helpful in other occasions. (Admin.template.php)
• Fixed select box drop downs being cut off in membergroup badge settings. Not my bug. (ManageMembergroups.php)
• Fixed invalid HTML. Not my bug. (ManageMembergroups.template.php)

---

[Commit revision af2d910]
Author: Nao
Date: Wed, 12 Feb 2014 23:45:04 +0100
Stats: 1 file changed; +11 (insertions), -13 (deletions)

• Fixed badges being shown after another badge even when set to "show only when no other badge is shown". This was due to $user_profile[$id]['badges'] being tested against in a loop, when at this point it was *explicitly* empty. $badges was the actual target of that test. Not my bug. (Load.php)

- First issue: my bad, I didn't look into it enough. It's all due to an intermediary <dl class="settings"> which has an overflow set to hidden. Hmm... Honestly, I can't remember why it's overflow: hidden at all, it might be tempting to just remove that rule. And, maybe, push the overflow: hidden to a higher level...

- The fix was uploaded here, and it didn't work (normally the post badges are also hidden if another badge is in there), but I think that's still the one, so... it's probably just something I forgot to fix in another place, too. I'm busy IRL right now, so that'll have to wait a bit.

The first problem is a common issue with absolute positioning and z-index stacking.
Basically, there are two ways of fixing it. The first isn't possible because it involves removing positioning from sortable elements, which completely breaks the feature. Uh. The second implies moving the select box out of the current flow, for instance by putting its HTML at the very bottom of the page, outside of the #wedge div, etc. This means it gets its own z-index stack, and will correctly show up everywhere (see alert popups, for instance.)
Unfortunately, doing this has a MAJOR problem: it forces me to absolutely position the select box dropdown in pixels from the start of the screen, so if the select box ever changes its position (e.g. hardware scrolling when opening a hidden sidebar, or doing any kind of animation such as showing/hiding the header) will not update the dropdown's position, meaning it will, quite simply, stay where it was, and show up in silly places.
I tried doing that a few times in the past, and always gave up.
Another solution could be to change the way the sortable list is shown... For instance, I could show the current setting with a button next to it (change), and clicking it could open a popup when you can choose your preference. That's pretty much a cop-out, and a usability nightmare I'd say.

I don't know what to say, or what to do... What do you think?

As for the second problem, I'll look into it.

Have you tried using the Purge Cache menu option after changing an option..?

Well, I don't know, but I've repeatedly said it.
I guess it should be mentioned in the Pretty URLs page itself, but it isn't the case.
That's mostly because /install used to be a folder where one was supposed to move all files to the root. Since this is no longer necessary, I tend to dismiss the fact that you still need to move some of the files to the root, if you want all features.What URL is being shown in your address bar when it shows a 404..?Hmm, can't find anything at fault here. What Apache version..? (Admin > Server > phpinfo)