PHP Configuration Functions

[Viper114]

Greetings.  First time poster looking for some PHP help if it can be provided, because I'm confused as hell.

 

First off, I'll explain my situation.  I'm the IT technician of a small business tasked with ensuring the business' computers and website are running in top shape.  I originally joined as a Data Entry clerk to post products to the business' website, but got promoted when they original IT technician left town to pursue his PhD.  Before he left, he taught me a few things to prepare watching over the website as my new duty, including some PHP and MySQL.  Now, a few months after he's left, I have the glorious task of trying to move our website to a new host because we've apparently outgrown our original host's capabilities.  And being based on PHP with a MySQL database, it's turning out to be OH-so-fun. :-\

 

So far, I've managed to download our entire website from the old host and given it to our new host to put up as a testing site, to ensure everything works before we switch hosts.  And for the most part, a lot of it has come together nicely, but there's still work needed to be done.  And thus we come to the problem I hope someone here can help with.

 

Our website has two back-end Admin sections, an older one that used to handle everything, and a newer one that's sleeker but still reads off a lot of data from the older one to work properly.  Normally, when you access those sections, you need to log in first.  Now, in the testing site, when I access those areas, the header of each of those sections now reads <?= $row[title] ?> and if I attempt to log in as normal, it just flashes back to the login page with the fields now cleared of what I typed in.  When I asked about this to see what the problem might be, the new host said it might "at least two misconfigurations on the new server relative to the old server".  So, I've been trying to Google for some help with PHP Configuration Functions, but I don't know if what I'm reading will help me fix the problem.  Would anyone here happen to know what they might mean in this case, because my knowledge of PHP is fairly limited beyond what I was taught to keep the website in order without considering a host change...

 

Thanks to those who help or can direct me to a place that helps!

[Psycho]

Ahh, yes, you have stumbled across the notorious problem of short tags.

 

Instead of using

<?php
//Code goes here
?>

 

Some programmers would use

<?
//Code goes here
?>

 

Also, the short tags had the added benefit of easily inserting dynamic text using

<?=$variable?>

instead of

<?php echo $variable; ?>

 

But, short tags are considered bad practice and that setting is no longer turned on by default. With that optioned turned off on your new host, the short tags are not recognized as the start of PHP code and the code inside them is not processed.

 

Check this manual page on how to set that option. Although, it might be better to just find and replace all instances of short tags. Then you never have to worry about this again if you change servers.

 

http://php.net/manual/en/ini.core.php

[Pikachu2000]

Short open tags are probably set to off in the php.ini file. The short open tag syntax <?, and quick echo <?= syntax should be avoided for just that reason. Full tags will work irrespective of the setting, short tags only work when it's set to On.

[Viper114]

That's something I can definitely try to fix first, see if perhaps that will allow things to work again.  However, being a PHP newb, I don't see a php.ini file in amongst the files I downloaded directly from our original host.  Is the php.ini file located somewhere on the host's end, or is it somewhere else?  I've never had to manipulate the php.ini file before...

[Psycho]

That's something I can definitely try to fix first, see if perhaps that will allow things to work again.  However, being a PHP newb, I don't see a php.ini file in amongst the files I downloaded directly from our original host.  Is the php.ini file located somewhere on the host's end, or is it somewhere else?  I've never had to manipulate the php.ini file before...

 

The PHP.ini file is a server configuration file - it is not configured for the site or reside in the site's public directory. If you are on a shared host you will likely be out of luck in getting them to change it since it affects all websites on that server. If you have a dedicated server with this new host they should have no problem changing that setting for you. I don't believe there is a way to change the behavior at run time.

 

But, the best solution is to just remove the short tags anyway.

 

If there is just this one instance of that problem, then change that code from

<?= $row[title] ?>

 

To this

<?php echo $row[title]; ?>

 

But, I would probably do a search of all the files for short tags. There are many free utilities out there that can do this for you. Search & Replace is one that comes to mind (I think it's still available).

[PFMaBiSmAd]

I'll second that ^^^

 

You won't always be on a server where you will have the ability to change the short open tag setting, so it is worth your time to just fix the code so that the php tags will always work and you won't need to go through this every time you switch to a different server.

 

Most programing editors and/or operating system search/replace utilities can globally search/replace in all the files and folders starting at some folder location.

 

1) Change all <? to <?php

2) Change all <?phpphp to <?php

3) Change all <?php= to <?php echo

[Psycho]

1) Change all <? to <?php

2) Change all <?phpphp to <?php

3) Change all <?php= to <?php echo

 

Just to clarify what PFMaBiSmAd is advising. The first replacement will change all short tags from <? to <?php. But if you have any "regular" tags, they will be changed from <?php to <?phpphp which is why he has the second replacement. Then, of course, the short tags used to echo text are changed from <?= to <?php= which is why the third replacement is listed above.

 

That should work. But, call me a nervous Nellie, but I never do such system-wide search and replaces. I would be concerned that there might be a valid use of "<?" somewhere in the code which has nothing to do with the short tags. So, I would use a search and replace utility but validate each replacement before it is made. Of course, it shouldn't need to be said, but you should only do the replacements on copies of the files so you can revert back if needed.

[Viper114]

When I do some digging on the login.php file, the file which is aptly named to need a login before going into the admin section, I notice that a lot of the work is done in long form rather than short form (it starts off with a <?php at the top, for example).  The section I mentioned is in the HTML section, shown as:

 

<html>

<head>

<title><?= $row[title] ?></title>

</head>

etc...

 

So, should this little section be changed to long form, like <?php echo $row[title] ?> instead?  It seems a lot of little sections seem to be done in short form, where big section are done in the long form.

[Psycho]

So, should this little section be changed to long form, like <?php echo $row[title] ?> instead?

Yes. But, I'd add a semi-colon and quote marks as well - just to follow good programming standards.

<?php echo $row['title']; ?>

 

It seems a lot of little sections seem to be done in short form, where big section are done in the long form.

 

Which is why we are stating you will need to do a system wide search and replace.

[Viper114]

Alright, I'll see what I can do with a search and replace.  I'll do the changes in one set of files and keep another set of the files unchanged in case something even worse occurs after the change so I can fall back if needed.  I'll return later with results of the change.

[Viper114]

OK, so I did the changes and uploaded, and while the short forms are now gone as suggested, it didn't change much, there's still no logins going through.  Since the logins are tied to the database, perhaps there's something wrong with the website and database communication...

[PFMaBiSmAd]

You should be debugging your code with error_reporting set to E_ALL and display_errors set to ON to get php to help you.

 

If the php code on a page acts like it is actually being executed (not just a blank page), you can add the following two lines of code immediately after the first opening <?php tag -

 

ini_set("display_errors", "1");
error_reporting(E_ALL);

[Viper114]

I'll try that, see what happens.  If it's anything in particular, I'll report back.

[Viper114]

AH, I now see errors at the top of the page above the login fields now.  There's two:

 

Notice: Undefined variable: action in D:\wwwroot\gear-up.com\_root\cart_admin\login.php on line 7

Notice: Undefined variable: package in D:\wwwroot\gear-up.com\_root\cart_admin\login.php on line 59

 

So, what's on these two lines exacly, I wonder?  I opened the file and found them:

 

Line 7 - if ($action=="logout")

Line 59 - <div align="center"><br><br><?php echo $package?><br><br>

 

So, it seems to be a case that, for some reason, the test site I'm working with wants these two variables defined.  But it's strange, on our live site, these lines are the exact same, yet there are no errors occuring when logging into our backend admin sections.  Why would the test site not like this when the live site doesn't mind?  Could it be because according to the PHP file, one you hit login, it does a MySQL query to find the username and password put in, and the test site isn't communicating well with the database right now (which I'm trying to fix as per another thread)?  Or something else?

[Psycho]

Those are just notifications - not really errors. You are only seeing them because you changed the error reporting to E_ALL.

 

Basically the notification is that you are tying to use/compare a variable that has not been set. It is a notification because you *may* have created a typo and really want to be comparing a different variable.

 

Example:

$myVar = 1; //Note V is uppercase

if($myvar==1) //Note: V is lowercase
{
  //Do this
}

 

You could make a modification of those comparisons to prevent the notification

if (isset($action) && $action=="logout")

<div align="center"><br><br><?php echo (isset($package))?$package:''; ?><br><br>

Or just set $action and $package as '' somewhere at the beginning of the script.

[Viper114]

Worth trying out, I'll see what those do and report back later.

[PFMaBiSmAd]

Your line 7 error is a good indication that your code was written using a feature that was turned off by default over 8 years ago, is currently depreciated, and scheduled to be removed in the next major release of php - register_globals.

 

What are lines 1 - 7 of that file?

[Viper114]

Lines 1 - 7 in the file called login.php are as follows:

 

<?phpini_set("display_errors", "1");error_reporting(E_ALL);require_once("setup.php");require_once("database.php");if ($action=="logout")

 

 

Then it goes on with the script to check the login and such.

[PFMaBiSmAd]

$action is not being set by your code, therefore it is not defined.

 

Unfortunately, your code does appear to be dependent on register_globals being on to magically set program variables from $_POST, $_GET, $_COOKIE, $_FILES, $_SESSION, $_ENV, and $_SERVER variables. Unfortunately again, register_globals also magically allow hackers to set your $_SESSION variables and a lot of web sites have been taken over.

 

Your code should be setting $action from wherever it is actually coming from, probably a $_POST or $_GET variable with an index name of 'action'.

[Viper114]

Yeah, I'll probably try to find out where it is, probably in one of the required PHP files listed at the top.  If I can't find it, I could do what mjdamato suggested, see how that works.  I'll try some things later today and get back on the results.

[Psycho]

Yeah, I'll probably try to find out where it is, probably in one of the required PHP files listed at the top.  If I can't find it, I could do what mjdamato suggested, see how that works.  I'll try some things later today and get back on the results.

 

The point PFMaBiSmAd was trying to make is that if that variable is relying up REGISTER_GLOBALS to be turned on you won't find that variable being set anywhere.

 

Example: Let's say a user clicks the following link

http://www.mysite.com/index.php?action=deleterecord

 

In that script you could access the value of action, as passed through the GET parameter, using $_GET['action']. But, with register globals on, that value is also automatically set in a local variable with the same name: i.e. $action. So, you wouldn't see a

$action = $_GET['action'];

[Viper114]

So should I bother with what you suggested earlier, trying to use isset?  Or should I look at changing the REGISTER_GLOBALS instead?  The problem I think may happen if I change REGISTER_GLOBALS is that numerous things may then stop working as intended in other places, requiring mode code work done.

[Viper114]

Oh, now I understand.  I tried isset and sure enough, as you said, the notifications went away but the problem remained.  Well, also, the notifications were still in the title bar of the browser, anyway.  Durr...

 

OK, so it seems that what needs to happen is both these things need defining somehow, although I have no idea how our live site works with these "undefined" variables.  What I think I should try first is to see if the register_globals function will allow these to work, as you guys mentioned.  I Googled up on register_globals and found DIY methods of manipulating the function that some people have said worked for them, since usually it's handled by the server owner in the php.ini file.  So, I tried:

 

1. Creating a php.ini file with "register_globals = on" only, and placed it in the root directory to see if it will work.  No change.

2. Used the same file and put it in the directory that the backend section is contained in.  No change.

3. Changed the .htaccess file so that it uses the "php_flag register_globals on" line, then put it in the root directory.  No change.

4. Used the same .htaccess file and put it in the directory the backend section is contained in.  No change.

 

All those methods didn't even change the page showing those notifications, they sat there just as normal and I still couldn't log in to the backend of the test site.  My guess is that either the DIY methods I found through Google just don't work (the new host may have somehow blocked those changes from happening from outside sources and only they have the ability to change it) or perhaps they weren't originally affected by the register_globals function (which is probably total crap according to you guys, but I'm just a newb who's hypothesizing here).

 

I suppose there's two things I could try and do at this point.  Either ask the new host if it's possible they have the power to allow register_globals for the test site and see if that does the trick, or forget the register_globals entirely and manually try each variable governed by that function and see which ones are the right ones needed, in a way that you showed in your last post, mjdamato.  Or perhaps something else I'm not thinking of?

[Viper114]

Well, I decided to try both.  First, I asked the new host if they can turn on the global variables.  But it may take a while before they respond, so I decided to experiment a bit.  I tried to add in the following to the PHP file:

 

$action = $_XXX['action'];

$package = $_XXX['package'];

 

Where XXX was each and every global variable that I could find.  SERVER, GET, POST, FILES, REQUEST, SESSION, ENV and COOKIE.  Unfortunately, each and everyone just led to the same thing: Undefined Index on each of those new lines I made.  I originally tried POST and GET as when I checked all the files, I found "METHOD = " instances using either one of those, but when both of those came back as Undefined Index, I branched out to the other ones.

 

When I decided to see if I could find a way to fix the Undefined Index problem, I generally encountered the same solution: isset.  That's all well and fine for those people, but I tried those before and as I said, all it does is hide those warnings and doesn't fix the overall problem.  Unless there's something else to try, I'll have to wait and see if the new host will allow the register_globals function to be turned on.

[Psycho]

When I decided to see if I could find a way to fix the Undefined Index problem, I generally encountered the same solution: isset.  That's all well and fine for those people, but I tried those before and as I said, all it does is hide those warnings and doesn't fix the overall problem. Unless there's something else to try, I'll have to wait and see if the new host will allow the register_globals function to be turned on.

 

I think you are still not understanding the core issue. Using isset() IS the solution. You DO NOT want to use register globals. Using that opens your site to vulnerabilities. The problem is that it may take a lot of code review to find all the places where you need to implement a fix.

 

Let me give one last example to hopefully illustrate the problem.

 

Again, let's assume that there is an $action variable used to determine what to display on a page. The value may be set usign $_GET or $_POST, or both, and possibly other means. By having register globals turned on you would have to know all the possible ways in which the value could be set. Because of register gloabls there is no direct indication of how the variable is being set.

 

But, to make matters worse, it seems that the value of $action is not required to be set! In the cases where it is not set, the application follows some default logic. So, you might see this in the code.

if($action=='admin')
{
    //display admin results
}
else
{
    //display user results
}

 

So, in that case, the else statement will be the default. However, if you are always testing as an admin you would never get the notification error (if register globals was on).