Due to several factors, it’s possible for changes you make in the Visual Editor to not show up either in the viewport or when you view your live website. If you’re running into either of these problems, try these solutions.
1: Be Sure to Save Changes
Changes in Grid Mode or Design Mode must be saved before your live website is affected. It can be easy to forget that step before clicking View Site in the menu bar. Further, switching between layouts or between Grid and Design Modes without saving will discard the changes you made since you last saved.
The Save button appears in the upper-right corner of the Visual Editor. It’s active only when you have made changes so you know whether there’s anything to save.
2: Clear the Headway Cache
Headway has a caching system that enables your site to load quickly for your visitors. This cache applies to the preview function in Grid Mode and to the live display of changes in Design Mode. As a result, at times your changes may not appear as expected unless you clear the cache.
To clear the cache in either Grid Mode or Design Mode, click Clear Cache in the Tools menu.
Important: It’s recommended that you not disable Headway caching to avoid this problem.
3: Clear the Browser Cache
Your web browser stores temporary files on your computer when you visit websites so they’ll load faster the next time you visit. Since you’re probably viewing your site frequently as you lay it out and develop its styles, your browser is caching files and will sometimes use those instead of grabbing the updated files from the web server—even if you try refreshing the page.
To clear the cache in most browsers, press Ctrl+F5. The page you’re viewing is reloaded using the files on the server.
4: Check Whether Layout Inheritance Is Overriding Changes
The article on layout inheritance explains in more detail, but to summarize: layout inheritance is the way that customizations to a layout flow down to its uncustomized child layouts. The Blog Index layout is at the top of this hierarchy.
Any time you customize a layout, including assigning a layout template, layout hierarchy is overridden for that layout. Customizations to layouts higher in the hierarchy will not affect the customized layout or its child layouts.
Understanding where each layout fits in the hierarchy is important for knowing when and where to expect changes to appear. For example, if you have customized the Single layout (a child of Blog Index), then changes to Blog Index will not affect Single or any of its children. By the same token, if you customize the Single > Page layout, then changes to Single will not affect Single > Page.
The layout selector displays a “Customized” label next to layouts you have made changes to. A circle appears next to layouts with customized children.
If a page on your website doesn’t look the way you expect, check the layout selector to see whether the corresponding layout or another layout above it in the hierarchy has been customized. It could be that a customized layout is interfering with layout inheritance. Then you can either make the same changes to the customized layout or reset the layout so that layout inheritance will take effect again.
5: Check Whether CSS Inheritance Is Overriding Changes
Many times, if changes you’re making to styles in Design Mode aren’t taking effect, a more targeted style definition is overriding the change.
Similar to layout inheritance, CSS is hierarchical in nature. Styles defined for general elements, like <body>, can be overridden by styles for more specific elements and for classes of elements. And a style sheet can be overridden by another one that’s applied afterward. When your Headway website loads in a browser, styles are applied in this order:
- Design Mode styles set in the Design Editor
- Styles defined in the Live CSS Editor
- Styles defined in a Headway child theme’s style.css file
Style definitions applied later override earlier ones.
In addition, in Design Mode, styles can be customized in several different ways in a hierarchy. For more details about these items, including instructions, see Targeting Elements for Styling: Levels of Customization. Elements can be styled in these ways:
- For an element globally
(in the Visual Editor, this is called editing the “regular element”). Changes to the regular element apply across your website. For example, if you define styles for the header block regular element, the styles apply to all header blocks on all layouts.
- For a particular layout.
If you have customized a layout in Grid Mode, you can also define styles for it in Design Mode. The right-click menu options and the Design Editor for a block or element include the option to edit for the current layout. Alternatively, to target a block in a layout without first switching to that layout, select the layout and block combination in the Instances box. (The next item in this list describes instances.) Customizations for a particular layout override global styles.
- For an instance.
An instance is a specific layout-block-element combination—for example, the site title in the header block with alias “Main” in the Front Page layout. Many times, if a block or element appears only once on a layout, editing the instance is the same as editing for a particular layout. Customizations for instances override both global styles and customizations for a particular layout.
- For a state. Various states apply to hyperlink and menu item elements, such as hovered and clicked. You can define styles for states at any level—globally, for a particular layout, or for an instance. These customizations follow the same hierarchical rules. For example, customizing the hover state of a link for a particular layout overrides any hover state defined for links globally.
If you’re not seeing style changes affect an element or block the way you expect, it’s possible that you have customized that element or block’s styles on a specific layout or for a specific instance, so your changes are being overridden. Navigate to the block or element in question in the options panel and look for a yellow bullet next to a property group or a property, which indicates that you’ve customized the styles. You may need to set the property back to inherit by clicking the X next to it so it takes on the styles you’ve defined farther up the hierarchy.
For details about what styles are already defined in a new Headway Base installation, see Headway Base Default Styles.
6: Ensure Your Custom Classes Are Assigned to Blocks
In the Live CSS Editor, you can define custom classes for blocks. In order for your custom styles to apply to blocks, however, you need to assign the custom classes to the block. If you’re not seeing your custom class styles applying to a particular block, make sure it has the custom class or classes assigned:
- In Grid Mode, click the Edit button next to the layout where the block isn’t using your custom class.
- Right-click the block, and then click Open Block Options.
- Click the Config subtab.
- In the Custom CSS Class(es) field, type your custom class name(s). Separate each class with a space.
- Click the Save button.
- Click the View Site button to ensure that the class was applied correctly.
7: If working with a caching plugin or service
While we’ve changes/improvements to Headway to better work with caching/plugins or services, if you are using one and have gone through the list above and they are still not showing up, please do this:
- Clear cache of plugin or cache service
- Turn caching off in plugin settings or cache service settings
- If using a plugin: then deactivate the plugin
- Occasionally, if using the plugin, you may need to to undo the edits the plugin made to your
wp-config.phpfile and your
.htaccessfile. See here for instructions for WP Super Cache but you would do similar steps for other plugins
- Try your changes again. If you still have troubles, please submit a support request