Hi,

after some playing around with my local test system, I decided to start installing the soon to be productive wordpress installation. So far I am running

WP 2.9.2
ATA 3.5.3
I have made several changes to the styling on my local installation. To reuse them, I exported them into an ata_XXXX_.txt file. I can also succesfully import this file into the WP installation on my server.

The problem is, that after the import the wordpress installation goes dead, i.e. I only get a blank screen, the HTTP response is zero bytes.

I have checked the logs of the server and I see the following error:

[Thu Oct 14 21:37:26 2010] [error] [client XXXX ] PHP Fatal error:  Cannot use object of type stdClass as array in /var/www/domain/htdocs/wordpress-2.9.2/wp-content/themes/atahualpa353/functions/bfa_theme_options.php on line 29

As said before - when I do not import the settings, everything is fine. Afterwards things break.

I will also attach the exported style file. Maybe this can help somehow.

Can anybody give me a hint as to what might cause this?

bye, Grimmi

ust imported it and it works fine. one difference, I'm on wp 3.0.1 not sure if I have any test 2.9.2 versions around...I'll look
Can you swap back to the defaule theme (go into the Atahualpa folder and rename index.php to index.old - then go to dashboard->appearances->themes and it should switch to the twenty-ten theme) Then rename index.old back to index.php and try activating atahualpa again.

I will try this on the weekend.

Out of interest: What version of PHP is your system running?

I am wondering if it might be a compatiblitiy issue between php versions.

Test system (where everything works): PHP 5.3.3
Prod system (where things fail): PHP 5.2.11 + Suhoshin(?)

I have started some debugging of this issue. By adding a var_dump like this in line 29:

$bfa_ata = get_option('bfa_ata4');
echo "<pre>";
var_dump($bfa_ata);
echo "</pre>";

I get an output starting with this for $bfa_ata:

object(stdClass)#114 (267) {
  ["use_bfa_seo"]=>
  string(2) "No"
  ["homepage_meta_description"]=>
  ...

EDIT:
The output from my dev system for this is:

array(267) {
  ["use_bfa_seo"]=>
  string(2) "No"
  ["homepage_meta_description"]=>
  string(0) ""
  ...

So, to me it seems like the error message as showed in my initial statement indeed is correct. The result of the get_option call is NOT an array, but an object. So it is reasonable that the following:

$bfa_ata_widget_areas = $bfa_ata['bfa_widget_areas'];

causes such an error, because it treats $bfa_ata like an array.

That still leaves me wondering why I don't see this on my test system. But at least it seems like this is a bug. Anybody with more PHP/atahualpa development experience who would like to give a statement on this?

OK, taking this further: If I change this to the correct OO syntax, i.e.

$bfa_ata_widget_areas = $bfa_ata->bfa_widget_areas;

The error is gone. Next error up ahead is:

[Fri Oct 15 17:42:18 2010] [error] [client 79.196.247.50] PHP Fatal error:  Cannot use object of type stdClass as array in /var/www/vierpfeile/htdocs/wordpress-2.9.2/wp-content/themes/atahualpa353/functions/bfa_get_options.php on line 526

There I can see the same problem. But in fact, the whole code uses the array syntax on $bfa_ata. So I do not believe that this is the real problem.

Question: Given the very "mutating" history of PHP - Does anybody know if this is another episode of the ever-changing PHP??? Maybe there's some kind of switch that forces my production system to behave like this?

BTW - now that I am back in front of the system: The exact version of the prod system's php is:

PHP Version 5.2.12-pl0 with suhosin 0.9.7

Maybe there are some known issues with this combination?

Well I just went back and did a test on a WP 2.9.2 and Atahualpa 3.5.3 and export/import works fine. This is with php 5.2.9

I added the

echo "<pre>";
var_dump($bfa_ata);
echo "</pre>";

and I get an Array out.

So it seems that this is an environment issue. On one of your systems (and on two of mine), the line

$bfa_ata = get_option('bfa_ata4');

returns an array and on the other it returns an object.

so we have
php 5.2.9 - returns an array
php 5.2.12-pl0 - returns an object
php 5.2.13 - returns an array
php 5.3.3 - returns an array

Thanks for investigating, Juggledad.

To be more precise, we have

Originally Posted by juggledad

php 5.2.9 - returns an array
php 5.2.12-pl0 with suhosin - returns an object
php 5.2.13 - returns an array
php 5.3.3 - returns an array

So, to me the most likely culprit is suhosin. I will try to check this out further and report my findings.

OK, seems I am homing in.

We tried php 5.3.3 on the server - with and without suhosin. Seems like it is not to blame afterall.

So what I did next, was to import the DB Dump from the non working productive system to my test system. And I got the problem reproduced locally.

OK, so it is the DB contents. My best guess is, that the theme uses the entry "bfa_ata4" in table wp_options, correct? I did a diff of my working DB dump and the non working dump. Looking specifically at the bfa_ata4 entry.

And look what I found:

working dump starts with:

(185,0,'bfa_ata4','a:267:{s:11:\"use_bfa_seo

non working dump start with

(137,0,'bfa_ata4','O:8:\"stdClass\":267:{s:11:\"use_bfa_seo

I am pretty sure this is the culprit. So question from my side is: Which part of PHP is in control of how these settings are serialized into the DB? (I am guessing this is a serialized form as it seems that the first field is defining the data type that follows....).

Interesting though: I tried to fix the prod system manually, by exchanging the O:8:\"stdClass\" with a simple "a" like it is present in the working dump. That made the system work again, but the theme displayed only its standard values. Probably the serialization cannot be fixed that easily.

Anyway, here comes the interesting part: Due to the testing with and without the suhosin, we are now on PHP 5.3.3 on the prod server. So out of curiosity I did another import. And now everything works, and YES, the import now created a serialized version of the bfa_ata4 like it is on my test machine.

For me the issue is therefore solved. If someone has an idea as to why this strange version of the bfa_ata4 might have ended up in my DB, I would love to hear you out.

Thanks for the support.
Grimmi