Close

Layers Help & Support

Layers 2.0.10 Update

Layers 2.0.10 Update

Removing the Envato Marketplace listings.

  • Fixed Image Ratio button in the Post widget
  • Removed redundant Envato Market listings

UPDATE LAYERS View on GitHub

[print-me]

How to Create a Style Kit

How To  Tutorials  Last Updated: Time to Read: 6 minutes

This guide is intended to help novices and pros alike, but assumes you know a little CSS. It offers best practices advice aimed at Style Kits intended for sale or client projects with regard to format and naming conventions. If you’re just getting started with using CSS to customize WordPress sites, see How to Customize Your Site with CSS Style Kits are comprised of three main parts:

  • Page builder layouts and their widget’s settings
  • Custom CSS code
  • The content (XML)

We recommend starting on a fresh WordPress install with no pre-existing content. We also recommend setting up your demo on a live server before doing the export so others can reference what the intended outcome should be, and images come over in the content import without additional tweaking or manual upload.

  1. Build your pages starting with a blank page. When designing for the general public, only Layers widgets should be used, as 3rd Party widget data is not saved by our export function.
  2. Add custom styling that is specific to the widget or page layout using the Advanced option of the widget Design Bar.
  3. On the Page Editor view in your admin, ensure the page’s Title and Slug match and clearly describe the kind of layout it is. Example: Portfolio, Features, Team Members, etc.
  4. Export the page
If your kit is intended for commercial distribution, you must setup a demo on a live server before exporting the data. This ensures any demo images can be transferred by the remote server and saves your end-users the extra step of importing the image assets manually.

See How to Export Page Builder Layouts

We strongly recommend using the DevKit plugin to help generate Layers-compliant CSS, especially if you intend to modify the mobile views. This incredibly useful plugin enhances the customizer with extended CSS editing and responsive mode testing. Learn More here

The following will help you decide where to best place custom styling and if the Advanced option in the widget should be used vs the main CSS area.

See All Layers Customization Tutorials

Advanced Widget CSS

Each widget has an Advanced option on the Design Bar for creating a custom class. This class is added to the main container of the widget, so any properties applied to the class alone will only affect that container (or any other widget with the same class assigned) and not necessarily everything in it. This allows you to apply a style to just this widget or page layout and is the only way you can add a custom class name to builder elements in Layers without touching HTML. Without it, you would need to use much more complex selectors to target specific elements or widgets. Targeting elements in CSS by ID is also not a good idea, as those IDs may be in use already with inline styles, anchors or Javascript.

The benefit of using this method is that custom classes and styles added to the Advanced options in widget setups are saved along with the other data when exporting a page file. This makes importing the styling aspect a little more foolproof. See our Advanced Custom CSS Tutorial for a detailed walkthrough of using this feature to customize your presets.

Our example kit uses advanced techniques covered in the Advanced Tutorial to replace the large button in widgets with an app store image hosted on the app providers websites. Additionally, it adds some global CSS to the main CSS area which is not saved in the page export. Custom CSS added to the main CSS area is not associated with any one page, so needs manual export and import, explained next.

Custom CSS

Custom CSS is used to add global custom styling to the CSS tab under the main Customizer menu if you need to provide additional styling changes. When building your custom CSS, keep the following in mind:

  • Never copy entire styles from the inspector or core stylesheets – your declarations should contain only changed properties and new additions.
  • Use waterfall formatting to make it easier to read and edit.
  • Lint your CSS before finalizing it and saving it to your kit.
  • If your custom css is really extensive, it may be time to consider a child theme. Style kit CSS should be as simple as possible and focused on basic styling changes like colors or element styles. It should not contain advanced CSS like transforms, layout hacks or hard-coded font sizing that might interfere with the user’s font or widget choices in the normal Layers options.
Kits intended for commercial distribution should not include Custom CSS that requires the end-user to edit image or font paths. Make sure any assets like this are optional with clear instructions, or linked to a hosted file.

To prepare your Custom CSS for your kit, simply copy it into a plan-text document named css.txt. Mac Users, hit Shift+Cmd+T in TextEdit to switch to plain-text mode.

View the example kit css.txt file

Including a content XML is an important step in ensuring the base pages used for your presets and the images used in the widgets can be easily imported by the user. Before exporting your content, check the following:

  • There are no tags under PostsTags
  • If your content includes demo posts, ensure any categories you created are relevant to your kit, otherwise create only one, such as “Demo”. This makes customization and cleanup of the content easier for end-users and reduces the risk of having a duplicate category with a bad slug.
  • Pages other than Layers builder pages should not use “Home”, “Portfolio”, “Shop” or “Blog” as the page title.
  • Empty the trash on your posts and page indexes
  • Remove all comments
  • Ensure all plugins are deactivated to avoid import of CPT data, etc
If your kit is intended for commercial distribution, you should setup a demo on a live server before exporting the data. This ensures any demo images can be transferred by the remote server and saves your end-users the extra step of importing the image assets manually.

Export the content from ToolsExport and name the file your_kit-content.xml where your_kit is your kit name. Example: kittn-content.xml

View the example kit XML

Your readme should include general information about you as the author, a link to the demo, if one exists, and some basic instructions for use. You may copy the demo kit’s readme and customize it for your kit, if desired.

View the example readme

If you will be hosting your kit on GitHub, don’t forget to add a readme.md file.

Your kit should use a simple structure like this one:

  • folder
    • images
    • css.txt
    • layout-one.json
    • layout-two.json
    • kit-content.xml
    • readme.txt
  1. Test the import process on a live server to ensure everything works!
  2. Re-export all the data if your original files were staged locally. This ensures others can import images without uploading them manually.
  3. Zip the folder and name it kitname_layers-style-kit.zip where kitname is your Style Kit name.

Go through How to Import a Style Kit to verify your Style kit works as expected on a fresh install.

screenshot

Download Example See the Demo

Did you know?

Our friends at Jetpack are doing some incredible work to improve the WordPress experience. Check out Jetpack and improve your site's security, speed and reliability.

Jetpack