View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0004138||OXID eShop (all versions)||4.07. Source code, Test||public||2012-06-07 17:44||2014-11-20 08:33|
|Status||resolved||Resolution||unable to reproduce|
|Product Version||4.6.1 revision 45706|
|Target Version||4.8.5 / 5.1.5||Fixed in Version|
|Summary||0004138: _smartyDefaultTemplateHandler (oxutilsview) ist not compatible with PHP 5.4.x|
|Description||This small incompatibility avoids adding the message body to sendednow-mails from the backend, instead they will be blank. This is because PHP has slightly changed its behaviour with param references in function call_user_func_array, which is called in Smarty.class.php (line 1580). The problem is, now the param vars source_content and resource_timestamp aren't filled anymore.|
But it seems to be sufficient to extend the function definition in oxutilsview like this to solve the problem:
public function _smartyDefaultTemplateHandler($sResourceType, $sResourceName, &$sResourceContent, &$sResourceTimestamp, $oSmarty)
Please confim this or give us a better solution... :)
|Steps To Reproduce||- install and run demo shop on webspace with PHP 5.4.x|
- make a test order with your valid e-mail address
- open that order in the backend and send a "sendednow" e-mail to you
- the e-mail will be blank without any body content!
Before PHP 5.4, referenced variables in param_arr are passed to the function by reference, regardless of whether the function expects the respective parameter to be passed by reference. This form of call-time pass by reference does not emit a deprecation notice, but it is nonetheless deprecated, and has been removed in PHP 5.4. Furthermore, this does not apply to internal functions, for which the function signature is honored. Passing by value when the function expects a parameter by reference results in a warning and having call_user_func() return FALSE (there is, however, an exception for passed values with reference count = 1, such as in literals, as these can be turned into references without ill effects — but also without writes to that value having any effect —; do not rely in this behavior, though, as the reference count is an implementation detail and the soundness of this behavior is questionable).
|Tags||No tags attached.|
There is another more urgent problem caused by this bug:
You can't use module template files defined in metadata.php if your shop is running with PHP 5.4! And this also works again if you change the function declaration as described above. So please fix this asap! ;)
Things getting even more crazy:
I've accidentally found a completely different way to solve the first problem (sendSendedNowMail) which seems to be independent from PHP versions!
Simply add this line in oxemail after or nearby "$myConfig->setAdminMode( false );" (~ line 1070):
$oSmarty->template_dir = $myConfig->getTemplateDir(false);
Probably this line should also go into function sendDownloadLinksMail() because it has the same security exception logic inside.
And for the module template problem we can go the same way but it is not as easy to fix because there may be an infinite number of possible module names (IDs). So we can not fix this statically and every shop owner needs his own individual solution depending of the modules being used.
So I wrote a little module which provides an admin option for adding individual paths (comma seperated) to $oSmarty->template_dir but I guess this is too complicated to use for a normal shop owner. A much better solution would be a fully automated way to add these missing paths.
Please also have a look at these problems while running OXID in demo mode ($this->blDemoShop = 1)! This was the reason why I started analyzing some deeper because even if I added the mentioned parameter references I wasn't able to use module templates if OXID runs in demo mode.
||Related bug 0004586 was closed, leaving this one open to fully check issues with emails, thank you.|
||waiting for the PO decision.|
@Mitmacher: You are my hero!
After 2 over years I do not believe they gonna solve it.
Especially nobody cares about php 5.4 anymore... :-(
Hereby I ask for a statuschange.. I would like to suggest "never solved" ;-)
@jh.revier: what exactly do you mean? The bug was solved 2 years ago (see 0004586) and didn't caused trouble anymore. So the status could be changed to solved I think?
btw: I am afraid there are many shop owners who are still running their shops with PHP 5.2 + 5.3, so the 5.4-age may not have been really started until now (sad but true)... ;)
We checked this bug and we cant reproduce it. So the status of this bug is changed to resolved.