Hello! I want to report a bug I found in the current version of i18n-subsites, that involves the mechanism that interlinks static files back to the main site.
Steps to reproduce
I have forked the project and updated the test data that was not working on Pelican 4.11. Notably, I replaced the {filename} links to static files (in translated_article-*.rst) with {static} links. Indeed, linking to static files with {filename} has been deprecated, according to the documentation. This is where the issue arises in i18n-subsites, I think.
git clone https://github.com/gjorando/i18n-subsites.git
git checkout ad7d1a5
Once the development environment is setup, run invoke update-test-data, then invoke tests. All tests should pass, but...
Expected behaviour
If we navigate to a subsite (say, de/), we should not see the images static directory, because static files in a subsite are linked back to the main site. And indeed, if we open the subsite's article file (de/translated-article.html), we should see that the link to the img.png static file links back to the main site's static path (../images/img.png, relative to the subsite).
Observed behaviour
If we check the output folder generated with the current version of the plugin, and navigate to a subsite (say, again, de/), there's an image folder with the img.png file, that should not be there. Worse, if we open the subsite's generated article, it links back to this copy (./images/img.png, relative to the subsite) instead of the main site's.
Proposed fix
In i18n_subsites.interlink_static_files, for each generator, we go through each static file from the main site. If said static file is not in the generator context, we add it, fixing its URL to point to the main site's static path. This seems fine, but what happens to static files from the main site if they already exist in the generator context? They are not modified at all, which means that their URL stays broken, pointing to a static file inside the subsite.
This would explain why the URL is incorrect in the generated article, but not why the static file gets copied to the subsite. The thing is, the StaticGenerator object holds a list of all static files that need to be copied to the output path, in its staticfiles attribute. If we don't remove the static file from this list as well, it gets copied to the subsite output directory anyways.
I implemented a really ugly patch in a personal project, but I think actually fixing it upstream is better? :)
Regards,
G.
Hello! I want to report a bug I found in the current version of i18n-subsites, that involves the mechanism that interlinks static files back to the main site.
Steps to reproduce
I have forked the project and updated the test data that was not working on Pelican 4.11. Notably, I replaced the
{filename}links to static files (intranslated_article-*.rst) with{static}links. Indeed, linking to static files with{filename}has been deprecated, according to the documentation. This is where the issue arises in i18n-subsites, I think.Once the development environment is setup, run
invoke update-test-data, theninvoke tests. All tests should pass, but...Expected behaviour
If we navigate to a subsite (say,
de/), we should not see theimagesstatic directory, because static files in a subsite are linked back to the main site. And indeed, if we open the subsite's article file (de/translated-article.html), we should see that the link to theimg.pngstatic file links back to the main site's static path (../images/img.png, relative to the subsite).Observed behaviour
If we check the
outputfolder generated with the current version of the plugin, and navigate to a subsite (say, again,de/), there's animagefolder with theimg.pngfile, that should not be there. Worse, if we open the subsite's generated article, it links back to this copy (./images/img.png, relative to the subsite) instead of the main site's.Proposed fix
In
i18n_subsites.interlink_static_files, for each generator, we go through each static file from the main site. If said static file is not in the generator context, we add it, fixing its URL to point to the main site's static path. This seems fine, but what happens to static files from the main site if they already exist in the generator context? They are not modified at all, which means that their URL stays broken, pointing to a static file inside the subsite.This would explain why the URL is incorrect in the generated article, but not why the static file gets copied to the subsite. The thing is, the
StaticGeneratorobject holds a list of all static files that need to be copied to the output path, in itsstaticfilesattribute. If we don't remove the static file from this list as well, it gets copied to the subsite output directory anyways.I implemented a really ugly patch in a personal project, but I think actually fixing it upstream is better? :)
Regards,
G.