Don't have an account yet? You can create one, it is free, just click here
as a registered user you have some advantages like free downloads, comments and posting on our forums, depending upon this site's configuration and options.
While working on a new module I found quite a major limitation of the system
I have a file to be placed in the MDPro root for displaying recent RSS posts. This calls to a template within a modue using atSmartyDisplay.
When this is attempted a error is received from Smarty saying it's unable to read the resource. After a bit of debugging this has been tracked down to the file_get_contents_from_smarty function in atAPI.php the problem is due to using $script_path=$GLOBALS['SCRIPT_FILENAME']; since my calling function isn't inside a module the $_smarty_compile_path used in the smarty fetch function is:
I've modified this to check for any .php file that appears to be in the root, it all works fine for me, but Oleg will probably have to give it the once over
That way any .php file in the root will be stripped out of the $script_path statement before smarty tries to compile to an invalid directory
Also, I've found some problems with the usage of global $GLOBALS; which is used in atAPI.php. In certain installations I've found this seems to overwrite the $GLOBALS array with an empty array. There shouldn't be any need to declare $GLOBALS as a global as it's a superglobal that's accessible from anywhere. Just removing the global $GLOBALS; lines resolves the problem, but it will probably need testing on a few more systems
Took the time to benchmark these changes I'd recommended to file_get_contents_from_smarty.
I further optimized the preg_replace to match xxxx.php and \.. so no need for further str_replace's
Used ApacheBench on two test scripts, running 20,000 times on each:
My Version:
Time taken for tests: 47.640625 seconds
Existing MDPro Version:
Time taken for tests: 111.562500 seconds
The main reason for the slowdown is the explode statements. In the new version of atAPI, just use at_getScriptFileName instead. When I removed the explode statements the time for the MDPro version using str_replace took 71.95s to complete, so my version is 134% faster than the current version used in MDPro, and using one preg_replace is 51% faster than using multiple str_replaces
Both test cases and full results are attached, this version is now running at my site and I've not noticed any problems yet, so I've also attached the replacement version of atAPI.php but only the brave/experienced should give this a try as it simply hasn't been tested on enough systems to guarantee that it'll work in every configuration!
Forum FAQ
Search
Usergroups
Preferences
Options forum
Watched Topics
Latest forum posts
Log in to check your private messages
Log in
