• tortitudo

    (@tortitudo)


    I successfully made a child theme using the “Create a block theme” plugin in order to import a new font. I did it by uploading it to the child theme’s assets/fonts folder and referencing it in the child theme’s theme.json file, but it did not work at first. The font DID appear in the list of fonts when using the Site Editor, but a different default font is used in the frontend and backend. However, if I add the font to the PARENT theme’s assets/fonts folder and change nothing else, it immediately starts working. Therefore it seems that the font is being used from the PARENT theme’s folders. Why? The src for the font in child theme’s theme.json is “file:./assets/fonts/sulu-script_normal_400.woff2”.

    Thanks for your help!

    • This topic was modified 1 year ago by tortitudo.
Viewing 6 replies - 1 through 6 (of 6 total)
  • annezazu

    (@annezazu)

    Hey there! Awesome to hear you’re using the Create Block Theme plugin. From what I can gather with what you’ve shared and how child themes work, it sounds like potentially the font asset source?isn’t correct. By chance, can you share your theme.json file for both the parent and child theme so I can test this out and see what’s going on? You could also be running into a bug that I can report on.

    Of note, work is underway to add managing fonts to WordPress out of the box in WordPress 6.5 if all goes well (not a guarantee). You can follow the efforts here if you’re interested.

    Thread Starter tortitudo

    (@tortitudo)

    Thanks for the response. I could share my theme.json and file structure, but it’s a mess. I experimented a lot trying to get my fonts to reliably work. I will give you an example: sulu is a custom font and working successfully, it was entered totally manually and by experimentation. At first I successfully added them to the parent theme, but later realized they will be lost by a theme update (this was before I realized they can be added via the create block theme plugin), so I created a child theme with the plugin, and added the fonts in the same way. I thought everything was ok, until I deleted the font files in my parent theme, and the font stopped working.

    I have just double checked my theme.json files. The child theme.json has the src for the sulu font as such: “file:./assets/fonts/sulu/sulu_script.woff2”
    The font is located there as well, of course.

    The parent also has sulu in theme.json, but with the following location: “file:./assets/fonts/sulu-script_normal_400.woff2” . with the child theme activated, renaming the font in this location to x.bak has no effect on the correct appearance of the font. So I’m guessing the parent’s theme.json is really not being used.

    Anyway, there is a second, probably unrelated problem to adding fonts. I added Roboto and Oswald via Create a block theme plugin, with my child theme activated, and they install and appear correctly in the dashboard. But they do not appear in the Site Editor, and cannot be selected (don’t work).

    chbing5828

    (@chbing5828)


    It’s great that you’ve created a child theme and are working on customizing the font. The issue you’re facing might be related to the way the theme.json file is referencing the font file.

    Here are a few things to check and try:

    1. Path to the Font File:
      • Ensure that the path specified in the child theme’s theme.json file is correct. Double-check for any typos or issues with the file path.
      • Verify that the font file is actually present in the specified location in the child theme’s assets/fonts folder.
    2. File URL:
      • Instead of using file:./assets/fonts/sulu-script_normal_400.woff2, you can try using the full URL as the value for the “src” property. For example:jsonCopy code"src": "file:///path-to-your-theme/your-child-theme/assets/fonts/sulu-script_normal_400.woff2" Make sure to replace “/path-to-your-theme/” with the actual path to your theme.
    3. Cache Issues:
      • Clear your browser cache to make sure that the changes are reflected on the frontend.
      • If you are using any caching plugins on your WordPress site, clear the cache there as well.
    4. Theme Activation:
      • Ensure that you have activated the child theme in WordPress. Sometimes, changes may not take effect if the child theme is not activated.
    5. Correct Theme:
      • When editing the theme.json file in your child theme, make sure that you are indeed editing the correct file in the child theme, not accidentally modifying the parent theme’s file.
    6. Priority of Stylesheets:
      • Check if there are any stylesheets in the parent theme that might be overriding the font styles in the child theme. Use browser developer tools to inspect the elements and see which styles are applied.

    After making changes, be sure to refresh your browser and check if the font is now being applied correctly. If the issue persists, it might be helpful to consult the documentation of the “Create a block theme” plugin or the theme framework you are using for any specific considerations when working with child themes and custom fonts.

    Thread Starter tortitudo

    (@tortitudo)

    Thanks for your thorough reply. I read all your suggestions but it’s really the first one that’s the problem. I can now truly confirm that the issue is indeed that wordpress is searching for the font files in the wrong location. I have checked the network tab in the chrome developer tools when loading the “Manage theme fonts” part of the backend, and I can indeed see failed network attempts as the browser is trying to load the fonts from the parent theme’s fonts location, where they of course, do not exist. This is the case if the child theme’s theme.json file has src as file:./assets/fonts/sulu/sulu_script.woff2

    Changing the src to https://mywebsitename.com/wp-content/themes/mychildtheme/assets/fonts/sulu/sulu_script.woff2 makes the fonts start working.

    So, I think that the problem is that there is something wrong in my child theme’s setup that makes the relative paths not work – or, there is some other bug that prevents wordpress from finding the fonts in the child theme, that it automatically tries searching for them in the parent theme, which of course does not work.

    So, now I have a solid and maintainable workaround for including custom fonts. But, I would like to solve this issue anyway, so if anyone knows why the relative paths do not work, please let me know.

    Extra info just to clear doubts: i totally removed my previous parent theme that was tainted by my changes and experimentations, and replaced it with a fresh twentytwentythree parent theme. so the parent theme is totally virgin

    • This reply was modified 11 months, 4 weeks ago by tortitudo.
    • This reply was modified 11 months, 4 weeks ago by tortitudo.
    Thread Starter tortitudo

    (@tortitudo)

    I spoke too soon again. While it’s true that changing the src fixed the font appearance in the “Manage theme fonts” part of the backend, the fonts still don’t show up in the Site editor. I am very confused because sulu does show up for some reason, but roboto doesn’t.

    So the new question is: why do the font work and appear correctly in the “Manage theme fonts” but do not show up in the site editor (or some do, some don’t, depending on when they were added – before i created the child theme or after.) So confusing!

    • This reply was modified 11 months, 4 weeks ago by tortitudo.

    So the new question is: why do the font work and appear correctly in the “Manage theme fonts” but do not show up in the site editor (or some do, some don’t, depending on when they were added – before i created the child theme or after.)

    If you’re open to it, I would recommend opening an issue in the repo for this plugin to get direct help from the folks both maintaining this plugin and working on adding font management to the Site Editor. Here’s where you can do so: https://github.com/WordPress/create-block-theme/issues

Viewing 6 replies - 1 through 6 (of 6 total)
  • The topic ‘Child theme – relative paths don’t work correctly’ is closed to new replies.