View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0006699 | OXID eShop (all versions) | 2.3. Extensions (modules, themes) | public | 2017-09-25 14:06 | 2024-05-16 10:31 |
| Reporter | AlexN | Assigned To | |||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Product Version | 4.10.4 / 5.3.4 | ||||
| Fixed in Version | 7.0.0 | ||||
| Summary | 0006699: Two issues with the serialized basket | ||||
| Description | In my case I have extended oxBasketItem to override the method getTitle(). 1) Changes to an extended oxBasketItem class does not take effect when a shop user added articles to the basket already Let's say a user is browsing the shop and added articles to basket already. Then a module extending oxBasketItem is activated which displays the title different. For example no "varselect" as in my case. The user won't see the updated title unless he removes every article and re-adds them. 2) Validation the basket fails when deactivating a module which extends the basket As long as the module is active, shop users can browse the shop without problems. However, should the module be deactivated and a shop user tries to open any frontend page following message is returned to the user: --- Fatal error: oxSession::_validateBasket(): The script tried to execute a method or access a property of an incomplete object. Please ensure that the class definition "TroFlow_Model_TroOxBasketItem" of the object you are trying to operate on was loaded _before_ unserialize() gets called or provide a __autoload() function to load the class definition in [...]/core/oxsession.php on line 639 | ||||
| Steps To Reproduce | 1) Changes to an extended oxBasketItem class does not take effect when a shop user added articles to the basket already - create a new module which extends oxBasketItem and overrides method getTitle - open the shop and add an article to the basket - activate the module in the backend - reload the basket page --> you should not see the changed title 2) Validation the basket fails when deactivating a module which extends the basket - remove the article from basket - add a new article to the basket --> you should see the new title now - deactivate the module - open any shop page --> you should receive a message like in the description | ||||
| Tags | Basket, Module, Session | ||||
| Theme | Not defined | ||||
| Browser | Not defined | ||||
| PHP Version | Not defined | ||||
| Database Version | Not defined | ||||
|
|
The general reason for this is a legal requirement: Once the customer put something into the basket there are very strict requirements if the content should be changed by the shop owner (UWG, reliable information for the customer that he saw when putting things in). That is why the basket was persisted in a similar way as the final order (which is even more protected by law). We made some changes and will also iterate on this, but for the time being you need to clear our ALL baskets when changing something there. Be aware that this might annoy your customers as well. So you need to think very thoroughly before changing the basket in any way. |
|
|
@AlexN: Thank you for your report. We discussed this with our Core Team, and there really is little we can do about baskets getting lost right now. We will refactor this part in the future, and we made the deserialization code now failsafe, but the basic problem still remains: If you change the class for the basket or the basket items, PHP is no longer able to deserialize objects that were serialized with a previous version of the class. So now you will still lose the basket after such a change, but you don't get a fatal error anymore. If you know about this kind of change beforehand, you could try to entice your users to save their basket into the database, but there are legal restrictions. You won't be able to force them. In case this is a really bad problem for you, you could also think about replacing the serializing and deserialization into something like a json format or similar that can be both used by the old and the new class. |
