(split from New Rev comments)
Found the origin of the bug. Comment out the $current_action = 'moderate' line in Subs.php and it doesn't generate the error anymore... I think it's related to how I moved the moderation center to within the admin menu. Didn't look any further.
Posted: October 19th, 2011, 09:43 AM
I'm seeing FOUS effects in the admin area when dealing with the error log... Hadn't seen these in a while. Dunno if it's due to some bug in the new Opera. Can you tell me if you've seen any of these in Chrome?It's to make it easier for themes to add options, that are under admin control. There's no way for themes to add user options AFAIK without replacing some/all of the profile template.
There are plenty of options that should be in general options...
Fading delay between items for the news fader: NEWS area
Number of recent posts to display on board index: possibly elsewhere. That's in the info center right..? See below.
Show statistics on board index: --> I don't believe themes would modify the info center so much that this would kill layout...
Show latest member on board index: ditto (might be removed entirely)
Show group key on board index: ditto (should be removed as an option, and always shown.)
"Show who is viewing" --> this is an important feature, it should be enabled by default at the very least... (And the English description is confusing, too.)
Show last modification date on modified posts: if themes don't provide a field for that, then it just won't be shown... Otherwise, they'll provide for it, and make sure it's usable. This is definitely an option for POST settings.
Show view profile button under post: POST settings.
Show user avatars in message view: POST settings or AVATAR settings.
Show personal text in message view: POST settings.
Show gender images in message view: POST settings.
Hide post group titles for grouped members: POST settings or MEMBERGROUP settings.
Enable collapsible additional post options: general, post settings or something...
My conclusion: theme settings should only *contain settings that related to the theme itself (e.g. something like, "show the info center in the sidebar/main area"), not settings related to features that are built into Wedge* (e.g. personal_text has a field in the members table, so all themes are expected to be able to deal with it.)
What do you think...? As an added bonus, we get to have the options made searchable... This is all because yesterday I wasted 5 minutes trying to enable 'show group key' and the admin search refused to point me to it...
We should also rename 'Current Theme' to 'Current theme settings & options' or something. Yeah, I know, it's a bit too long...Admin > Current Theme makes some modicum of sense, but not a lot - though it's a world better than how unobvious theme settings are to find normally.
(It's interesting that Opera is telling me 'unobvious' is not a valid word... I always thought it was. A dictionary gives me these antonyms for obvious: ambiguous, indefinite, obscure, unclear, vague. Hmm, that's very close to what we'd use in French -- ambigu, indéfini, obscur, flou/pas clair, vague.)
If they're actual theme settings, I understand they need to be together in one place, but if they're not logically theme settings per se, they should be elsewhere. At worst, we could add 'aliases/shortcuts' to the correct setting pages in a main page if needed.It's a theme option because not all themes provide it.
It's inside the info center... Especially now that InfoCenter is its own template, I don't see how/why themes should delete the option. Additionally -- it's up to the theme to decide what to do. For instance, if I had an admin setting to choose the default sidebar position (left/right), I'd expect the theme to either follow it, or just don't show a sidebar on the left or right (e.g. show it at the bottom). It's a bad example but I hope you get my point...Seriously tempted to move that back out into being a plugin anyway because partly not all themes provide it and partly because so many people want it 'ordered how they want, not just alphabetic', and I think it would be a stretch too far to make core with that in mind. It's not like it's tough to expand any more or anything.
I don't know... :-/
I suppose you're right in that sense. Like, people might want to sort membergroups by color brightness... :lol:Nice. I spent the rest of my evening trying to score the one remaining achievement I had for Monkey Island II on Steam (complete the game in under 3 hours, just finished with 30 mins to spare), so I haven't looked at the commit yet.
I hope you used a walkthrough for that :P It's easier to get below 3 hours that way.
Don't have Steam though... I only have MI2 on my iPod and I don't think it has achievement lists :P Arrr... How appropriate anyway, I play like a cow!Uncaching on updateMemberData() means doing it on many, many user actions... Might as well not cache anything
Is there really a lot of places that call updateMemberData?
Yeah, pretty much... Over 60 times. And the cache would be updated even if 'id_group/additional_groups' isn't updated, which isn't too great IMNSHO.I'll update it if it becomes necessary but given how there haven't been updates for a while and it's one of those things that generally 'just works', it should be OK to fix up now.
Sure. Do you want me to get started on it maybe...? Or would you rather do it? It's not exciting work :P
Heck, technically I thought you were planning to have a minified version of the file... (Maybe we could move Class-SFTP.php to the wip folder, and include the minified version in Sources. No one has to know about the problems it had :P)Hmm, we should probably test that. It's likely I'm worrying about nothing but I'd rather that and be proven wrong than to be bitten by it later.
Sure, but I'd rather know why SMF/Wedge is using \n when it could be using br in most places :PIn that case, hmmm... How do we do that? Just a simple if (isset($_GET['xml'])) will do...?
Testing for $_GET['xml'] is good but it doesn't automagically do that for the feeds IIRC. But if we had the feeds set that too (if they don't already), then it's a no-brainer.
I'd rather not have ';xml' on any URL that is likely to be reused by someone, reposted on a forum, etc. We can just add a special || action == 'feed' anyway ;)