Jump to content

Recommended Posts

My website is only partially functioning since my hosting provider switched to PHP5.

 

The main page comes up OK (it is composed of multiple PHP includes)

However, most of the links-- which are in the form noted just below-- do not function.

Here is a typical link:

  http://www.mysite.org/index.php?page=link

 

I was not the original developer of the site.. he is long gone.  I am good with HTML, JS, CSS, and SQL; but PHP and MySQL are new to me.  I can figure most things out, and have actually added some PHP to enhance the site.

 

I am thinking that PHP5 must handle parameters differently.  Or maybe "includes" are handled differently.

 

There is a very limited amount of MySQL in the site, but the main areas which are not working have no MySQL in them.

 

My questions:

1. Does PHP5 must handle parameters differently than PHP4?

2. Are "includes" handled differently than PHP4?

3. Could MySQL changes at the host affect the whole site?

4. What is the best open source debugging system?  What should my whole configuration be for programming and debugging on my local system?  Is there some effective and convenient way to debug the site "live" on the server.

 

Thanks for any and all suggestions.  :)

 

GentleGeek

I don't think PHP5 is substantially different from 4.

 

Could you possibly post a link to this page so I could check it out? Includes certainly shouldn't be affected.

 

And the best PHP debugging system is PHP. Just make sure errors are turned on, either in your php.ini or put display_errors(E_ALL); and ini_set('display_errors', E_ALL); at the top of each script.

There are very few incompatible differences between php4 and php5. Given the same php.ini configuration, most php4 code will work as is under php5. It is more likely that the problem is a php.ini configuration difference and given that a GET parameter on the end of the url is not working, your code is probably dependent on register_globals. Register_globals were turned off by default 7 years ago in April 2002. No code written after that point in time should have been dependent on register_globals. Register_globals have been completely removed in php6, so simply turning them on is not a long term solution (assuming your host has permitted them to be turned on at the site level.)

 

Posting the code for a page the does not work would allow someone to see what exactly it might be doing that is php version or php configuration dependent.

 

Your host should have posted any php.ini configuration changes he was planning on making with the upgrade so that you would have a clue as to what you might need to change in your scripts.

Thank you jackpf and PFMaBiSmAd

 

The site is stpatsmemphis.org 

.. it's a church website, so don't hack me please.. :-).. I know you were kidding...

 

If you see the links on the left.. those that use the "Page=" parameter, are the ones that no longer work.

 

Re your comments-

1. I was kinda wondering if there was some config that I could/should change in php.ini...

2. The site was originally developed around 2002 I believe.. so I better check register_globals- should I set it to "OFF"?

 

The other thing I have noticed is that "cascading" may be the problem- in other words- the main file "includes" a file, which then "includes" another file.  These 2nd level includes are not being loaded.  Is there some config switch in the INI that affects this?

 

Thanks again for your help

 

 

 

Is there some config switch in the INI that affects this?
Yes, but we cannot tell you which one without seeing how the code is attempting to include files.

 

There is not a one symptom = one cause in programming, due to its' general purpose nature. For any symptom there can be a dozen different causes and any problem can cause several different symptoms depending on where and how it exists in the code.

Here is a simplified discussion of how the code "works":

 

Index.php has a bunch of includes:

javascript.php, functions.php, navigation.php, and content.php, plus a few more.

They all look like this:

<?php include("includes/functions.php"); ?>

 

One thing that Functions.php does is fill an array variable

$contentpage

and $contentpage includes relative URL's which lead the way to the various content pages, like:

content/church-001-schedule_of_masses.php

 

When the home page is loaded, the navigation.php include has links to the other pages.

The link labeled "Church", points to the following URL:

http://stpatsmemphis.org/index.php?page=church

 

When you click this link, index.php loads the same set of includes as the first time, except

content.php has the following line:

include($contentpage[$section]['url']);

which loads

content/church-001-schedule_of_masses.php

 

So, the oversimplified sequence is

index.php "includes" content.php

and content.php "includes" whichever file is appropriate based on the link.

 

Anyhow...

All of this used to work, but now that my site host made their changes, the content in

content/church-001-schedule_of_masses.php

is never getting loaded...

 

You would need to determine what part of - include($contentpage[$section]['url']); is not working, then find out why. Is the $contentpage array being setup correctly? Does $section contain expected values?

 

As already stated your code is probably dependent on register_globals to magically populate program variables from external data. The program variables are no longer being set to any value. For the specific issue of $page not being set, you would need to add a line of code that sets page from the corresponding $_GET variable -

 

$page = isset($_GET['page']) ? $_GET['page'] : FALSE;

 

This may or may not cause the include($contentpage[$section]['url']); statement to work, depending on what the code is that sets $contentpage and $section.

 

If you set error_reporting to E_ALL and display_errors to ON, there will be undefined variable and index errors that would help point out the variables that are no longer being magically set by register_globals and need to be set from the correct source. However, based on the "quality" of the code so far, you are likely to get a huge number of such errors being reported due to lazy programming and not just the variables that are no longer set by register_globals.

 

It is going to take a significant amount of time to find and fix all the problems in your code. If they are all due to register_globals, you may want to consider temporarily turning them on while you find and make the corrections necessary make the code work without register_globals.

PFMaBiSmAd,

 

Thank you for your latest response.

I've read throug it once, and am now reading it more carefully to understand it all.

 

But, I'm gonna have to go to bed soon, and work through your suggestions tomorrow. after I get home from my day job.  I hope you can check in tomorrow and see how well I am progressing.

 

Thank you.

 

GG

include($contentpage[$section]['url']);

 

My god, that's so dodgy with register globals turned on :P

 

If somehow the variable $contentpages wasn't initialised, someone could just put http://www.yoursite.com/index.php?contentpage=http://www.mysite.com/&section=hack.php which could like...wipe the contents of your server.

 

Well, that's the principal of it anyway, I'm sure it wouldn't be that easy. So yeah, good job you got an upgrade :P

Hi guys!!

 

Sorry I haven't followed up.. My taxes got in my way.  :-[

 

Anyhow, I've checked my register_globals, and they are off.. so that's not a problem.

 

I've checked my error logs, and there isn't really anything there.  But, I will expand the error reporting if the other items mentioned below don't reveal the problem.

 

I'm going to try some "ordinary" debugging later today... by just echoing some values at key points in the code.  Especially checking to see what values  $contentpage and $section have when that include statement tries to execute.

 

I'm also going to make sure that $page is being set- by adding the following line of code as recommended by PFMaBiSmAd-

  $page = isset($_GET['page']) ? $_GET['page'] : FALSE;

 

Again, thanks for your help... I hope you guys are "still around".  :)

 

GG

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.