-
-
Notifications
You must be signed in to change notification settings - Fork 478
Add missing prefixes to filenames of downloadables #1650
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
The system that copies the standard downloadable files to the "resources" folders identifies them by a file suffix which starts with `-` (e.g., `*-schematics.pdf`). These files were missing the standard `<sku>-` prefix and thus did not match the pattern and were not copied to the "resources" folders. The website infrastructure has a system for handling files not covered by the "resources" system. However, unlike the resource downloadables file copying system of the `arduino/docs-content` repository, the website generator's system doesn't include the `-` in the file suffix patterns it uses to identify the resource files. This means that if a downloadable file has a name matching the resource filename pattern, but without the `-`, then it slips through a gap between the two systems and the download link on the website for these files will be broken. This is fixed by adding the standard prefix to the filenames of the resource downloadables. Even though the mismatch between the resource downloadable file identification code in the two systems is a bug, a differentiating prefix on the filenames is also required to avoid collisions in the resources folder so this change is beneficial even after the bug in the infrastructure is fixed.
The established convention is to use a prefix with the form `<sku>-` in the filenames of the downloadables. This sort of unique prefix is mandatory for the "resource" downloadables. It is not mandatory for the non-"resource" downloadables, but consistency with the established conventions is beneficial regardless.
Hello Per! I am adding @Matteo-it as the main reviewer of this PR, since he is working on the next version of Docs.
Thank you! ⭐
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Hey @per1234 and @sebromero. As mentioned in the previous message, I wanted to wait until @Matteo-it had time to preview this PR. Why was this merged before that happened?
No problem, will check directly in the active branch for Docs 2 - if i notice problems i will ask!
What This PR Changes
Add Mandatory Prefixes
The system that copies the standard downloadable files to the "resources" folders identifies them by a file suffix which starts with
-(e.g.,*-schematics.pdf):docs-content/.github/workflows/deploy-prd.yml
Lines 31 to 34 in afad791
The website infrastructure has a system for handling files not covered by the "resources" system. However, unlike the "resource" downloadables file copying system of the
arduino/docs-contentrepository, the website generator's system doesn't include the-in the file suffix patterns it uses to identify the resource files (seesrc/components/product/ProductResources.js:65-109in that private repo). This means that if a downloadable file has a name matching the resource filename pattern, but without the-, then it slips through a gap between the two systems and the download link on the website for these files will be broken.Some of the "resource" downloadable files were missing the standard
<sku>-prefix and thus did not match the pattern and were not copied to the "resources" folders. This causes the "Schematics" links on those product pages to lead to a 404 page instead of downloading the schematics as expected:This is fixed by adding the standard prefix to the filenames of the resource downloadables.
Add Non-Mandatory Prefixes
Although a unique dash-separated prefix is mandatory for the "resource" downloadables, it is not mandatory for the non-"resource" downloadables. However, consistency with the established conventions is beneficial regardless so I also propose the addition of this prefix to the filenames of the non-"resource" downloadables that don't have any prefix.
Additional Context
Even though the mismatch between the resource downloadable file identification code in the two systems is a bug, a differentiating prefix on the filenames is also required to avoid collisions in the resources folder so this change is beneficial even after the bug in the infrastructure is fixed.
Contribution Guidelines