[SOLVED] Problem with themes after "upgrade"

[JoeP]

In a localhost install of 1.1.4 with tables populated using restore_backup.php, I am having problems with a custom theme that was working previously.  One specific example is in the board index page it does not seem to be picking up the default BoardIndex.template.php as witnessed by the lack of a catbg class.
One significant change between the working environment and the new one is moving from php4 to php5.
The custom theme is pretty simple, with only index.template.php, post.template.php, and style.css files.  The custom theme was based on version 1.1 beta 3.

I cannot provide a link to the non-working version because it's on my local development machine.
Thanks in advance!
joe

[charlottezweb]

so the main factor is that you (or your host) upgraded php4 to 5 and that's when this started?

[JoeP]

so the main factor is that you (or your host) upgraded php4 to 5 and that's when this started?

It's not quite that simple...
I did a complete backup of my live forum. 
I did a clean install of smf in my development environment.
I used restore_backup.php to make a "copy" of my live forum within the development environment.
The development environment is Mac OS X XAMPP 0.71 (apache 2.26, mysql 5.051, php 5.25, php 4.4.7).  I get the same behavior in the development environment with either version of php, so it's not a php 5 issue as I'd originally suspected.
The "live" forum is SMF 1.1.4 having gone through several upgrades since 1.1 beta3.

Everything seemed to work except that when I use my custom theme it does not seem to be using the default theme templates where it ought to be doing so.  I've been trying to figure out where the other templates are supposed to get called, but so far, I've not been successful.

Here's a specific symptom of the problem:  When I go to http://localhost/smf/index.php?board=8.0, the table row containing the column headings should have a class="catbg".  On the "live" site, it works correctly.  On the development site, it has no class assigned and the background comes out the same color as the text... black.  I believe that this behavior is supposed to be established by the default theme's BoardIndex.template.php.

Thanks for the interest,
joe

[TrueSatan]

Often you can fix such issues by copying the necessary file from the default template into the custom template directory...it's a known issue and a hosting peculiarity.

[JoeP]

Often you can fix such issues by copying the necessary file from the default template into the custom template directory...it's a known issue and a hosting peculiarity.

Thanks!
Unfortunately, since the last post I attempted to do another backup of the live site and restore to the development site and the restore is not working any more.  I posted the details on the backup_restore thread.
joe

[JoeP]

It turned out to be a rather simple problem after all... When you do a forum DB backup, many of the settings include absolute references to the site's url and directory structure which may not be correct for the site you are attempting to transfer your forum to.  So, what I did was edit the db dump sql file to replace all instances if http://my.old.site.url with http://my.new.site.url, and replace /path/to/old/smf with /path/to/new/smf.
Seemes to have worked like a charm!
joe

[charlottezweb]

Glad to hear you got it fixed 

Did you try repair_settings.php prior to that?

Cheers

[JoeP]

Glad to hear you got it fixed 

Did you try repair_settings.php prior to that?

Cheers

no, what is that?  I don't see it in my smf directory.
joe

[TrueSatan]

You would get it from the following link and put the file in your forum root then browse to it to use it...details are shown on the link below and with it:

http://www.simplemachines.org/download/?tools

[charlottezweb]

It does basically what you described in a few clicks

[JoeP]

It does basically what you described in a few clicks

Thanks!
BTW, forgot to mention that I had also had to increase my max_execute_time in php.ini to avoid the error I was getting with restore_backup.php. 
When I go to do this for real, I may take a look at using bigdump.php and repair_settings.php.
Thanks again,
joe