Wedge

(6 files, 2KB)

Revision: 1889
Author: arantor
Date: 01 February 2013 04:00:36
Message:
! Did I mention I hate the generic menu system and its strange handling of top level tabs? Well, this is what it took to fix the damn tabs in a fashion that makes sense. (Admin.php, ManageBans.php, language files: Admin, ManageBans)
----
Modified : /trunk/Sources/Admin.php
Modified : /trunk/Sources/ManageBans.php
Modified : /trunk/Themes/default/languages/Admin.english.php
Modified : /trunk/Themes/default/languages/Admin.french.php
Modified : /trunk/Themes/default/languages/ManageBans.english.php
Modified : /trunk/Themes/default/languages/ManageBans.french.php

Oh, that's hilarious.

That does pretty much mean the implied consent notice is sufficient. I think we'd actually be OK with implementing that in the core - since I *still* haven't seen any enforcement out of the ICO for *any* site.

Nao, what say you?

(10 files, 8KB)

Revision: 1884
Author: arantor
Date: 31 January 2013 17:26:56
Message:
+ Add ability to indicate maintenance mode will be required in plugins. (plugin-info.rng, ManagePlugins.php, ManagePlugins.template.php, Subs-Plugins.php, mana.css, ManagePlugins language file)
- Removed old sc/sesc legacy handling. There is no reason to accept a session id any other way. I haven't been able to break anything with doing this either. (wedge_api.php, Errors.php, ManageSearchEngines.php, Security.php, Subs.php)
----
Modified : /trunk/Sources/Errors.php
Modified : /trunk/Sources/ManagePlugins.php
Modified : /trunk/Sources/Security.php
Modified : /trunk/Sources/Subs-Plugins.php
Modified : /trunk/Sources/Subs.php
Modified : /trunk/Themes/default/ManagePlugins.template.php
Modified : /trunk/Themes/default/languages/ManagePlugins.english.php
Modified : /trunk/Themes/default/skins/mana.css
Modified : /trunk/other/plugin-info.rng
Modified : /trunk/other/tools/wedge_api.php


@ I didn't strictly *need* to do the sc/sesc change but it bugged me as it meant we were doing a lot of work for little benefit. The reason to preserve it - legacy - is no longer a reason, so let's just drop it and only support the more secure method we were really trying to use.

I get the feeling it is a nice idea but not actually worth the hassle. I remember having to help debug an Impact JS game a bit back that was compiled with Closure that didn't work any more, because there was a set-up involving (x - -k) or something in the original source that gets compressed to x--k which is of course no longer a valid expression.[1]

100 bytes is 100 bytes, sure, but at a massively increased debug and maintenance cycle? I would leave it alone personally.

1.	I only vaguely remember the circumstances, it was a 3rd party library that wasn't really designed to be minified too heavily.

You and I both want to believe that but in the end, the users are going to shout about it, and I'd rather avoid that because user shouting = Arantors having a sad face

Essentially this is about cases where users attempt to log in, fail, and we don't let them log in too many times.The complexity of the testcase is the key thing here. If it's just about setting a session on validation then logging in, that's about as easy as it gets. Anything more than that really depends on how hardened it has to be against brute forcing.Probably. Or more likely I'll find it, think WTF, remember that we discussed it, then swear at the search facility for a moment until I find this conversation.Display.php, lines 86-92...?robots.txt isn't an Apache tech, no. But not all prefetchers respect it, which brings me back to things in the headers (i.e. like FF used to do, hence the test for the X-Moz header) which can't be sifted out in robots.txt, but can in htaccess - if you're using Apache.

I was more asking about the mass upload aspect.

We still support IE8 with a vague nod at occasional IE7 support.