-
Notifications
You must be signed in to change notification settings - Fork 379
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add a way to force early creation of the cache file #242
Comments
What exactly do you mean? Do you want to manually create the filtered images when saving/updating the original one? So you never get into creating the cached version on a request mentioned above? |
Right now the common case is:
I am talking about making it possible to force the creation of the cached image in step 1) |
+1 |
This would also stop multiple database queries. In step 1 the server may run queries on request. Eg the image path is requested from the database. In step 2 this query may have to run again to verify the path. |
right that is the idea .. when dealing with remote resources it might be more efficient to generate the cache file early without having to generate all possible cache files when the resources is created/updated |
Ok, let me try to sum this up and let's verify we are talking about the same. You got something (e.g. a model retrieved from a datasource) in your template. This model got an accessor on a related image path (e.g. a profile picture of a user). This code is reflecting the first step: <img src="{{ model.image|imagine_filter('thumbnail', true) }} " /> This will eventually call Basically the solution would be a new method combining |
Yes, I guess resolvers like Amazon S3 are one scenario. However often the model with the image itself (though as a stream) maybe already be fetched by the controller. So the gist of it there are cases where in the current setup the same resources needs to be fetched both in the request generating the html and the subsequent request for the actual image binary. for this case i proper adding another optional parameter to force cache generation right when the html is generated. |
I am not sure if this helps but i found a way around this by creating a new twig function - I was not able to pass on the PHPCR Image document as an argument to a filter I then implemented a service which has a lot of dependencies to liip imagine bundle basically saving me the work to generate thumbs using the existing filtermanager generating the thumbs at the time of the url generation should also allow us to invalidate cached thumbs more effective (document image creation time > thumbnail time) unfortunately the image Document has no updatedAt property so i cant effective invalidate the cache maybe its a good idea to have updatedAt added to Image in the future? i am pretty sure the LIIP wizzards have better insight into their bundle and this can be MUCH done better but maybe some of my thoughts and code might be useful :) <img src="{{ thumbnail(relatedPage.teaserImage,"cmf_111_63") }}" width="111" height="63" alt="{{ relatedPage.teaserTitle | striptags }}" / /**
/**
|
I am not sure but I think I have another use case. I want to serve my model via rest API and therefore have no access to the twig helpers. @havvg : you already pointed in the correct direction. I was trying to reverse engeneer the controller, but am slightly confused. Because in order to just eagerly store the thumbnail, I would not need the cacheresolver. It would probably make sense for other use cases, though. You said that this is the flow that needs to happen: Basically the solution would be a new method combining ResolverInterface::resolve, ResolverInterface::store and ResolverInterface::getBrowserPath. It's very similar to the ImagineController::filterAction but without the dependency of a Request. But how does the Cache and DataManger play a role in this? |
I have now a resquejob that basically is manually creating the Image. Performance is not too good. And I also did not really all the parts, how they play together. I am also unsure how to test this. I started writing a test but I would like to assert that the targetFile does not exist before the test is run and then assert that its there after the test, but I don't know how to do this. But here goes the Code of my Job: $resolver = $container->get('liip_imagine.cache.resolver.amazon_s3');
$dataManager = $container->get('liip_imagine.data.manager');
$filterManager = $container->get('liip_imagine.filter.manager');
$req = new Request();
$targetPath = $resolver->resolve($req, $path, $filter); // 1s
$image = $dataManager->find($filter, $path); // 7s
$response = $filterManager->get($req, $filter, $image, $path); // 0.003s
$response = $resolver->store($response, $targetPath, $filter); // 1s |
If anybody is still interested in this, the fix is actually quite easy to implement. The following code creates the image as soon as the filter is called. It's basically the same code as in the filterAction of the ImagineController.
Use it like this:
|
can you submit a PR for this? |
I can, but I'm not sure if it should actually be a separate command when being in the bundle. Maybe a flag on the current imagine_filter would be better. Something like "forceEarlyCreation" or similar. |
👍 on flag option. |
No flags, please. Just another filter, like |
@pscheit Is this something you are looking at? Given the eyes emoji. If not, I'd like to label this one as a "good first issue" and write some clear instructions what needs to be done. Let me know :) |
I was referring to: "Wow, this is still open lol".,. ;) I'm not using imagine anymore |
there is enqueue now and #1360 adds symfony messenger. |
I have to dig in an see if and how it would make sense exactly. But when reading from a remote data source it can make sense to generate the cache entry in the request that renders the image tag.
The text was updated successfully, but these errors were encountered: