2 Dec 14, 2019 18:29
I have not come across this problem
Some images did not not load in pages. While checking how this happened, I discovered that the folders in files had been renamed - without me having done it myself.
The original graphic link
was changed by system to
Apart from the fact that the new mode of naming folders is counterproductive and confusing (too long etc.), the fact is that renaming the names of the folders without any alias (the original name) is really problematic.
I now have to check where this happened in my collections and what triggers the renaming. That is time consuming and not really effective. It is really annoying.
Recommendation: Either users can choose whether the folders are named as before (e.g. p230) or aliases are automatically added when the system renames folders.
I would be very pleased if you could take this into account and implement it.
Thanks and Regards, Will
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
[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
@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.
[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
[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.
[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
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
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
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
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:
quick-uploadsbefore 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
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.