serialize() can return output with null bytes and other
non-text data. The prior behavior truncated data
which later results in unserialize() errors.
This happens when e.g. caching an object with a private field
or when caching e.g. a JPEG file (starts with 0xFFD8FFE1)
Fixes errors such as e.g.:
unserialize(): Error at offset 20 of 24 bytes at caches/SQLiteCache.php line 51
* refactor(cache): extract and encapsulate cache expiration logic
* fix: logic bug in getSimpleHTMLDOMCached
* fix: silly me, index should of course be on the key column
* silly me again, PRIMARY keys get index by default lol
* comment out the delete portion in loadData
* remove a few log statements
* tweak twitter cache timeout
* refactor
* fix: bug in previous refactor
* chore: exclude phpcompat sniff due to bug in phpcompat
* fix: do not leak absolute paths
* refactor/fix: batch extensions checking, fix DOS issue
This fixes a future problem when code is placed under a namespace because `get_class($bridge)` will then return e.g. `RssBridge\Bridge\TwitterBridge` instead of the the current value `TwitterBridge`.
Also a bit refactoring of `Configuration.php`.
The configuration files are currently hard-coded in the configuration
classes and error messages. However, the implementation should not
rely on specific details like the file name. Instead, the files should
be part of the global definition.
This commit introduces two global constants for the configuration files
- FILE_CONFIG => 'config.ini.php'
- FILE_CONFIG_DEFAULT => 'config.default.ini.php'
- 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).
