By default, on frontend $overwrite is false. Backend function installFromUpload
/ installFromURL will have a default of true to preserve existing behavior for
other API users.
installArchive now will insert a frontend msg() about not installing because of
overwrite restriction. It's not being exposed by exception, but it should be
reflected on its return array list of installed plugin.
This fixes#715.
The $conf['fperm'] value was checked in multiple files using different methods.
This can cause permission trouble with restricted environments, i.e. when chmod is forbidden and file permissions are non-default.
Now, all checks use implicit cast to boolean which leads to consistent behaviour.
Also, a misleading variable was renamed in context to better understand one of the checks.
There is no need for this check, since these files should not have any
main code that is executed on direct call.
Fixes PSR1.Files.SideEffects.FoundWithSymbols
Resolves#1192
`/lib/plugins/<plugin>/deleted.files`
which list files that can be removed e.g.
```
# This is a list of files that were present in previous plugin releases
# but were removed later. An up to date plugin should not have any of
# the files installed
action.php
folder/file.txt
```
In an older version of PHP a file_exists() call would issue a warning
when the file did not exist. This was fixed in later PHP releases. Since
we require PHP 5.3 now, there's no need to supress any error here
anymore. This might even give a minor performance boost.
The filename found in the URL will be used for old plugins missing a
base entry in their plugin.info.txt and lacking a subdirectory inside
the archive as well. This patch makes sure possible query strings aren't
included in the filename.
Note: io_download() will also try to get a filename from any
content-disposition header.
If no filename can be found we simply use an md5 sum of the URL and hope
the plugin will contain it's own hint for naming.
Andreas Gohr