View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0006109 | OXID eShop (all versions) | 4.08. Cache | public | 2015-04-02 15:55 | 2022-02-01 13:55 |
| Reporter | henrik.steffen | Assigned To | |||
| Priority | normal | Severity | feature | Reproducibility | always |
| Status | closed | Resolution | open | ||
| Product Version | 4.9.3 / 5.2.3 | ||||
| Summary | 0006109: Re-indexing the category tree from back-end should automatically clear the Default Cache Backend | ||||
| Description | We have recently had a merchant with some corrupt data in his oxcategory list.... the nested sets were somehow mixed up, some oxleft/oxright values were disordered. I've seen this sometimes before happening even for other merchants, and usually the function "Re-Index Category Tree" in the back-end Category Adminstration helps. However, I've noticed, that when the Default Cache Backend is active, this won't help you all the way, unless deleting the Default Cache Backend afterwards manually. But who knows this? It's not documented anywhere. This is because the corrupt oxleft/oxright values are also being saved in the cache-folder for each category in a file like this: oxcategory_0f4f08358666c54b4fde3d83d2b7ef04_1_de.cache And the next time when you edit one of these categories in the shop-admin back-end, OXID will load parts of the object directly from the Default Cache Backend cache (and not from mysql), so when hitting the save-button, user will actually save the corrupt oxleft/oxright data back into the mysql tables, and we have corrupt nested sets again. In my opinion, when using the "Re-Index" function, you shold automatically trigger a cache cleaning dependency event. This would be more comfortable. Or at least a hint in the confirmation popup, where it says: ATTENTION: This function can delete categories - backup before execution! you could add: Don't forget to purge your default cache backend after execution! | ||||
| Steps To Reproduce | 1. set up a fresh EE 5.2.3 2. enable default cache backend (on filesystem) 3. browse to category "Kiteboarding" 4. in cache folder a file oxcategory_943a9ba3050e78b443c16e043ae60ef3_1_de.cache has been created 5. edit this file to simulate a corrupt nested set by changing this "OXLEFT";s:1:"1"; into this: "OXLEFT";s:1:"5"; 6. go to oxid admin back-end and edit category Kiteboarding, you don't actually have to change anything, just hit the save button 7. you can see that the position of the category name in the admin-list above changes 8. if you check mysql table oxcategories, the category Kiteboarding now has the invalid OXLEFT value of 5. The nested set is broken. 9. go and re-index the category tree 10. database nested set is repaired 11. go edit the category again in oxid admin back-end, just hit save, and the nested set in mysql table is broken again | ||||
| Tags | Cache, Category, Enterprise | ||||
| Theme | Azure | ||||
| Browser | All | ||||
| PHP Version | Not defined | ||||
| Database Version | Not defined | ||||
|
|
I simulated corrupt nested sets by changing the value in the database. Changing the cache file doesn't work for me. So step 5 would be: 5. change oxleft value for categorie "Kiteboarding" to 5. SQL: UPDATE `shop`.`oxcategories` SET `OXLEFT` = '5' WHERE `oxcategories`.`OXID` = '943a9ba3050e78b443c16e043ae60ef3'; |
|
|
Just changing an oxleft value in the database will not help, because then re-indexing will simply to the job, and you will never have a corrupt cache-file. Here is a way, how you can edit the cache file: The challenge when editing cache files is to preserve the timestamp of last modification to be in the future. If the timestamp changes after saving to the current date, the file will be considered expired and thus be ignored. This can easily be achieved by first editing the file and then executing a command like this before performing step 6. above: touch -r oxcategorytree_1_de.cache oxcategory_943173edecf6d6870a0f357b8ac84d32_1_de.cache where oxcategorytree_1_de.cache is a usually existing file in the cache folder and where oxcategory_943173edecf6d6870a0f357b8ac84d32_1_de.cache is the cache-file you just edited. This will copy the modification timestamp of the first file to the second file. |
|
|
The Issue is no longer reproducible. So this issue gets closed. QA -SG- |
