Wedge

I personally prefer stylings but on the flip side, I'm happy to bow to the court of vocal majority if that's preferred term on it. And, fair enough, it IS, really, more common. That said, our 'skins' are more flexible than most, I think.I thought we were going to go with add-ons? :P

You know as well as I do that our users will tend to disagree anyway, and will call them themes and mods, because they're familiar terms.

Revision: 850
Author: arantor
Date: 11:58:15, 11 July 2011
Message:
! Move the IM fields into custom field templates. While there are slight changes to formatting, it *should* work out OK; I tested using the newer links and still got the information I should have had... (ManageSettings.php, ManageSettings.english.php, Admin.template.php, facebook.png, steam.png, twitter.png)

@todo: Add a couple more fields (PSN, XBox Live), remove the existing fields.
----
Modified : /trunk/Sources/ManageSettings.php
Modified : /trunk/Themes/default/Admin.template.php
Added : /trunk/Themes/default/images/facebook.png
Added : /trunk/Themes/default/images/steam.png
Added : /trunk/Themes/default/images/twitter.png
Modified : /trunk/Themes/default/languages/ManageSettings.english.php

Nao likes garlic sausage, though!

(as for me, I can't currently recall trying it, but to be fair, I've spent virtually the entire day sat in front of a Wii playing the Lego games. Numbs the brain somewhat.)

Hmm, well, I've come to the conclusion of assuming the lowest common denominator as far as anyone is concerned these days: if someone is interested in the finer points, they'll probably ask in a way that suggests it - while if someone asks a broad question, they probably don't want details.

Yeah, it's nice that it's extensible without having to be complicated in terms of editing the htaccess file now.

No.

The .htaccess file is the part that handles the fancy URL and passes it to PHP.

You can, on some configurations, get around it by constructing URLs in the form of index.php/rest-of-link/whatever but it's ugly and unreliable.

I don't want to get into the details, suffice to say I had need to write a SimpleDesk plugin today, and one of the things it does is add a new area to the admin panel, through $config_vars being passed to prepareDBSettingsContext. Nothing wrong there.

Then, after I finish setting up the array and passing it through to that function, I get a Warning: Invalid argument supplied for foreach() in C:\Dev\public_html\intranet\smf_2-0_install\Sources\ManageServer.php on line 1824.

This is a bit strange, but sure enough, line 1824:

Now, there's nothing happening between the start of prepareDBSettingsContext and that line that touches $config_var. And if I do a var_dump, I find there's a random NULL at the end of the var-dump that appears to be breaking it. Now, I'm confused because I have no idea where that NULL is coming from.

Here's the kicker: if I var_dump BEFORE the call, I get a normal var_dump and the array is normally traversable, so something about the call itself causes it to go nuts. It's not even the fact it's a reference, I reverted it to a normal variable by value and the same thing happens.

It's not like there's anything else going on - this variable is passed directly to the destination function and nothing hokey is going on in the middle.

So I'm really, really confused, and wondering if it's a bug. Maybe I should try upgrading (currently on 5.2.13 on local PC)

In other news, I am actually going mad, ignore me. Stupid bug, having spent an hour of frustrated debugging, because I forgot something quite important...

Not so much ironic, more using things the way they were designed to work. If it's running on startup and needs more-than-normal permissions, it should be hooked into the system designed for that express purpose.