Including handling in OC_Image
But also a preview provider
Of course only works if your php actually supports webp
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
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>
* introduces a new IRootMountProvider to register mount points inside the root storage
* adds a AppdataPreviewObjectStoreStorage to handle the split between preview folders and bucket number
Ref #22033
Signed-off-by: Morris Jobke <hey@morrisjobke.de>
* `php occ preview:repair` - a preview migration tool that moves existing previews into the new location introduced with #19214
* moves `appdata_INSTANCEID/previews/FILEID` to `appdata_INSTANCEID/previews/0/5/8/4/c/e/5/FILEID`
* migration tool can be stopped during migration via `CTRL+C` - it then finishes the current folder (with the previews of one file) and stops gracefully
* if a PHP memory limit is set in the `php.ini` then it will stop automatically once it has less than 25 MiB memory left (this is to avoid hard crashes in the middle of a migration)
* the tool can be used during operation - possible drawbacks:
* there is the chance of a race condition that a new preview is generated in the moment the folder is already migrated away - so the old folder with the newly cached preview is deleted and one cached preview needs to be re-generated
* there is the chance of a race condition during access of a preview while it is migrated to the other folder - then no preview can be shown and results in a 404 (as of now this is an accepted risk)
Signed-off-by: Morris Jobke <hey@morrisjobke.de>
Else the number of files can grow very large very quickly in the preview
folder. Esp on large systems.
This generates the md5 of the fileid. And then creates folders of the
first 7 charts. In that folder is then a folder with the fileid. And
inside there are the previews.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
To continue this formatting madness, here's a tiny patch that adds
unified formatting for control structures like if and loops as well as
classes, their methods and anonymous functions. This basically forces
the constructs to start on the same line. This is not exactly what PSR2
wants, but I think we can have a few exceptions with "our" style. The
starting of braces on the same line is pracrically standard for our
code.
This also removes and empty lines from method/function bodies at the
beginning and end.
Signed-off-by: Christoph Wurst <christoph@winzerhof-wurst.at>
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>
Fixes#17828
* Modified the preview provider to provider smaller fonts for the
previes (so it is not so screaming)
* Modified the sidebar to show plain text and markdown files full size.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
Signed-off-by: npmbuildbot[bot] <npmbuildbot[bot]@users.noreply.github.com>
* 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>
To allow us to create previews of files stored in appdata we need to
construct the view differently.
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>
- implement isAvailable
- run tests only if ImageMagick with HEIC support is available in the
environment
Signed-off-by: Sebastian Steinmetz <me@sebastiansteinmetz.ch>
Exporting all pages of a document to a PDF is a waste of time. All we
need is a thumbnail of the first page anyway. Plus, reading that PDF
(even just the first page of it) into imagick is presumably much
slower than reading a simple PNG.
Signed-off-by: Tor Lillqvist <tml@collabora.com>
Fixes#9469
When a version of a file is restored the previews are no longer valid.
Thus we should remove them so they are regenerated.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
This code had the potential to time out. If a huge folder with pictures
for example was deleted then this could easily grow the number of files
to clean with a factor 5 (or more).
Now the previews just get cleaned up in the background. Which is good
enough for the 99% case
As a bonus this now also keeps the previews when in the trashbin so you
don't have a spiking server load when a user opens the trashbin view.
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>
* Fixes#2739
It tries to create an image from an SVG file. Which we don't support. So
this fails and prints an log line. Then we fall back anyways to the 404
and fetch the default icon.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
The owner of a federated file is the federated user. For which we
obviously can't setup a view.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
