question about optimising the site and the documentation procedure

@Y0Coss

Hello

Why not use github hooks like pre-commit and or pre-merge to check the links / images and refuse the action if the hook output is not ok?

And depending on your hook, you can ensure that an irregular contributor will only be filtered by the pre-merge hook, so it's you who will receive the alert, whereas a regular contributor who knows the mechanisms will be filtered by the pre-commit hook and will even be warned before being able to commit. To do this, all you need to do is draw up a list of trusted contributors and, of course, make the hook accordingly.

Have you already run Selenium or Cypress type tests (for example) on your documentation site? You regularly have to refresh the page to access the kb ‘categories’.

This would indicate everything that is not :

• missing elements
• link error
• image loading error or to slow
• slow execution
• ...

Another question: why resize an image to 1400px max width? Personally I have a very large screen resolution (LG 22MD4KA-B UltraFine 4K Display 21.5" UHD 4096x2304) so when I click on an image it is smaller. Why not use the html picture tag and its source & srcset argument & default value?

example:

<picture>
 <source media="(min-width:650px)" srcset="img_pink_flowers.jpg">
 <source media="(min-width:465px)" srcset="img_white_flower.jpg">
 <img src="img_orange_flowers.jpg" alt="Flowers" style="width:auto;">
</picture>

Example: https://www.w3schools.com/tags/tryit.asp?filename=tryhtml5_picture just change the size of your browser

This allows you to define minimum/maximum widths or minimum/maximum heights and, depending on the device, load only the correct image.

There's a big difference between a smartphone/tablet and a computer.

Many markdown to html systems have this plugin

And you could only apply it in production by creating images resized according to your breakpoint css and thus keep your images in your documentation whatever their size.

No files, tests, or entry points are named. Start by reviewing the documentation build and contribution workflow, then assess the proposed hooks, Selenium or Cypress checks, and responsive image handling separately; done means the project has a decided, documented scope rather than several unresolved suggestions.