Jump to content

[SOLVED] Some problems after upgrade to 1.5.5.0


Recommended Posts

I upgraded today from 1.5.4.1 to 1.5.5.0, and I'm experiencing some problems. It appears that the URL-rewriting of "http://shopdomain/order" is causing a redirect loop. I have tried regenerating the .htaccess-file, but that didn't help. When I changed the order process to onepage checkout, it seems to work.

 

Also, it appears that the first access to a page after a configuration change causes a PHP-error:

 

"PHP Fatal error: Function name must be a string in /var/www/prestashop/tools/smarty/sysplugins/smarty_internal_templatebase.php on line 281"

 

Anyone else having the same problems?

Link to comment
Share on other sites

The requests doesn't seem to enter the Dispatcher at all, so I suspect the .htaccess file as the cause of the problems.

 

Edit: Then again, changing the friendly url name does solve the problem, so it might not be a .htaccess problem after all. But it's strange that I can't see any traces of the initial request.

Edited by Nils-H (see edit history)
Link to comment
Share on other sites

I just did an upgrade from 1.5.4.1 to 1.5.5.0 and my customers called me complaining they cannot place an order or edit cart.

i was able to do it for them over the phone.. even though i got errors. credit card payment went through. Since then I reverted to last previous version and all problems solved. BUT i cannot see visitors online. I thought that was weird.

Link to comment
Share on other sites

After enabling debug logging for mod_rewrite, I noticed that apache was adding .php to the friendly URLs. After some googling, I found that this is something Apache Multiviews. Disabling multiviews in the back office solved the problem.

Link to comment
Share on other sites

Yes, but there's still the other issue, with the error "PHP Fatal error: Function name must be a string in /var/www/prestashop/tools/smarty/sysplugins/smarty_internal_templatebase.php on line 281" that seems to occur after the first request after a configuration change in the back office.

Link to comment
Share on other sites

Ok, that might explain why multiview caused a problem. Still, shouldn't the upgrade process have deleted those files, if they are no longer used?

 

Anyway, that still does not explain the smarty-issue I'm seeing. It seems to happen quite a lot during order-opc. I have switched to the regular 5-step order to see if that helps.

Link to comment
Share on other sites

i've done a clean 1.5.5.0 install, and they are still present.

Multiview causes apache to try to search for files, if the request isn't found in the first place.

If the request was /order  , which isn't present, apache search also for order.html , order.php and so on.

Looks like a couple of files are there for backwards compatibility, because i found more traces of this in the code.

 

@Nils-H, have you tried switching on the smarty debugging ?  The error is because of caching an unnamed function

at that part in the fetch method of smarty, so a screen (or part of) was being fetched.

Maybe the debugging is showing what was called. Hope this clears the error a bit.

              // render cached template
              $_template->properties['unifunc']($_template);
    
Link to comment
Share on other sites

I have tried opening the smarty debug console, but the only thing I get is a blank page with the error text "Notice: Undefined index: unifunc in /var/www/prestashop/tools/smarty/sysplugins/smarty_internal_templatebase.php on line 281 Fatal error: Function name must be a string in /var/www/prestashop/tools/smarty/sysplugins/smarty_internal_templatebase.php on line 281"

 

Edit: I guess the reason I don't get any smarty debug is because it's a fatal error that terminates the script before the Smarty error handling kicks in.

Edited by Nils-H (see edit history)
Link to comment
Share on other sites

I did a var_dump of the template properties before the error occurs:

 

array(3) { ["file_dependency"]=> array(0) { } ["nocache_hash"]=> string(0) "" ["function"]=> array(0) { } }

 

The next refresh (when it works again) is:

 

array(6) { ["file_dependency"]=> array(1) { ["b32cba648c10beabbf26f4192247c6999ea4d051"]=> array(3) { [0]=> string(73) "<install_dir>/prestashop/themes/<theme_dir>/modules/blocktopmenu/blocktopmenu.tpl" [1]=> int(1377872403) [2]=> string(4) "file" } } ["nocache_hash"]=> string(33) "17354004405220ab73f11865-10841594" ["function"]=> array(0) { } ["cache_lifetime"]=> int(31536000) ["version"]=> string(13) "Smarty-3.1.14" ["unifunc"]=> string(31) "content_522875e7f1d7b2_09093845" }

Link to comment
Share on other sites

Thats correct..  it's try -- catch block that catches undefined indexes.  this can be altered as posted in this thread : http://www.smarty.net/forums/viewtopic.php?p=78040&sid=096118edff12251044d5ef01fc6f1f12#78040

 

The reason for throwing an exception is because the var   $_template->properties['unifunc']  != string

If i look into smarty, it has to do something with the templates and merged ones...

Link to comment
Share on other sites

The catch block is not entered. I have verified that. It is aparently terminated before that because it's a "fatal error". 

 

When I do some more echo-ing in the script, it seems that it always encounter this error in my templates 'blockbestsellers.tpl' template. I have not verified if it also happens with the default template. However, I cannot find any substantial differences between the default and the theme version of this template.

 

Edit: It does indeed seem to be related to blockbestsellers. If I deactivate this module, the error disappears (at least in this exact scenario, after a configuration update). It didn't make any difference if I used the default template for the module, so it seems to be a general blockbestsellers issue.

 

Edit2: It also happens with the blocknewproducts. (Also with default theme)

 

Edit3: And also with blockcontact and blockmanufacturer

Edited by Nils-H (see edit history)
Link to comment
Share on other sites

×
×
  • Create New...