somehow-digital / typo3-media-processing

"Media Processing" for TYPO3 integrates various image processing libraries and SaaS cloud services into TYPO3 by leveraging their APIs to process images.
https://somehow.digital
GNU General Public License v3.0
6 stars 1 forks source link

Extension isnt producing, but registering files in _processed_, which might break other extensions' output #4

Closed fgerards closed 1 year ago

fgerards commented 1 year ago

Your extension registers identifiers on processedFiles with a path like "processed/0/f....", but the MediaProcessor and its services dont produce any physical processed files there. While this is ok for the TYPO3 core's image rendering, extensions like c1_adaptive_images and its viewHelper for placeholder-images still rely on the pyhsical processedFile you register as identifier of the processsedFile, throwing an error.

Please implement a consistent behaviour. the identifier of a ProcessedFile would have to point to the imageKit URL too (which isnt possible with the cores processedFile model in 12 and 11). You would have to override the whole processedFile model to really be consistent i think.

thasmo commented 1 year ago

@fgerards, thanks for your input!

I've quickly installed c1_adaptive_images, set up a very simple image rendering example via the ai:image view helper and so far the output is something like this, which also renders/displays the images just fine:

<img class="img-responsive lazyload" sizes="100vw" srcset="http://imgproxy.typo3.local/g8oWoFgXVaoF91RywAs1ow/rt:force/w:128/c:744:744:nowe:599:479/cb:54fdc88aaa17b5996d6198508920b349ae03dfa9/plain/http://frontend/fileadmin/user_upload/image.jpg 128w" data-sizes="auto" data-srcset="http://imgproxy.typo3.local/4jIhSPQazpe3EUrDqRGOAA/rt:fit/w:320/c:744:744:nowe:599:479/cb:54fdc88aaa17b5996d6198508920b349ae03dfa9/plain/http://frontend/fileadmin/user_upload/image.jpg 320w,http://imgproxy.typo3.local/tmv_Sozqv4uDfxgCdDp1GA/rt:fit/w:640/c:744:744:nowe:599:479/cb:54fdc88aaa17b5996d6198508920b349ae03dfa9/plain/http://frontend/fileadmin/user_upload/image.jpg 640w" data-img-debug="1" src="[http://imgproxy.typo3.local/1koWDgxDCVGvte3TLTCQMA/rt:force/c:744:744:nowe:599:479/cb:54fdc88aaa17b5996d6198508920b349ae03dfa9/plain/http://frontend/fileadmin/user_upload/image.jpg](view-source:http://imgproxy.typo3.local/1koWDgxDCVGvte3TLTCQMA/rt:force/c:744:744:nowe:599:479/cb:54fdc88aaa17b5996d6198508920b349ae03dfa9/plain/http://frontend/fileadmin/user_upload/image.jpg)" width="745" height="745" alt="" />

No errors show up for me so far. Is there any specific view helper or a specific implementation you use which might throw errors in the scenario you describe?

Understandably there might be issues with non-core extensions or application-code because - as you mentioned - the identifiers do actually reference non-existent local files.

fgerards commented 1 year ago

hi, i was talking about the ai:placeholder.image viewhelper with the default "dataUri" set to true. this collects processed file-content from the TYPO3 local filesystem, which in this case isnt there.

thasmo commented 1 year ago

hi, i was talking about the ai:placeholder.image viewhelper with the default "dataUri" set to true. this collects processed file-content from the TYPO3 local filesystem, which in this case isnt there.

True. For now, in version 0.3.1, I've added an extension setting common.storage, which can be enabled to store processed images locally. This is disabled by default, because it slows down rendering of images, as this is not an async/deferred process for now. But it helps with extensions which need to read the processed files contents. Note that references/URLs to images in the generated markup will still point to the remote/service URL and not to the local file, so users get all the benefits those services offer (content negotiation etc.).

fgerards commented 1 year ago

Thx for implementing this possibility. Helps a lot.