Thanks for your replies. Well we are already using imagick, otherwise some large images wouldn't work at all. It's a real problem if the process times out as imagick is not properly cleaning up temporary files… (and those temporary files seem to be uncompessed image files…)
there was an external service that someone was using at #stripeconeu - let me see if I can find it. seemed like a good option for people where SS' built-in functionality isn't enough
yeah that 😛
Thanks 😉 We are looking for a self hosted solution. We have some sites using Thumbor (http://thumbor.org/) with rewriting image urls to point to the thumbor server. I was just wondering if someone has different approaches 🙂
Thumbor is a smart imaging service. It enables on-demand crop, resizing and flipping of images. It features a very smart detection of important points in the image for better cropping and resizing, using state-of-the-art face and feature detection algorithms (more on that in Detection Algorithms).Hide attachment content
The only thing I've done in the past was onAfterWrite on DataObjects that attach images, pre-generating the common sizes
you could potentially combine that approach with queuedjobs to run a queue that generates all the image sizes you use
that way you're not trying to generate too much within a single HTTP request
When I have a manymany relation and someone deletes the related DataObject, is it supposed to clean up the many_many relation table? Or do I need to remove the items from the ManMany relation manually?
by default, it doesn't clean up
you can set $cascade_deletes
but then it deletes the related items... In my case someone deleted on the belongs_manymany site; it didn't clean up; now if I add a new item and it accidently has an old ID it's automatically related to the old relations
a new object shouldn't get an old ID unless you've reset the auto_increment on the table
the DB maintains its own counter, it doesn't just take the highest ID and add 1 to it
(for MySQL/MariaDB anyway, I can't speak for other DBs)
seems it got an old ID after moving a DB to a new server (from test to live or so).
for the record: in delete(),
$this->ManyManyRelation()->removeAll() cleans up the relation table when deleting.
@Ed Linklater would you see this as a bug?
ah - gotta make sure you include auto_increment value of tables in your SQL dump
dunno if sspak or phpmyadmin do that by default
mysqldump command does it by default, which I think sspak uses
not sure about phpmyadmin though
but theoretically a hook to loop over all manymany relations and cleans up would be an improvement, wouldn't it?
in other ORMs it would be natural, but it kinda goes against the "playing it safe" nature of the SS ORM in my opinion
for the record, here is an old issue about it: https://github.com/silverstripe/silverstripe-framework/issues/5290 manymany through with cascade deletes would be the way to go
Quite some time ago there was some debate around cleaning-up intermediary relations when one or the other side of a ManyMany relation was deleted, for internal consistency. The arguments for this a...Hide attachment content
yeah, I think using the cascade deletes feature is best because that way it is developer-specified and not "magic" data deletion that the developer doesn't know about