View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0002931 | OXID eShop (all versions) | 2. ----- eShop backend (admin) ----- | public | 2011-05-24 14:04 | 2014-09-17 18:01 |
Reporter | dominik_ziegler | Assigned To | |||
Priority | high | Severity | minor | Reproducibility | random |
Status | resolved | Resolution | fixed | ||
Product Version | 4.5.0 revision 34568 | ||||
Fixed in Version | 4.5.10 revision 44222 | ||||
Summary | 0002931: Sporadic partial output in browser of oxpec_class_file_paths.php content | ||||
Description | Sometimes, especially in admin area, there is a partial output of the class location cache file in the browser, which disappears on next visit. Unfortunately I can not reproduce this bug because it occurs randomly. Perhaps developers can check from source code side if such issue exists. | ||||
Tags | No tags attached. | ||||
Theme | Both | ||||
Browser | All | ||||
PHP Version | any | ||||
Database Version | any | ||||
|
I have this every few clicks on my development machine, only with 4.5.0. |
|
i debuged it in a 4.5 because we got the error like every 1-4 clicks in admin and also partially in frontend. imho the problem is the shops file caching where file handles are opened in different modes to increase performance. after opening a file, the file pointer is set manually in some cases. this combined with the caching of the file handle itself causes the shop to overwrite an already build modules cache file (example: 10 lines) with a shorter data (example: 1 line) without deleting the files contents first. so the difference (in this case 7 lines+2 for php-code ) from the old file are still present after writing the new file. this will look so: <?php //automatically generated file //2011-05-25 14:41:34 $_aCacheContents = array ( 'oxclass' => 'path_to_azcustomclass.php', ) ?> 'oxclass' => 'path_to_azcustomclass.php', 'oxclass' => 'path_to_azcustomclass.php', 'oxclass' => 'path_to_azcustomclass.php', 'oxclass' => 'path_to_azcustomclass.php', 'oxclass' => 'path_to_azcustomclass.php', 'oxclass' => 'path_to_azcustomclass.php', 'oxclass' => 'path_to_azcustomclass.php', ) ?> so the output when including the file will be: 'oxclass' => 'path_to_azcustomclass.php', 'oxclass' => 'path_to_azcustomclass.php', 'oxclass' => 'path_to_azcustomclass.php', 'oxclass' => 'path_to_azcustomclass.php', 'oxclass' => 'path_to_azcustomclass.php', 'oxclass' => 'path_to_azcustomclass.php', 'oxclass' => 'path_to_azcustomclass.php', ) ?> a bugfix is possible, modifying the way the cache files are opened/file pointers are set. i wrote a patch but removed it due the risk of changing some internals that might crash the shop at other places (sorry, i dont have the code anymore) |
|
@developers: investigate this issue from source code side. |
|
can confirm that behaviour but only on windows php 5.3.6(xampp). And there ist a second behaviour(issue?). the paths are only written to the cache-file while you click around the backend. If you click within the frontend, the cache-file will cleared and not filled with the paths. Just click inside the backend and the paths are written to the file. |
|
Priority low, Severity tweak? If you run your local copy on Xampp this can drive you crazy. |
|
This problem still persist in 4.5.7. And it is very annoying! And it has high priority! Pls. move your ass and fix it asap! |
|
> Pls. move your ass and fix it asap! Excuse me, Sir? Please calm down and stay polite - same rules here for communication as everywhere in the community! Nevertheless, I changed the Prio and the Severity (for the first time ever in this entry!). |
|
modified oxUtils::commitFileCache() and added "ftruncate( $rHandle, 0 );" just before writing cache data to file |
|
We've modified oxUtils as described in the last note, but the problem has occured again (merely one time) while using the backend. The fix was applied nearly four weeks before this occurence, our backend is in daily use. - So it seems, there is still "something left". |
|
This type of cache periodically is causing more troubles than solves problems. I removed this type of cache until further decisions is made. |
|
I fixed it by removing (commenting) 2 lines in oxfunctions.php: 44: //$aClassPaths = oxUtils::getInstance()->fromPhpFileCache("class_file_paths"); 72: //oxUtils::getInstance()->toPhpFileCache("class_file_paths", $aClassPaths); |
|
We use OXID 4.52 EE - Is it possible for us to use the bugfix? |
|
Reminder sent to: welzel The fix is quite easy. See comment from Tomas Liubinas few notes above: "I fixed it by removing (commenting) 2 lines in oxfunctions.php:..." https://bugs.oxid-esales.com/view.php?id=2931#c6358 That should not be hard to apply the same fix on the 4.5.2 version |
|
welzel, yes you can apply the fix to 4.5.2 as well. |
|
Remaining references to oxeec_class_file_paths.php were removed with 5.2.0 RC1: https://github.com/OXID-eSales/oxideshop_ce/commit/66c8d33b68cad9a225747730e975b6958a1584b9 |