View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0006179 | module PayPal Plus | module PayPal Plus - sub | public | 2015-06-29 17:03 | 2016-07-20 14:30 |
| Reporter | d3 | Assigned To | |||
| Priority | normal | Severity | minor | Reproducibility | sometimes |
| Status | resolved | Resolution | fixed | ||
| Product Version | 1.0.1 | ||||
| Summary | 0006179: oxpsPayPalPlusOxViewConfig use parent attribute | ||||
| Description | Class oxpsPayPalPlusOxViewConfig extends oxViewConf. There is already a "protected $_oShop = null;" in oxViewConf declared. This causes an exception in the frontend "Function 'getPayPalPlusConfig' does not exist or is not accessible! (oxShop)". best reagards KH | ||||
| Steps To Reproduce | Solution: get a separated name: /** * OXID eShop methods wrapper instance. * * @var null|oxpsPayPalPlusShop */ protected $_oPaypalShop = null; /** * Get OXID eShop wrapper. * * @return oxpsPayPalPlusShop */ public function getPayPalPlusShop() { if (is_null($this->_oPaypalShop)) { $this->_oPaypalShop = oxpsPayPalPlusShop::getShop(); } return $this->_oPaypalShop; } | ||||
| Tags | Exception, oxViewConf, Paypal Plus | ||||
|
|
Module version 1.0.1 Shop version CE 4.7.5 |
|
|
if you use this code snippet: /** @var $oViewConfig oxViewconfig * */ $oViewConfig = oxNew('oxViewconfig'); $oShop = $oViewConfig->getShop(); Which object is loaded in $oShop? Which object should be in $oShop? best regards Kristian |
|
|
Tested with current Version 1.0.5 and current shop version. Issue is not reproducible. |
|
|
Test it with this code: /** @var $oViewConfig oxpsPayPalPlusOxViewConfig * */ $oViewConfig = oxNew('oxViewconfig'); $oViewConfig->setViewShop(oxnew('oxshop'), array()); $oShop = $oViewConfig->getShop(); $oShop->getPayPalPlusConfig(); // Exception KH |
|
|
The way I see it the problem shows up as soon as a SECOND module is using the protected class variable $_oShop. Due to this we have the company coding rule: > In cases a class is extended from an OXID class (it appears in the extend section of the metadata.php) - AND ONLY THEN - every class variable needs the prefix em, IF the function is protected or public. In cases a class is extended from an OXID class, additionally the technical name of the module/extension has to be part of the name. < The individual prefix in combination with the name of the module (PayPal or better PayPalPlus as suggested from d3) prevents the conflict. To only call it $_oPayPalShop is still not save, because there could be a conflict with another third-party PayPal extension (if they don't add their two-char company ident either). So the save name for OXID would be: $_oOxPayPalPlusShop or similar |
|
|
The bug still exists in paypal plus module version 2.0.1. I had the same exception in a live shop (oxid version 4.9.7 with several modules). I used the workaround/solution mentioned above. When there will be a bugfix in the paypal plus module? |
|
|
PayPal Plus version 2.0.3 was released which solves the issue http://exchange.oxid-esales.com/de/en/Bestellprozess-und-Versand/Bezahlung/PayPal-PLUS-2-0-3-Stable-EE-PE-4-9-x-5-2-x.html |
