Bryce Wray Posts - Answer Overflow

Bryce Wray

•Created by Bryce Wray on 11/6/2023 in #general-help

CF Fonts beta: examples of problems

Have been told the general-discussions channel isn’t where to report this, so will try here. (Tag choices didn’t really apply.) Re the Cloudflare Fonts beta: I created a mini-site to test how CFF handles Google’s Latin-language variable serif and sans-serif fonts that have italic styles. The ones which CFF currently doesn’t process correctly are the following, with links provided as examples: - Brygada 1918 (https://cfftest.brycewray.com/cff003/) - Noto Serif (https://cfftest.brycewray.com/cff009/) - Source Serif 4 (https://cfftest.brycewray.com/cff014/) - DM Sans (https://cfftest.brycewray.com/cff022/) - Exo 2 (https://cfftest.brycewray.com/cff024/) - Kumbh Sans (https://cfftest.brycewray.com/cff033/) - Roboto Condensed (https://cfftest.brycewray.com/cff042/) - Source Sans 3 (https://cfftest.brycewray.com/cff047/) To be fair, these amount to a small percentage of the fonts I tested! Good job, CFF team! However, some of these are fairly popular choices and, thus, could merit some attention as to why CFF isn’t processing them yet. Thanks. One thing to note for any other user finding this: where a font has a multi-word name, it’s important to make sure your website feeds the necessary link with an unescaped + between the font name’s words (e.g., Noto+Sans+Display for the Noto Sans Display font). I got help with that in the Hugo Discourse (https://discourse.gohugo.io/t/how-to-unescape-plus-sign-in-url-re-cloudflare-fonts/46734) but, if you’re using a different web-building tool, make sure it’s not escaping the + as &43#; since that appears to complicate things for CF Fonts.

11 replies

CDCloudflare Developers

•Created by Bryce Wray on 10/16/2023 in #pages-help

CSP issues with CF Fonts and CF Workers (execution order)

In my CF Pages site repo, I use a CF Worker (through functions/middleware.js) for, among other things, providing a Content Security Policy. One part of that CSP requires using a nonce to allow style statements, so — also with the Worker — I inject a nonce into any style statements that I must use for whatever reason. I'm now testing Cloudflare Fonts and see that my CSP is rejecting the style statements CF Fonts sets up because that nonce isn't getting injected, presumably because the CF Fonts stuff happens after the Worker runs. Am I correct in assuming that this order can't be changed? And, if that's the case, is my only option to add unsafe-inline and be done with it? (Also posted this on the Discourse. If I get an answer on either source, will indicate that and close each accordingly.)

1 replies

CDCloudflare Developers

•Created by Bryce Wray on 10/6/2023 in #pages-help

Deprecation warnings when deploying to CFP from GitLab CI/CD

I typically deploy to Cloudflare Pages from GitHub Actions, but am currently doing so from GitLab CI/CD. The CFP-relevant parts of my .gitlab-ci.yml script (https://github.com/brycewray/hugo-site/blob/main/.gitlab-ci.yml) are:

    - npm install -g wrangler --unsafe-perm=true
    - wrangler pages deploy ./public --project-name=$PROJECT_NAME --branch "main"

    - npm install -g wrangler --unsafe-perm=true
    - wrangler pages deploy ./public --project-name=$PROJECT_NAME --branch "main"

I get a successful deploy, but receive these warnings (which I don’t get when using GitHub Actions to deploy):

▲ [WARNING] Using "CF_API_KEY" environment variable. This is deprecated. Please use "CLOUDFLARE_API_KEY", instead.
▲ [WARNING] Using "CF_EMAIL" environment variable. This is deprecated. Please use "CLOUDFLARE_EMAIL", instead.

▲ [WARNING] Using "CF_API_KEY" environment variable. This is deprecated. Please use "CLOUDFLARE_API_KEY", instead.
▲ [WARNING] Using "CF_EMAIL" environment variable. This is deprecated. Please use "CLOUDFLARE_EMAIL", instead.

These items — I’ll call them security vars — all refer to existing “Secrets” I have in GitHub and CI/CD variables I have in GitLab, and I assigned the names back in the wrangler 1.x days. From searching the Discord about such warnings, I get the impression that it’s the names themselves that are the problem. So is the solution simply renaming these security vars accordingly? Also, in case you know: why doesn’t wrangler issue the same kind of warnings on GitHub? On my GitHub Action (https://github.com/brycewray/hugo-site/blob/main/.github/workflows/deploy-hugo-site.yml), the CFP-relevant parts are:

      - name: Publish to CFP
        if: ${{ env.GITHUB == 'true' }}
        uses: cloudflare/pages-action@v1
        with:
          apiToken: ${{ secrets.CFP_API_TOKEN }}
          accountId: ${{ secrets.CF_ACCOUNT_ID }}
          projectName: 'static-site-v2' # was 'static-site'
          directory: 'public'
          gitHubToken: ${{ secrets.GITHUB_TOKEN }}

      - name: Publish to CFP
        if: ${{ env.GITHUB == 'true' }}
        uses: cloudflare/pages-action@v1
        with:
          apiToken: ${{ secrets.CFP_API_TOKEN }}
          accountId: ${{ secrets.CF_ACCOUNT_ID }}
          projectName: 'static-site-v2' # was 'static-site'
          directory: 'public'
          gitHubToken: ${{ secrets.GITHUB_TOKEN }}

2 replies

CDCloudflare Developers

•Created by Bryce Wray on 5/11/2023 in #pages-help

Middleware OK on `pages.dev`, not on custom domain?

I tried _middleware.js stuff with CF Pages, in an attempt to use it instead of an existing CF Worker. The middleware worked perfectly on the pages.dev version — but, on the custom-domain version from that pages.dev, only the HTML files were affected even though the middleware was supposed to apply for all routes and files (location: functions/_middleware.js, thus presumably for all routes). To be more specific: on the pages.dev version, a number of custom headers (such as for caching) were added to a variety of file types, including CSS and image files; but, on the custom-domain version, this worked for only the HTML files. Is there something special I have to do in the domain’s DNS, or elsewhere, to make the middleware work properly on the custom domain, too? (And I did remove the custom domain’s routes from the Worker for the test, so the Worker shouldn’t have been interfering.) The pages.dev domain = static-site-2to.pages.dev The custom domain = brycewray.com Note: I had to re-add the custom domain routes to the Worker and take the _middleware.js file out of the project in order to regain the previous functionality, at least until I could learn from you folks why the middleware file wouldn’t work on the custom domain. Let me know if/when you want me to restore the test setup (assuming GitHub is stable at the time, that is 😄 ).

8 replies

Gaming

Programming