[Amoifr]

Q	A
Branch?	2.x
Bug fix?	no
New feature?	no
BC breaks?	no
Deprecations?	no
Fixed tickets	#1608
License	MIT
Doc	yes

@dbu you said on #1608 that you were glad if somebody sorted it out and proposed fixes or documentation updates. Checking first, the code half is already done: AssetMapperLocator landed in 2.17.0 with #1645. What is left is the documentation, and it is what produced the confusion in the first place.

The reporter went to Asset Versioning because it promises the bundle handles versioning. That page covers framework.assets.version, which puts the version in a query string, and json_manifest_path, which puts it in a manifest. AssetMapper puts it in the file name, so neither integration applies to it and the page reads as if nothing had to be done.

What actually happens, as AssetMapperLocator's own docblock describes:

• in production, asset-map:compile writes the versioned files into the public directory, so the filesystem loader finds them like any other file. That is why running that command works around the problem, as @Schyzophrenic found in the thread;
• in development the versioned files do not exist on disk, since AssetMapper serves the assets from their source directory, which is where the Source image for path could not be found comes from, and what the asset_mapper data loader is for.

The page now says both, and links to the loader page.

While linking to it I noticed its title underline is one character shorter than the title, which makes Sphinx warn about it, so that is fixed here too.

[dbu]

i guess this only works for images that exist at container build time and that are referenced statically, not for any dynamic image loading. what happens when the asset mapper is active and we have dynamic images?

[Amoifr]

Thanks for looking at it @dbu! It is not tied to build time: AssetMapperLocator looks the path up in AssetMapperInterface::allAssets(), which walks the asset directories on every call, so an image added under assets/ in dev is found on the next request. It also matches whatever public path asset() generated, so nothing has to be referenced statically.

Dynamic images, like uploads, are not AssetMapper assets at all: they live outside its paths, never get a hash in their name, and keep being served by the filesystem loader from wherever they are stored, in dev as in prod. The mapper only matters for the images shipped with the code. I added a sentence saying so to the page.

[dbu]

finally getting back to this. thanks a lot!