Skip to content
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

footer updates not showing up #524

Open
shawna-slh opened this issue Dec 6, 2023 · 8 comments · Fixed by w3c/wai-website#383
Open

footer updates not showing up #524

shawna-slh opened this issue Dec 6, 2023 · 8 comments · Fixed by w3c/wai-website#383
Assignees

Comments

@shawna-slh
Copy link
Contributor

pull request

new footer in preview

missing from published resource footer

@iadawn before we announce this, I'd like to get this fixed. Maybe we ask for Remi (or Howard) to look into it?

@remibetin
Copy link
Member

@shawna-slh I know how to fix. Will open a PR in the next 5 min.

@remibetin
Copy link
Member

remibetin commented Dec 6, 2023

@shawna-slh @iadawn Here is the PR to fix this: w3c/wai-website#383

_config.yml in "local" repositories is only used in previews. Changes have to be made in wai-website repo to appear on live website.

@remibetin
Copy link
Member

@shawna-slh
Copy link
Contributor Author

@remibetin (cc @iadawn) It would be easier if the footer info lived in the repo with the document. What about removing the ‘footer’ entirely from the config.yml in the wai-website repo?

@shawna-slh shawna-slh reopened this Dec 6, 2023
@remibetin
Copy link
Member

remibetin commented Dec 6, 2023

@shawna-slh
The benefit today is footer content is declared at "collection" level, meaning it is automatically displayed on all subpages.

We would probably have to declare (and update) footer content in each page frontmatter if we want this info to live in this repo. I am not sure it is better.

cc @iadawn

@iadawn
Copy link
Contributor

iadawn commented Dec 6, 2023

That is problematic since all subpages may not be part of the same resource. Additionally, this approach makes it harder to check and less 'findable'.

My strong preference is for this to be declared in the _config.yml of the resource as a default. This can be overridden in specific parts of the resource by including altered content in the header YML.

@remibetin
Copy link
Member

That is problematic since all subpages may not be part of the same resource. Additionally, this approach makes it harder to check and less 'findable'.

Maybe the phrase "subpages" is misleading. To be more specific, a "Jekyll collection" has been used for this resource. All pages in "_policies" folder share common default attributes declared in _config.yml (layout, footer, parent, permalink pattern, etc.). If a page in this repo is not part of this resource it should not be added in _policies folder.

My strong preference is for this to be declared in the _config.yml of the resource as a default.

Unfortunately, to the best of my knowledge, the _config.yml file in a child repo does not represent the _config.yml file of the resource. It represents the _config.yml file that is used in this repo to generate the Netlify preview, but is totally ignored when building the live website. There is only one global _config.yml file used for the live website, located in wai-website repo.

I think of two main options: (feel free to add a new one!)

  • If having a common footer in all country listings is relevant, keep it in _config.yml. Note: it is probably tricky to translate there... This can be overridden by including footer attribute in page frontmatter.
  • If it is more relevant to use page-specific footer info only, delete the default footer in _config.yml and add footer content in each page frontmatter. (Option used in other resources)

@iadawn
Copy link
Contributor

iadawn commented Dec 6, 2023

Well that is a pain in the neck. My preference would still be to have this in the repositories rather than the main wai-website. Not idea but keeps it local.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants