- For consistency, functions should always return null on non-existing data.
- WordPressPluginUpdateBridge appears to have used its own cache instance in the past. Obviously not used anymore.
- Since $key can be anything, the cache implementation must ensure to assign the related data reliably; most commonly by serializing and hashing the key in an appropriate way.
- Even though the default path for storage is perfectly fine, some people may want to use a different location. This is an example how a cache implementation is responsible for its requirements.
- Do not add spaces after opening or before closing parenthesis
// Wrong
if( !is_null($var) ) {
...
}
// Right
if(!is_null($var)) {
...
}
- Add space after closing parenthesis
// Wrong
if(true){
...
}
// Right
if(true) {
...
}
- Add body into new line
- Close body in new line
// Wrong
if(true) { ... }
// Right
if(true) {
...
}
Notice: Spaces after keywords are not detected:
// Wrong (not detected)
// -> space after 'if' and missing space after 'else'
if (true) {
...
} else{
...
}
// Right
if(true) {
...
} else {
...
}
json_encode causes high memory footprint on large input data,
where serialize is less problematic.
Example: When using AcrimedBridge items contain pictures in
raw format (entire picture) which leads to a file size of about
2MB using serialize. json_encode will allocate about 98MB of
memory for encoding, causing memory exhausion errors (PHP
allows for 128MB of memory by default)
PHP operator '===' is the only strict way to mix up the value '0' and
the value 'FALSE'.
The function saveData of the FileCache tests if the write of the cache
files was done with success and raise an Exception if not. The test was
done without the '===' operator, and if the data is 0 bytes long the
error message says there is a permission error, which is false.
A data 0 bytes long is another issue, either in the json_encode function
either in the Bridge, but not a permission issue.
JSON format does not serialize object instances, which we don't
want anyways, and improves readability. The hashing algorithm
changed to md5 to prevent collisions with existing cache files
There is no need to check the absense of the parameters in
all functions. Instead 'getCacheName' is the only function
actually using the parameters and thus should check the
availability.
Previously the cache file name was build on the original request URI
which also included the parameters. This could result in different
file name for the same request (different format). Removing the format
from the request is already done in index.php and could lead to issues
in the future (if new parameters are introduced).
The function 'prepare' previously implemented in CacheAbstract
is specifically required for FileCache and thus belongs to FileCache.
Since this change removes all code from CacheAbstract, it can be
removed completely.
Previously for each requested format a new cache file was created,
though the data is the same. With this the file name no longer depends
on the requested output format.
