--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To view this discussion on the web visit https://groups.google.com/d/msg/silverstripe-dev/-/fUjsQQnfEPAJ.
To post to this group, send email to silverst...@googlegroups.com.
To unsubscribe from this group, send email to silverstripe-d...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/silverstripe-dev?hl=en.
I don't think we need to protect against FTP uploads. If you upload a
file via FTP you are usually also able to delete or replace it. The
problem with the current state is that a user can upload a file that
crashes SilverStripe. If he does not have FTP access, there is no way to
delete it again.
--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to silverstripe-d...@googlegroups.com.
To post to this group, send email to silverst...@googlegroups.com.
Visit this group at http://groups.google.com/group/silverstripe-dev.
For more options, visit https://groups.google.com/groups/opt_out.
I can't really see any way around it though. I don't think you can actually strip the EXIF data with PHP, just resave the image without it. You couldn't really force that, though, as you'd have to resave every image as it's uploaded, as well as when they're 'synced' from asset admin. That aside, there's the quality loss from resaving the image to contend with as well.
Unless I'm mistaken, GD doesn't support handling EXIF data - so any generated images should have the data stripped. The only exception would be if you called, for example, $SetWidth(500) on an image that was already 500px wide, so it wouldn't be processed.
I can't really see any way around it though. I don't think you can actually strip the EXIF data with PHP, just resave the image without it. You couldn't really force that, though, as you'd have to resave every image as it's uploaded, as well as when they're 'synced' from asset admin. That aside, there's the quality loss from resaving the image to contend with as well.
I think we need to separate out the idea of a lock file and just a way of knowing if the file is available or can be resized.
Perhaps with a local image library it can be implemented with lock files, but that doesn't necessarily need to be the name of the function.
If we use a service the image may already be in a process queue for resizing so we'd want a function that would prevent another resize request, but it wouldn't be by querying a lock file.