After Install 2.6 Have error in theme page

I have a similar problem when selecting “Design” (and Themes).

Fatal error: Cannot use string offset as an array in /home2/acu/public_html/example/wp-admin/themes.php on line 100

The current theme is listed, but there’s no listing of themes to switch to.

I have the same problem. Has anyone a solution to this issue?

Update: I deactivated all of my plugin and the issue was resolved. Now, I’m going to go through one at a time to figure out which plug-in is causing this issue. I will update when I figure it out.

Update #2:
The plug-in that seemed to cause errors:
Stray Random Quotes

I have the fix. Simply edit the file wp-admin/themes.php

On line 94, add:

$table = array();

To help you find it, here’s what the surrounding code will look like:

$rows = ceil(count($theme_names) / 3);
$table = array();
for ( $row = 1; $row <= $rows; $row++ )
        for ( $col = 1; $col <= 3; $col++ )
                $table[$row][$col] = array_shift($theme_names);

burtonkent, I just upgraded today to 2.6 and encountered this error. Thanks so much for providing the solution!

Thanks burtonkent, only had this issue, so far, with a site on (mt).
I’ve also got stray quotes running but didn’t want to get rid of it.

Hm, I added that line but nothing happened.

My problem is just that no themes AT ALL show up on my theme page in the design tab. I do have the classic theme uploaded to my theme contents folder. Anyone else have this problem?

ok, figured it out.

I had uploaded “classic” but not also “default.” (I had figured I wouldn’t be using default anyway, so might as well skip it).

Turns out “default” has gotta be in there, at least initially.

For those of you who experience this same problem, do NOT edit the core WordPress files! The problem is not in the core, but most likely in a plugin that uses the variable name $table outside of a function. The var $table is declared early on in the included admin files and if a plugin uses the same $table var, it breaks the theme page.

I have the same problem, but all plugins are inactive, and I even added the (unneeded?) code above. Do I need to actually remove the plugins?

For those of you who experience this same problem, do NOT edit the core WordPress files! The problem is not in the core, but most likely in a plugin that uses the variable name $table outside of a function. The var $table is declared early on in the included admin files and if a plugin uses the same $table var, it breaks the theme page.

Don’t be such an alarmist.

There’s nothing at all wrong with editing the core WP files. Just don’t expect the “fix” to persist if you overwrite it with upgrades.

I have the same problem, but all plugins are inactive, and I even added the (unneeded?) code above. Do I need to actually remove the plugins?

No, the plugins aren’t run if they’re inactive. Your problem is caused by something else.

There’s nothing at all wrong with editing the core WP files. Just don’t expect the “fix” to persist if you overwrite it with upgrades.

Amazing. Your second sentence directly contradicts your first one.

The fact that your “fix” won’t survive an upgrade is the exact reason that you want to avoid editing core files. If you can fix it in any other way at all, then do it the other way. In this case, the fix should be made to the bad plugin instead.

I fixed it by insuring that the original “default” theme and “classic” theme were the ONLY themes in the theme directory. Once I did that, all worked. I was then able to add new themes, and have had no problems. But it required those two to remain, if I removed them, to save space, not that I need to, it had problems again. I had also tried to rename my preferred theme to default, but that did not work.

Don

The classic theme is optional, you can get rid of it without consequence.

The default theme is NOT optional. It must be there. This is because WordPress defaults to it for certain files, when the current theme lacks these files.

There’s nothing at all wrong with editing the core WP files. Just don’t expect the “fix” to persist if you overwrite it with upgrades.

Amazing. Your second sentence directly contradicts your first one.

The fact that your “fix” won’t survive an upgrade is the exact reason that you want to avoid editing core files. If you can fix it in any other way at all, then do it the other way. In this case, the fix should be made to the bad plugin instead.

Otto, I agree we want to avoid editing the core files. But unless you have a better idea/fix not involving doing that, I stand by what I said.

This is especially true for users who don’t have the expertise to find the source of the problem. People need their sites to work – I wouldn’t tell them not to use their only known fix because it’s less than ideal. (Try to keep in mind not everyone is like you or me – able to debug PHP.)

If someone does come up with a better fix, I’m all for it. Until then, this one works without breaking anything. Just don’t expect it to be persistent.