Started to create an AT sub-theme for a clients site that I am upgrading from D6 to D7 today. All of the upgrade went fine, that's not the problem.
Set it all up, created the AT sub-theme, enabled it, everything fine at that point. Then into the template settings to set everything up from there before building out the sites CSS styling. Upon saving the settings I encountered a white screen with the message:
Fatal error: Cannot use assign-op operators with overloaded objects nor string offsets in C:\xampp\htdocs\dev\azlawpartner\site\sites\default\themes\adaptivetheme\at_core\inc\preprocess.inc on line 874
As it states Line 875, I had a peek through the code, that section is:
if (is_array($vars['attributes']['class'])) {
$vars['attributes']['class'][] = 'image-style-' . $style_name_class;
}
else {
Else it's a string, workaround for Media module bug: http://drupal.org/node/1722146
//and User Badges bug: http://drupal.org/node/1748394
$vars['attributes']['class'] .= ' image-style-' . $style_name_class;
}
with line 874 being: $vars['attributes']['class'] .= ' image-style-' . $style_name_class;
I have also had a look at the bugs mentioned in the comments but I am not using Media or User Badges, this is more or less a fresh install on my development machine as I am getting everything up to speed before pushing anything to the live site.
I initially managed to recover the installation thankfully without much hassle but after another unsuccessful attempt where I extracted the theme from the archive again and copied the sub-theme codebase out on its own and renamed everything I am now totally locked out of the installation and faced with the message:
Error
The website encountered an unexpected error. Please try again later.
.
I have used AT sub-themes for a few projects recently and haven't had any problems, I thought you would appreciate the bug report.
I have set this to critical inline with your comments on http://drupal.org/node/1722146#comment-6381534 as it is throwing a fatal error.
Comment | File | Size | Author |
---|---|---|---|
#8 | azlaw-krumo-screenshot.jpg | 166.37 KB | raynimmo |
#8 | modules-screenshot.jpg | 2.85 MB | raynimmo |
#10 | azlaw-krumo-screenshot-siteroot.jpg | 59.61 KB | raynimmo |
#9 | azlaw-krumo-screenshot.jpg | 327.96 KB | raynimmo |
#9 | modules-screenshot.jpg | 1.34 MB | raynimmo |
Comments
Comment #1
raynimmo CreditAttribution: raynimmo commentedjust tried to set up a fork of Corolla 7.x-3.0-rc1, exact same condition.
thank god for
$conf['theme_default'] = 'garland';
in settings.phpUPDATE
Just bumped everything back to AT 7.x-2.3 and Corolla 7.x-2.2 , a set up I have used previously and everything seems fine so I don't think its my setup that's causing the problem
Comment #2
Jeff Burnz CreditAttribution: Jeff Burnz commentedSounds like a pretty special case, you will need to debug this for me.
- install the Devel module
- comment out
$vars['attributes']['class'] .= ' image-style-' . $style_name_class;
- add
dsm($vars['attributes']);
at the bottom of the adaptivetheme_preprocess_image() functionNow reload the page where you have an issue. Krumo will print the results, I need to see those, maybe a screenshot would be good.
Comment #3
Jeff Burnz CreditAttribution: Jeff Burnz commentedYeah, 7.x-2.x themes do not have this special workaround for modules that mess up the classes array. What this code does is inject a class based on the image style, so you can in effect style all image fields that use a particular image style the same way. I am reluctant to take this out because I know there are themes and sites using it. We need to figure out what is causing the issue or close this issue if you have no plans to move back to 7.x-3.x. Its just too weird for me to guess what it might be, I mean it sounds like our check is_array is not working but that would be odd, very odd.
Comment #4
raynimmo CreditAttribution: raynimmo commentedahhhh, just shut down Jeff, currently in bed with the tablet, I really appreciate the prompt reply but its gonna be the morning before i get back to this, im in gmt+7
I tried commenting out $vars['attributes']['class'] .= ' image-style-' . $style_name_class earlier but it was just throwing a major error with site unreachable. I also tried commenting out the whole section, same situation.
Will repost as per your request as soon as i get the chance.
Feel free to bump down the priority on this as its still on a dev site although hoping to push it live in the next day or two.
Comment #5
Jeff Burnz CreditAttribution: Jeff Burnz commentedThinking logically, I wonder if there is a module that is totally wiping out the attributes array, that would make some sense, i.e. not only is classes not an array, the entire attributes array is a string, its possible.
Both the bugs that caused this workaround to be added to the theme are now fixed, so I am thinking I might actually remove part of this code entirely, aka the following, and just don't print a class if some silly module is trashing the attributes:
Comment #6
Jeff Burnz CreditAttribution: Jeff Burnz commentedRight, just saw your reply, no problem, I will change the details of the issue, to be frank this is not a bug in the theme, its a bug in a module, maybe even Drupal core (due to the upgrade thing).
Comment #7
raynimmo CreditAttribution: raynimmo commentedRight, sorry, hectic day yesterday and only had an hour to try and recreate this, sadly I failed to do that then.
This morning, attacked it fresh, this was my process.
Again faced with a white screen containing only the text
Opened the file '\adaptivetheme\at_core\inc\preprocess.inc' and commented out Line 874
$vars['attributes']['class'] .= ' image-style-' . $style_name_class;
and addeddsm($vars['attributes']);
at the bottom of the 'adaptivetheme_preprocess_image()' function.That function now reads as:
I then refreshed the page and took a screenshot of the output, see attached file azlaw-krumo-screenshot.jpg
I have also attached a screenshot of the modules page so you can see what modules are enabled, see the attached file modules-screenshot.jpg
On a side note, D.O. wimped out at the meagre 166kb krumo screenshot and dumped this to my screen:
{"status":true,"data":"\u003cdiv class=\"messages messages-error clear-block\"\u003eValidation error, please try again. The file you attempted to upload may be too large. If this error persists, please contact the site administrator.\u003c\/div\u003e\n"}
This had me uploading the modules screenshot in trepidation as it was 2.8MB!
Cleared my browser cache, logged in to D.O again and attempted the upload once more.
Text dump from Krumo output
edit
screenshots attached to next comment
Comment #8
raynimmo CreditAttribution: raynimmo commentedscreenshots attached.
maybe easier to show you at a glance the currently enabled modules to save you wading through that modules page screenshot:
enabled modules:
Edit
nope, crap screenshots, didnt notice that, check next comment for full screenshots
Comment #9
raynimmo CreditAttribution: raynimmo commentedbetter screenshots
Comment #10
raynimmo CreditAttribution: raynimmo commentedThe previous Krumo printouts where taken whilst the site was browser was still attempting to view the theme selection page at http://localhost/dev/azlawpartner/site/admin/appearance
Alas, when attempting to view the site root at http://localhost/dev/azlawpartner/site/ the Krumo output seems to point to the possible cause:
Krumo output as text dump
Will try and disable the following modules in the database and see what results it gives me:
see attached screenshot also
Comment #11
raynimmo CreditAttribution: raynimmo commentedUsed PHP-MyAdmin to view the site {
system
} table and setstatus = 0
for the following modules:sites/default/modules/print/print.module
sites/default/modules/print/print_mail/print_mail.module
sites/default/modules/print/print_pdf/print_pdf.module
Nothing, still the same Krumo output and the same error when un-commenting Line 874 on
adaptivetheme\at_core\inc\preprocess.inc
Its gotta be coming from the Print module surely (http://drupal.org/project/print), incidentally, using DomPDF (http://code.google.com/p/dompdf/) for PDF generation.
Update
re-enabled 'Garland' through the
settings.php
switch to allow me to uninstall the Print module completely from the database, no change, however when viewing the site root it is no longer showing the Krumo output, odd?Now that the module is completely uninstalled, un-commented Line 875 in preprocess.inc and again, same deal pointing to Line 874.
Comment #12
Jeff Burnz CreditAttribution: Jeff Burnz commentedAwesome man, can you tell me what version of PHP you are using?
Sorry for the short reply, I did read everything you posted but it still doesn't highlight any major issue, so I trying a different track.
Comment #13
raynimmo CreditAttribution: raynimmo commentedcurrently running XAMPP on my dev machine with PHP 5.3.1
Will try and upgrade to the latest PHP version over the next few days if I can get the chance and see if it makes any difference. Gonna bump back down to AT 7.x-2.3 for now as I gotta get this project rolling but will continue to try and debug this as I am sure it will rear its head again at some point in the future.
I have set this issue to 'postponed' for now as it would be handy to post my findings back into here when i get the chance to continue debugging it.