Test Installation

[Augustus Lucifer]

Would it be possible at some point to set up a test installation? I know we're afforded one limited access testing area, but to my knowledge we haven't utilized it. Reason I ask is I'd like to try my hand fiddling with vB-related PHP hacks, but I'm not too keen on changing anything on the live site of significance. Used to be able to do this on my copy of vB, but it's unlikely I'll get a new license since I just don't want to spend that kind of $$ for a testbed I'm not using for anything. I don't know if replicating the database of the live site or just using a default setup would be more ideal, since I suppose it depends on whether or not de-serializing forumcache on the test install is treated the same as just another user doing the same thing on the live site or it would handle it in some wacky compounding manner.

I'm putting this in the Cathedral for now since the vB terms stipulate it has to be limited access, so if we do set one up it's probably a good idea to not give away the location.

[GrnEyedDvl]

I have no issues with setting one up. Either on the main server or on another machine.

[Simetrical]

I've defined a function in includes/config.php:

    function sim_debug() { return $_SERVER['REMOTE_ADDR'] == '68.175.61.233'; } 

Then if I want to test a change, I do it on the live site, wrapped in if (sim_debug()) { ... }, so it doesn't affect other users while I'm testing. As long as I don't make a syntax error, it works fine. This is usually more useful in practice than a test site, because it has all our config and so on. It rarely causes problems. You could use a similar function, if your IP address is fixed. Or write one that checks $vbulletin->userinfo['userid'] == 14571, although that will only work once $vbulletin->userinfo is initialized.

I'll move this to the Bazaar, since there's nothing confidential yet. If we set up a secret test site, we can put the access info in the thread in the Cathedral with the rest, but there's no need to keep it secret beyond that.

[Augustus Lucifer]

Don't recall if I set up a static IP or not, but I'll check it when I update my router firmware. Good idea at any rate.

When you say "although that will only work once $vbulletin->userinfo is initialized.", are you simply referring to needing to log in to have it apply? Or is it a situation where some hacks can't call userinfo depending on what procedure they modify?

[Simetrical]

The contents of $_SERVER are set up by PHP before vBulletin code runs at all, so they'll always be there no matter where sim_debug() is called. $vbulletin->userinfo is a variable that's set up by vBulletin, so if you try to access it at some point in the code before it's set up in includes/init.php, the access will fail. init.php runs very early in vBulletin setup, so it will probably work rather reliably, but it might fail for some code in principle, if it's run early enough. So I use the IP address instead.

If you leave your router attached to a broadband connection all the time, it will keep the same IP address at least as long as it's continuously powered up and connected. And possibly indefinitely, as long as it's not disconnected for too long (depends on whether it tries renewing its old DHCP lease or requests a new one). Just get your public IP address from a site like http://www.whatismyip.com/ and see if it changes. At worst, you have to update the function once in a while.

[GrnEyedDvl]

If you leave your router attached to a broadband connection all the time, it will keep the same IP address at least as long as it's continuously powered up and connected.

That depends on the ISP. Quest for instance forces out a new IP every 2 weeks or so. If you find your IP changing frequently then you can set up Dynamic DNS through a 3rd party service. Basically you register the name augustuslucifer.com and then install a small app on your machine. It polls a DNS server several times a day and points your domain to the your new IP whenever it switches.

[Augustus Lucifer]

Should I add my IP to the existing $debugModeIps array as well?

$debugModeIps = array( '68.175.61.233', '76.95.12.82' ); 

Or just create a new al_debug() mirroring the existing sim_debug() one?

if (!function_exists('al_debug'))
{
    function al_debug() { return $_SERVER['REMOTE_ADDR'] == '76.95.12.82'; }

} 

Frankly, I'm not certain what debug mode does. I've googled and checked the vB Manual and the official forums; plenty of threads saying how to enable it, but not one listing of the features. Maybe I just failgoogle.

EDIT: Ironically, I seem to have gotten the answer to what it does from you. Well, you from the beforetime, in the thread where you enabled it for yourself based on the same vb.org thread I was just referencing.

This shows a neat little thing at the bottom of the page that allows me to see what templates were used, how long the page took to generate, what queries were used, and how long each took. Very nifty. In particular, I find that MySQL queries take tens of milliseconds, PHP logic takes hundreds. xdebug is definitely something to think about, sooner than more PHP tweaks.

[Simetrical]

That depends on the ISP. Quest for instance forces out a new IP every 2 weeks or so. If you find your IP changing frequently then you can set up Dynamic DNS through a 3rd party service. Basically you register the name augustuslucifer.com and then install a small app on your machine. It polls a DNS server several times a day and points your domain to the your new IP whenever it switches.

It won't force out a new IP address if the router is never shut off, because that would interrupt all connections. It might force a new IP address on router reboot. Anyway, yeah, that works too.

Should I add my IP to the existing $debugModeIps array as well?

$debugModeIps = array( '68.175.61.233', '76.95.12.82' ); 

Sure. The main effect is to add a performance summary to the bottom of every page. It has some other weird effects too, though, and isn't really meant for production use, so be careful. For instance, it will let you use the ACP even if install/install.php is present, but not other admins (since they don't have debug mode on).

Or just create a new al_debug() mirroring the existing sim_debug() one?

if (!function_exists('al_debug'))
{
    function al_debug() { return $_SERVER['REMOTE_ADDR'] == '76.95.12.82'; }

} 

You don't need a separate function_exists() check; just put the function definition in right under sim_debug(). If sim_debug() is defined, so will al_debug(), because they'll be right next to each other. The function_exists() is there because some things were require()ing config.php instead of require_once(), and PHP dies with a fatal error if a function with the same name is defined twice. Add your own function so that when you're messing around, it won't show up for me, and vice versa. This is unrelated to vB's debug mode.

[Augustus Lucifer]

Sure. The main effect is to add a performance summary to the bottom of every page. It has some other weird effects too, though, and isn't really meant for production use, so be careful. For instance, it will let you use the ACP even if install/install.php is present, but not other admins (since they don't have debug mode on).

Interesting, added it and took a look, some useful stuff. Not going to leave my IP in there at all times though, will just add it if I need to look at that information for something.

You don't need a separate function_exists() check; just put the function definition in right under sim_debug(). If sim_debug() is defined, so will al_debug(), because they'll be right next to each other. The function_exists() is there because some things were require()ing config.php instead of require_once(), and PHP dies with a fatal error if a function with the same name is defined twice. Add your own function so that when you're messing around, it won't show up for me, and vice versa. This is unrelated to vB's debug mode.

Right, done and done. The server may or may not be a ticking time bomb as a result.