When it comes to building themes in WordPress, one of the nicest things that you can do for your users is to implement a stylesheet specifically for the editor so that they get a true WYSIWYG experience.

To be more specific, that is you can (and should!) add a stylesheet specifically for the WYSIWYG editor in the WordPress Dashboard. This stylesheet is normally called editor-style.css, but can actually be called whatever it is that you’d like permitting that you enqueue it properly.

With the popularity of web fonts rising – such as those from Google – you have to take a slightly different approach when implementing them in the context of the editor rather than the typical way of doing so with server side hooks.

Add Google Fonts To WordPress Editor

Typically, when we add web fonts to WordPress, we do so using the wp_enqueue_scripts hook, a custom function, and a call to the wp_enqueue_style function that will include our font(s).

Of course, this is for making the fonts available on the front end of the site.

If you’re looking to get this same functionality in the dashboard of the site, you’ve got to do it a little bit differently.

1. Hook Up Your Editor Styles

First, go ahead and hook up your editor stylesheet, this is done using the init hook and your own custom function.

As you can see in the code above, my editor-style.css is located in a css directory in the my theme’s directory.

Also, for those who are using child theme’s, please see Dan’s comment for how you need to modify this code.

2. @import Web Fonts

Now here’s where the difference comes as it relates to loading stylesheets. You can’t use admin_enqueue_scripts to get the same result as above.

A little confusing, I know, but you actually need to use CSS’ @import statement. As such, your stylesheet may look something like this:

Note that the code above is just a sample – you’ll obviously need to provide significantly more styles for each of the various elements, but you get the point.

3. Refresh The Editor

At this point, you should have editor-style.css defined, importing the web fonts, and have several elements defined. This should then result in something like this:

Using Google Fonts in the WordPress Editor

Using Google Fonts in the WordPress Editor

Of course, if you’ve used different fonts or different styles, then your results will be different, but the point and the method remain.

Category:
Articles
Tags:

Join the conversation! 17 Comments

  1. so you’re saying that one should endeavor to produce the same experience (e.g. font) in the front end and the backend editor? i’ve never really given this much thought. i wonder how impactful that decision really is and what complications/dependencies that could produce on the backend.

    seriously interesting.

    • Well, it should (?)
      and wordpress twentytwelve also using this (in different way).

      @tom:
      the code above is not “wrong”.
      but it’s best to do add_editor_style() function on after_setup_theme hook because it’s related to theme support. and it only add mce on post edit screen.

      there’s also mce_css filter you can use (check twenty twelve theme) to add custom additional stylesheet, we can use this if add editor style is not suitable for the purpose.

      i also just create a plugin utilizing wp editor style + tinymce plugin,
      you can check it here: http://wp-editor.com
      you can try it in site :)

      with a little creativity, we can do so much in wp visual editor, for example: to create restaurant menu: http://shellcreeper.com/?p=901#Building-Restaurant-Site-in-WordPress (video)

      what do you think?

    • so you’re saying that one should endeavor to produce the same experience (e.g. font) in the front end and the backend editor?

      To a degree. I think don’t it’s possible to stop users from switching from the front end to the preview mode to see how their work looks, but if you can close that gap even a little, I think that it will help the user experience.

      This is something that some more modern themes do that I really like.

      i wonder how impactful that decision really is and what complications/dependencies that could produce on the backend.

      This depends on how many fonts or how crazy developers and/or designers want to get with their implementation. I prefer to try to keep a site to no more than, say, three fonts.

      That page load weight will be relatively low, and if you’re using Google Web Fonts, then it’s easy to import.

      When you get into more advanced things like, say, TypeKit, then that’s a whole other issue that I’ve personally never experienced.

    • Considering your theme has the feature “editor-style”, ref. http://wordpress.org/themes/tag-filter/ it should have the matching fonts along with the matching styles.

      :P

  2. thanks for this Tom! definitely gets one thinking.

  3. Folks trying to implement this in a child theme won’t be able to load their custom editor style sheet unless they use get_stylesheet_directory_uri() instead of get_template_directory_uri().

    Thought I’d add that in case anyone gets stumped by it.

  4. Good article. I will be facing some of these issues as
    well..

  5. Unfortunately, I can’t see any code snippets in the post.. Where is the code?

  6. I know this is an old post, but your code snippets are not showing.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.