Currently if the following situation happens
Server generates preview
Server has command removed which allows a preview to be shown
Client asks for preview, gets a 404 error when preview exists
(Mime checked before preview)
This happens more often with documents, or video as the commands are not
native PHP, they require a binary on the server.
After the fix the following would happen
Server generates preview
Server has command removed which allows a preview to be shown
Client asks for preview, gets preview which has been generated
(Mime checked after preview)
This would also allow offline generation (for example a docker image
containing the extra binaries), allowing a reduction in attack surface
of the instance serving the preview data.
Signed-off-by: Scott Dutton <scott@exussum.co.uk>
by allowing the generation of multiple previews at once we save on having to find, open and decode the max-preview for every preview of the same file
the main use case for this is the preview generator app (pr for that comming next)
in my local testing this saves about 25% of time when using the preview generator app
Signed-off-by: Robin Appelman <robin@icewind.nl>
* Order the imports
* No leading slash on imports
* Empty line before namespace
* One line per import
* Empty after imports
* Emmpty line at bottom of file
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
The main use case here is storage provided versioning where we dont have
separate file ids for all the versions, by allowing a prefix for the
version we can store separate previews for all the versions.
Additionally, by keeping all the version previews in the same folder as the
"normal" previews they will be cleaned up properly when the file is deleted
Signed-off-by: Robin Appelman <robin@icewind.nl>
the main difference is passing the `File` object to the provider
instead of a `View` + path
Old providers will still continue to work as before
Signed-off-by: Robin Appelman <robin@icewind.nl>
Before we'd round up all preview request to their nearest power of two.
This resulted still in a lot of possible images. Generating a lot of
server load and taking up a lot of space.
This moves it to previews to be powers of 4: 64, 256, 1024 and 4096
Also the first two powers are always skipped (4, 16) as it doesn't make
sense to generate previews for that.
We cache preview pretty agressively and I feel this is a better
tradeoff.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
Else if a preview provider is registerd but not available (for example
missing support in some external lib). It will do 💥. This way the
providers can at least do the sanity checks required.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
* delete it
* throw a NotFound Exception
- This should a proper 404 to the user
- Next time it is then regenerated
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
* IImage::crop/preciseResize now have type hinting for integers
* found while testing strict typing for PHP 7+
Signed-off-by: Morris Jobke <hey@morrisjobke.de>
With HiDPI screens. And even normal HD screens you want more detail from
your pictures. Or the ability to somewhat zoom on you previews. For this
we need somewhat larger previews.
Moving the default to 4096x4096 is a step up. Users that want the old
behavior can still set the values in config.php
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
Throw proper exception if we can't get the mimetype for a preview. Catch
it later on so we can just return a not found for the preview.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
For legacy reasons we stored all the previews with a png extention.
However we did not put png data in them all the time.
This caused the preview endpoints to always report that a preview is a
png file. Which was a lie.
Since we abstract away from the storage etc in the previewmanager. There
is no need anymore to store them as .png files and instead we can use
the actual file extention.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
If you request a preview of X by Y. And after calculating X and Y are
equal to maxWidth and maxHeight then there is no reason to create a
preview of that size.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
Christoph Wurst
Scott Dutton
Morris Jobke
Elijah Martin-Merrill
Roeland Jago Douma
Robin Appelman
John Molakvoæ (skjnldsv)
Roeland Jago Douma
Jan-Christoph Borchardt