I have not come across this problem

@saunders Are you using [image:12] tags or hardcoded <img src=... tags?

@fplanque I am using both tags, but normally short tags [image:12] or [thumbnail:12]. The problem seems to be independent from witch tags are used. I use hardcoded tags in case I want to link to e.g. a file for Download or link to the source of the image.

[thumbnail:12] references link with ID #12 and will always use the right path when the post is rendered. Now there might be an issue if a page is cached but this should be only a transient error.

Please temporarily disable page caching and clear your browser cache to verify if there are still errors on tags like [thumbnail:12] .

For downloading you should use [file:12] .

@fplanque thanks; towards using [file:12] - sometimes, because of copyright matters, I can't provide files via the collection, but have to link to an extern page or via deep link to the file.

Towards[thumbnail:12] - I mentioned this short tag because I used it together with [image:12] on those pages, where the related quick-upload folders were renamed; not because I supposed it as reason of the problem, but for the sake of completeness. The problem is [image:12]

towards using [file:12] - sometimes, because of copyright matters, I can't provide files via the collection, but have to link to an extern page or via deep link to the file.

Then it's irrelevant to the current issue.

Towards[thumbnail:12] - I mentioned this short tag because I used it together with [image:12] on those pages, where the related quick-upload folders were renamed; not because I supposed it as reason of the problem, but for the sake of completeness. The problem is [image:12]

Ok, show screenshots of front and backoffice + URL of one single example of one single issue where [image:12] does not show the file it is supposed to show.

@fplanque I tried to recover those cases, because I had taken the time to find each page which disappeared images to fixe this. I tried to do this by versions, without success. I then tried to rebuild the case.
Conclusion: I can rebuild the bug for this setting.

If I add a new image to the quick-upload bar, it is uploaded to a new folder that differs to the older one. As long as the edited page is not saved, in files I'll find both folders, the old one (/p305/) and the new one (/krempl-hochhaus-spinatbunker/). (fig.1.2) After saving the draft the old folder seems to be deleted. (fig.1.3) -The urls of all other Images switched to the new folder and the image of the old folder were copied to it.

But in case I used <img ...> (for example to define special width, hight, paddings etc.) the old folder name and url remains (https://linz.genba.org/media/blogs/linz/quick-uploads/p305/img_1374_712.jpg) - it gets a broken link because of renaming the folders.

This is what I can rebuild. May be all disappearing images are not coded as short tag [image:12], but as <img.

What is also problematic. I have linked to images of my collection pages from external sources, other blogs and microblogs. They also get broken links.

I do not quite understand why this change was necessary. Apart from broken links, the urls are now partly very long, which is not only confusing, but causes also disadvantages for SEO. The pictures in folders, named after the IDs of the pages, were much more conclusive.

May be all disappearing images are not coded as short tag [image:12], but as <img.

Ok, so you have the solution to your problem.

I have linked to images of my collection pages from external sources, other blogs and microblogs. They also get broken links.

Ok, I understand this use case. We should have redirects for moved images, the same way we have them for posts. I'll put that on the TODO list.

Temporary workaround: move your images OUT of the quick-uploads before linking to it from the outside. quick-uploads must not be considered as a stable structure.

I do not quite understand why this change was necessary.

Because there were folders with thousands of meaningless subfolders.

Apart from broken links, the urls are now partly very long,

Only if your slugs are too long.

which is not only confusing,

No, having a clear name of the post is LESS confusing thhan p1234.

but causes also disadvantages for SEO.

No, that makes no sense at all.

First, the new URLs better describe the images.

Then, if you really want to optimize the URL of your images for SEO:

1. Start by optimizing the slug of your POST. This will automatically optimize the URL of the images.
2. If you want to optimize furthermore, you should definitely move them OUT of quick-uploads before linking to them.

@fplanque I use hardcoded <img src=... tags in case I don't want to have those images added to the mediaidx. This is up to now the only way to customize, what should be added to the mediaidx. (Image that won't be shown on the page but should be seen in mediaidx are added to the page (inline) but not linked. It's pretty inconvenient, but a workaround) See also https://forums.b2evolution.net/media-index-how-to-include-images-from-linked

@suanders
Thanks for

I use hardcoded <img src=... tags in case I don't want to have those images added to the mediaidx.

Now I see why I have so few that show via mediaidx :) I hardly ever use it, almost always the html img tag.