I change the favicon (I deleted the default favicon and replace with new one with the same link structure '/favicon.png and /favicon.webp') but shows nothing on the home page and when visited posts the default favicon show
And the /tag/, /category/ and/blog/ shows error
And how can I customize 404

Create the missing 404 page template

IE11 ❌

Chrome ✔

Symptoms sick

• Missing the flexbox layout for post grids
• Losing the object-fit for post thumbnails
• Losing the color overlay for the background image in the .beforefooter section

Expected Causes

CSS Flexible Box Layout Module | Can I use...

CSS3 object-fit/object-position | Can I use...

"background-blend-mode" | Can I use...

Was browsing some Jekyll themes, This is a nice one, but noticed the drop down for viewing tags isn’t being shown properly on iPad Pro, Latest release

Jekyll-Scholar

[x] pre-release version (v2.1.2-alpha)
[ ] doc and demos

Description

We're experiencing a CORS policy error when trying to load an image from 'https://icon-library.com/images/b8d82a619c.png' on our website 'https://chriskyfung.github.io'. The error is being thrown because the server hosting the image lacks the 'Access-Control-Allow-Origin' header.

Expected Behavior

The image should load correctly without any CORS policy errors.

Current Behavior

The image is not being loaded due to a CORS policy error. The browser is blocking the resource from being loaded due to the absence of the 'Access-Control-Allow-Origin' header.

Possible Solution

To fix this issue, we have two possible solutions:

1. Host the image on the same domain as our website.
2. Configure the server where the image is hosted to include the 'Access-Control-Allow-Origin' header in its responses.

Steps to Reproduce

1. Open 'https://chriskyfung.github.io' in any browser.
2. Open the DevTools console.
3. Notice the CORS policy error related to the image from 'https://icon-library.com/images/b8d82a619c.png'.

Context (Environment)

The issue is reproducible in the Microsoft Edge browser.

Detailed Description

The CORS policy error needs to be resolved as it's preventing the image from being loaded on our website, which could impact the user experience.

Possible Implementation

Here are the steps to host the image on the same domain as your website:

1. Download the Image: First, you need to download the image from 'https://icon-library.com/images/b8d82a619c.png'. You can do this by navigating to the URL, right-clicking on the image, and selecting 'Save Image As...'.

2. Upload the Image to Your Server: Next, you need to upload the downloaded image to your server.

3. Update the Image URL: Once the image is uploaded to your server, it will have a new URL. You need to update the image URL in your website's code. For example, if your website is 'https://chriskyfung.github.io' and you uploaded the image to an 'images' directory, the new URL might be 'https://chriskyfung.github.io/amp-affiliately-jekyll-theme/assets/images/b8d82a619c.png'.

4. Test the Image: Finally, you should test the image by navigating to your website and ensuring the image loads correctly. If you still see the CORS error, make sure the image URL is correct and the image was uploaded successfully.

By hosting the image on your own domain, you avoid the CORS policy issue because the image is no longer being loaded from a different origin. This is a common solution to CORS errors when you have control over the server where the resources are hosted. Please note that this method requires that you have the necessary permissions to host and distribute the image. If the image is copyrighted, you should seek permission from the copyright holder before hosting it on your own server.

The Viglink integration used in this theme is no longer supported and may cause issues with website's performance and security. Therefore, we drop all the outdated Viglink integration from the AMP Affiliately Jekyll Theme.

Expected Result:
All outdated Viglink integration should be removed from the AMP Jekyll theme.

Priority: High

Following the configuration guide the categories and tags are not being displayed or generated.

I also checked your gh-pages branch and it seems that both categories and tags are actually new pages, not something generated via jekyll.

Description

The AMP validator reports two errors for the redirect pages, like this:

FAIL: <path>\index.html
line 1, col 224: The attribute 'http-equiv' may not appear in tag 'meta'. (see undefined)
line 3, col 385: Custom JavaScript is not allowed. (see https://amp.dev/documentation/guides-and-tutorials/learn/validation-workflow/validation_errors/#custom-javascript-is-not-allowed)

Steps to reproduce

1. Run the AMP validator after building the site files using npm run build
2. Observe the errors in the console output

Expected behavior

The redirect pages should pass the AMP validation without any errors.

Actual behavior

The redirect pages fail the AMP validation with two errors.

Environment

• Ruby: 3.1.2
• Jekyll: 4.2.2
• Jekyll Redirect plugin: 0.16.0
• Gulp: 4.0.2
• AMP Optimizer: @ampproject/[email protected]
• AMP Validator: [email protected]

Potential solution

To solve the AMP validation errors in the redirect template, follow these steps:

• Remove the <meta http-equiv="..."> tag. This tag is not allowed in AMP documents, as it can interfere with the AMP cache and the browser's rendering.
• Replace the <script> tag with an <amp-script> tag. This tag allows you to run custom JavaScript in AMP documents, as long as you follow the amp-script guidelines.
• Validate your AMP page again using Google’s Structured Data Testing Tool or the AMP validator.

Description

When using AMP optimizer to process our Jekyll site built with Gulp, we encounter a number of warning messages like this: AMP Optimizer AddMandatoryTags WARNING No canonical param is given. Setting canonical href to .

We have traced the source of the issue to the jekyll-redirect-from plugin, which generates redirect pages with missing the HTML <head> and <body> tags. This is incompatible with the AMP optimizer and causing issues in the AMP pages.

Steps to reproduce

• Install the jekyll-redirect-from plugin and enable it in the _config.yml file
• Add some redirect_from entries to some pages or posts
• Run gulp to build the site and run the AMP optimizer
• Check the console output for the warning messages

Expected result

The redirect pages should have absolute URLs for their canonical links, and the AMP optimizer should not show any warning messages.

Actual result

The AMP optimizer cannot ampify the redirect pages appropriately and shows warning messages like this: AMP Optimizer AddMandatoryTags WARNING No canonical param is given. Setting canonical href to .

Proposed solution

One possible solution is to customize the redirect template for the jekyll-redirect-from plugin. We can copy the redirect.html file to the _layouts directory under the Jekyll project. In the custom redirect template, we then add back the HTML <head> and <body> tags.

Steps to implement the solution

• Update the jekyll-redirect-from plugin to the latest version
• Add the custom redirect template to the _layouts directory
• Test the site locally and verify the canonical links and the AMP validity
• Deploy the site to the hosting service and run the AMP optimizer again
• Check the console output for any remaining warning messages
• Use the PageSpeed Insights tool to measure the site speed and performance

Description

The current Jekyll theme includes Google Analytics tracking using the Universal Analytics (UA) property. However, UA is outdated and will be discontinued in July 2023. We should update the theme to use the Google Analytics 4 (GA4) property instead to ensure continued tracking.

Issue Type: Enhancement

Proposed Changes

• Remove the outdated UA tracking code from the theme.
• Add GA4 tracking code to the theme, using the appropriate Measurement ID.
• Ensure that the GA4 configuration is AMP-compliant.
• Update the documentation and instructions to reflect the changes.

Benefits

• Maintain accurate and reliable tracking data after the UA discontinuation.
• Enhance support for modern website practices and AMP compliance.

Acceptance Criteria

• The UA tracking code is removed.
• The GA4 tracking code is correctly implemented.
• The theme is compatible with AMP pages.
• The documentation is updated accordingly.

Additional Information

• UA will be discontinued on July 1, 2023.
• GA4 is the recommended alternative for tracking website traffic and engagement.
• For more information on migrating to GA4, please refer to: https://support.google.com/analytics/answer/10088976?hl=en

Priority: High
Due Date: Before July 1, 2023

Title: Implement Granular Consent UI for GDPR Compliance

Description

The current AMP-ready Jekyll theme includes services that utilize cookies to store user data. To ensure compliance with the General Data Protection Regulation (GDPR), we need to implement a granular consent UI that allows users to control their cookies on a per-purpose basis.

Problem

The theme does not currently provide users with a way to opt in or out of specific cookie purposes, which could result in non-compliance with GDPR requirements.

Proposed Solution

We propose implementing a Consent UI that includes the following features:

• Granular Consent: Users should be able to consent to or reject individual cookie purposes separately.
• Clear and Transparent Information: Users should be provided with clear and concise information about each cookie purpose before giving their consent.
• Easy to Access: The Consent UI should be easily accessible and visible to users.
• AMP Compatibility: The Consent UI must be implemented in a way that maintains AMP validity.

Possible Implementations

One possible implementation could involve using a third-party consent management platform (CMP) that is AMP-compatible. CMPs provide a range of features out-of-the-box, including granular consent options, data collection, and reporting.

Another approach could be to develop a custom Consent UI using AMP elements. This would require more development effort but could provide greater control over the UI's design and functionality.

Benefits

Implementing a granular Consent UI will provide the following benefits:

• GDPR Compliance: Ensure that the theme complies with GDPR requirements for cookie consent.
• User Privacy Protection: Give users control over their personal data and how it is used.
• Improved User Experience: Empower users to make informed decisions about their cookie preferences.

Timeline

This feature should be prioritized and completed within the next sprint.

Assignee

To be assigned after discussion and review of proposed implementations.

Additional Notes

• We should consider using a CMP that is lightweight and does not impact page performance.
• The Consent UI should be designed to be user-friendly and easy to understand.
• We should provide documentation and guidance to users on how to use the Consent UI.

Development of a custom Consent UI using AMP elements

Objectives

• Create a user-friendly and compliant Consent UI using AMP elements.
• Ensure compliance with industry regulations and best practices.
• Provide a seamless and transparent user experience.

Tasks

Phase 1: Design and Development

• Design the Consent UI using AMP elements, considering accessibility and responsiveness.
• Develop the UI using AMP's HTML and JavaScript components.
• Implement the necessary AMP state management and event handling.
• Ensure the UI is visually appealing and aligns with the brand guidelines.

Phase 2: Integration and Testing

• Integrate the Consent UI into the existing website or application.
• Conduct thorough testing to verify functionality, performance, and accessibility.
• Perform user acceptance testing to gather feedback and validate the UI.

Phase 3: Deployment and Maintenance

• Deploy the Consent UI on the production site.
• Monitor the UI's performance and address any issues promptly.
• Regularly update the UI to maintain compliance and enhance user experience.

Additional Tasks

• Legal Compliance: Review and align the Consent UI with applicable laws and regulations.
• Transparency: Provide clear and concise information to users about the purpose and use of their data.
• Granularity: Allow users to specify granular consent preferences for different purposes and vendors.
• Revocability: Enable users to easily revoke their consent at any time.
• Accessibility: Ensure the Consent UI is accessible to users with disabilities.
• Vendor Management: Integrate with vendor consent management platforms to streamline consent collection and management.

Description

When using the Jekyll Archives plugin to generate archive pages for categories and tags, it creates multiple files with the same name in the _site directory, causing a conflict. For example, the following destination is shared by two files:

./amp-affiliately-jekyll-theme/_site/category/doc/index.html
 - category/doc/index.html
 - category/doc/index.html

This results in unexpected contents in the written file, and may affect the functionality of the site.

Steps to reproduce

1. Install the Jekyll Archives plugin according to the documentation.
2. Run bundle exec jekyll serve or jekyll serve to build the site locally.
3. Observe the conflict warning in the terminal output.
4. Check the _site directory and find the duplicate files.

Expected behavior

The Jekyll Archives plugin should generate only one file per destination, and avoid creating duplicate files in the _site directory.

Possible solutions

Upon inspection, it was found that the source directory contains a duplicate file that matches the archive path. The file is configured to provide the URL redirection from category/guide/ to category/to/.

To resolve this issue, we may rename the category/doc to category/guide and set the redirection using the front matter redirect_to instead of redirect_from.

Additional information

• Jekyll version: 4.2.0
• Jekyll Archives version: 2.2.1
• Operating system: Windows 10
• Ruby version: 3.0.0

Jekyll is a static site generator that uses Liquid as its templating language. Liquid has a tag called include that allows you to insert the content of another file into your current file. For example, you can use {% include footer.html %} to insert the content of footer.html into your page.

However, when you use include just after a list item, you may encounter an indent issue. This is because Liquid preserves the whitespace and indentation of the included file, which may not match the indentation of the list item. For example, if your footer.html file has four spaces of indentation, and your list item has two spaces of indentation, the result will look like this:

• This is a list item
  {% include footer.html %}

To fix this issue, you have two options:

• You can remove the indentation from the included file, so that it aligns with the list item. For example, if your footer.html file looks like this:

  This is a footer

You can change it to this:

This is a footer

• You can use the strip filter to remove the leading whitespace from the included file. For example, you can use {% include footer.html | strip %} to insert the content of footer.html without any indentation. This will result in the following output:

• This is a list item
  {% include footer.html | strip %}

Uncrawlable Link

a.nav-link.dropdown-toggle

Hello, could you pls help me with my issue.
I install your perfect theme, but if i tried to go to nav menu links: /category/ /tag/ /cloud/ i got empty page..

Shall i need to Add some .md files to root directory for this to work?
And one more question - could you please describe what it's for a file .post-template (in root directory)?)

References:

• Heading elements are not in a sequentially-descending order | web.dev

• –

  : The HTML Section Heading elements - HTML: HyperText Markup Language | MDN

• Headings • Page Structure • WAI Web Accessibility Tutorials
• How to Use Header Tags and H1 Tags for SEO

Description

The amp-addthis extension is no longer maintained and has been deprecated. It is recommended to drop this extension and its associated components from the codebase for the following reasons:

• Maintenance Burdens: The extension is no longer actively maintained, which can lead to technical issues and security vulnerabilities.
• Performance Impact: The extension can introduce performance overhead to AMP pages, which can negatively impact user experience.
• Lack of Support: The extension is not supported by any major AMP framework or library, making it difficult to integrate and debug.

Proposed Changes

• Remove the amp-addthis configuration from the Jekyll theme's _config.yml file.
• Delete all references to the extension and its components from the theme's codebase.
• Update the theme's documentation to reflect the removal of this extension.

Benefits

• Improved performance and reliability of AMP pages.
• Reduced maintenance burden.
• Simplified codebase and improved extensibility.

Timeline

This change should be implemented within the next release of the Jekyll theme.

Additional Notes

• Users who rely on the amp-addthis extension will need to find alternative methods for adding social sharing buttons to their AMP pages.
• There are several other AMP-compatible social sharing extensions available, such as AMP-Social-Share and AMP-Story-Sharing.
• Please provide feedback and suggestions on this proposed change.

Description:

We are encountering an error in the DevTools console related to resource preloading. The specific error message is:

A preload for 'https://chriskyfung.github.io/amp-affiliately-jekyll-theme/assets/images/logo-plainSVG.svg' is found, but is not used because the request credentials mode does not match. Consider taking a look at crossorigin attribute.

This error indicates a mismatch between the request credentials mode and the 'crossorigin' attribute in the <link rel="preload"> tag.

Steps to Reproduce:

1. Open the website in Microsoft Edge.
2. Open the DevTools console.
3. Notice the error message.

Expected Behavior:

The resources should be preloaded correctly without any errors in the console.

Actual Behavior:

The browser found a preload link for 'logo-plainSVG.svg' but didn't use it due to a credentials mode mismatch.

Proposed Solution:

We need to adjust the 'crossorigin' attribute in the <link rel="preload"> tag to match the credentials mode. This could be 'anonymous' or 'use-credentials', depending on the requirements of the resource being preloaded.

Additional Information:

Please ensure to test the changes in Microsoft Edge as the error was identified in this browser.

Problem

AMP validation fails for all pages that use the ‘amp-link-rewriter’ extension, which is no longer needed after dropping the Viglink integration in PR #45.

Actual Behavior

Expected behavior

AMP validation should pass for all pages without any errors or warnings related to the ‘amp-link-rewriter’ extension.

Steps to reproduce

1. Run npm test in the terminal to run the AMP validator.

2. Observe the error messages for each page that uses the ‘amp-link-rewriter’ extension, such as:

   FAIL: blog\example\index.html
   line 674, col 0: The extension 'amp-link-rewriter' was found on this page, but is unused. Please remove this extension. (see undefined)
   

Possible solution

Remove the ‘amp-link-rewriter’ extension from the pages that use it, and update the tests accordingly.

• Remove the 'amp-link-rewriter' extension from the pages that use it
• Run npm test and confirm that AMP validation passes

Additional context

This issue is related to PR #45, which removed the Viglink integration that required the ‘amp-link-rewriter’ extension.

Description

We are using Disqus to power the comment system for our AMP-based Jekyll theme. However, Disqus is showing unwanted ads on our website that we do not have control over. We want to hide these ads with CSS.

Steps to reproduce

1. Visit any page with Disqus comments on our website.
2. Scroll down to the comment section and observe the ads.

Expected behavior

We expect to see only the comments and no ads.

Actual behavior

We see ads above and below the comments.

Possible solution

We can hide the ads iframes with CSS by using the following selector:

iframe[src*="ads-iframe"] {
  display: none;
}

Tasks

• Edit the CSS style sheet to hide the ads iframes with the selector above.
• Test the website on different browsers and devices to ensure the ads are hidden.
• Commit and push the changes to the GitHub repository.

Description

The data-ampdevmode attribute is being used on an <amp-script> tag in production code, which can lead to unintended behavior, such as:

• The custom script will not be executed.
• The AMP page will not be validated.
• The AMP page may not display correctly in some browsers.

Steps to Reproduce

1. Create an AMP page that includes the following code:

<amp-script src="https://example.com/script.js" data-ampdevmode></amp-script>

2. Publish the page and load it in a browser.

3. Inspect the network requests and observe that the script is being loaded from the development server instead of the production server.

Expected Behavior

The data-ampdevmode attribute should only be used in development environments and not in production. A script hash should be used to verify that the custom script and included in a meta[name=amp-script-src] element in the document head.

Actual Behavior

The amp-script does not run in production because the data-ampdevmode attribute is present.

Proposed Fix

Remove the data-ampdevmode attribute from the <amp-script> component in production environment.

• Change the class names and styling of the Callout partial to better stick with the Bootstrap framework

Access to image at 'https://icon-library.com/images/b8d82a619c.png' from origin has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.

[ ] coding
[ ] test version
[ ] doc

Alternative:

TOC button

Problem

The theme's documentation website lists the jekyll-gist package as one of the whitelisted packages that can be used with the theme. However, this package is incompatible with AMP, and it renders script tags that break AMP validation and page layout.

Solution

The documentation website should remove the jekyll-gist package from the whitelist package list, and warn users not to use this package with the AMP-really theme. Instead, the documentation website should recommend alternative methods to embed GitHub gists in posts and pages, such as using the <amp-gist> component.

Steps to implement the solution

• Edit the documentation website's source code to remove the jekyll-gist package from the whitelist package list
• Add a note to the documentation website that explains why the jekyll-gist package is not compatible with AMP, and what are the possible alternatives
• Deploy the updated documentation website and verify that the changes are reflected