LayersWP — First Impression

I’ve finally got to try the new theme builder — Layers by Obox Themes. Upon arriving on their landing page I was pleasantly surprised. They present Layers as a modern, full-featured theme builder. However, there are things that I don’t like about Layers, so I’m going to write a short pros and cons of it.

Pros

Built into WordPress, as they say

Instead of creating yet another slow and resource-hungry custom theme builder, developers of Layers extended the WordPress Customizer. They’ve done it beautifully; just try it and see for yourself.

The approach to customizing pages is to use available WordPress widgets for page’s body. This way, a user can download any number of super-powerful widgets or create their own ones and use them for styling his homepage for example. No fancy modules or custom stuff; just standard WP widgets. What is more, Layers developers have created several useful widgets for manipulating content, sliders and Google maps. Their interface is quite simple, usable even for less technical people.

On the other hand, using widgets as building blocks for your pages has its downfalls which I’ll be describing later in this article.

Active community and open source

Layers is a young project with growing community and support. It’s developed the open source way on GitHub. Submitting issues and contributing to Layers core is welcomed. It seems like Layers will live for a long time, so it could be a good choice for your new projects.

Cons

Pages created in Layers? Don’t try to switch to another theme

Have you read Chris Lema’s great article about (not) using Divi? The problem is that if you construct your pages in Divi theme builder, switching to another theme in the future will be extremely painful. Well, Layers is no exception to this. Due to the reason pages are built with widgets and not pure HTML/CSS, after moving to a new theme you’ll be present with blank pages. Woah! Although there is an option to export Layers’ page data, the data is exported in a JSON format. Try to create the exact same looking page from that in another theme. Good luck with that.

This
Testing LayersWP Page
exports as this:

{
   "obox-layers-builder-679":{
      "layers-widget-column-4":{
         "design":{
            "layout":"layout-boxed",
            "liststyle":"list-grid",
            "gutter":"on",
            "fonts":{
               "align":"text-left",
               "size":"medium",
               "color":""
            },
            "background":{
               "image":"",
               "color":"",
               "repeat":"no-repeat",
               "position":"center"
            },
            "advanced":{
               "customclass":"",
               "customcss":"",
               "padding":{
                  "top":"",
                  "right":"",
                  "bottom":"",
                  "left":""
               },
               "margin":{
                  "top":"",
                  "right":"",
                  "bottom":"",
                  "left":""
               }
            }
         },
         "title":"Testing Page",
         "excerpt":"Page excerpt",
         "column_ids":"136,249,305",
         "columns":{
            "136":{
               "design":{
                  "background":{
                     "image":"",
                     "color":"",
                     "repeat":"no-repeat",
                     "position":"center"
                  },
                  "featuredimage":"",
                  "featuredvideo":"",
                  "imagealign":"image-top",
                  "fonts":{
                     "align":"text-left",
                     "size":"medium",
                     "color":""
                  }
               },
               "width":"4",
               "title":"Column 1",
               "excerpt":"Column 1 text",
               "link":"",
               "link_text":""
            },
            "249":{
               "design":{
                  "background":{
                     "image":"",
                     "color":"",
                     "repeat":"no-repeat",
                     "position":"center"
                  },
                  "featuredimage":"",
                  "featuredvideo":"",
                  "imagealign":"image-top",
                  "fonts":{
                     "align":"text-left",
                     "size":"medium",
                     "color":""
                  }
               },
               "width":"4",
               "title":"Column 2",
               "excerpt":"Column 2 text",
               "link":"",
               "link_text":""
            },
            "305":{
               "design":{
                  "background":{
                     "image":"",
                     "color":"",
                     "repeat":"no-repeat",
                     "position":"center"
                  },
                  "featuredimage":"",
                  "featuredvideo":"",
                  "imagealign":"image-top",
                  "fonts":{
                     "align":"text-left",
                     "size":"medium",
                     "color":""
                  }
               },
               "width":"4",
               "title":"Column 3",
               "excerpt":"Column 3 text",
               "link":"",
               "link_text":""
            }
         }
      }
   }
}

Not too fancy, is it…

The way Layers store page customizations might be a problem

I wanted to see how page customizations are actually stored in the database. Looking in the posts table, post_content of my custom post is empty so it must be somewhere else. After a while I found out that the data are stored serialized in options table; each widget having its own row. So, for example, if you use the Content widget (Layers custom one) on multiple pages, everything will be stored in a single (!) row in the DB, serialized. I think that’s not a good idea, especially for performance reasons.

Imagine you have 50 custom pages built with 20 widgets. Now, a user loads your /contacts page. Instead of querying single row in posts table with all the content needed for rendering the page, WordPress has to query multiple rows from options table, unserialize them and use only a small part of that data. I haven’t tested the loading speeds but I estimate that these serialized data can run in the megabytes range in such scenario, which will slow everything down. There is a reason why one table is called options while the other posts — WordPress options should be stored in options and pages/posts with their content in posts tables, obviously. I’m aware of the fact that standard WordPress widgets which reside in sidebars/footers are also stored in the options table. However, you probably won’t have 100 different widgets on different pages or posts while you can have hundreds of different posts pretty easily.

 

All in all, I gave Layers just a few hours and this is my first impression of it. I might be missing something or I might find it perfectly fast and fine after some more usage.

 

Join the Conversation

6 Comments

  1. Ok, I want to make a theme for WordPress and use a page builder in it. In your opinion what’s better siteorigin page builder plugin or layerswp framework?

    Like

    1. Hello saeed,

      I’m sorry, but I don’t have much experience with page builders in general. I tried LayersWP because the concept of integrating the builder into the WordPress Customizer got my attention. And as Layers is free, I immediately had to give it a spin.

      Although I’ve done no load testing of Layers, I think it won’t be as performant as it could be, telling from its architecture — the customizations are not stored in the posts table (post_content column) to the post/page row directly but in the options table in the same way as widgets are stored.

      Give both of them a try and see which one suits you more. If you prefer no coding at all, have a look at http://premium.wpmudev.org/blog/introducing-upfront. Looks promising. Haven’t tested it on production site though.

      Like

  2. do you know any good framework to start with ? Especially for themeforest submissions.
    Layers looked promising to me but its has own issues One you pointed out and second i don’t want html/css stuff bundled with framework.

    Like

    1. Layers is not a framework in the sense that you build your own theme on top of it. It could be done (as a child theme) but it’s more of a theme than a framework.

      Other than that, I, currently, don’t have a favorite theme/plugin framework. There are plenty of them. What I recommend to you is to find the most recognized developers in the WordPress ecosystem and go through their GitHub profiles, looking for frameworks/skeletons. For a start, inspect my GitHub following list: https://github.com/lamosty/following. Half of the people on the list have some kind of framework. 🙂

      Like

  3. Layers is bad, and having used it now to create a dozen or so client sites I wish I could go back 18 months and tell myself to use something else.

    Every time they update Layers it breaks the child theme we’ve created for the client… In the long term, it’s cost us huge amounts of time and money to keep going back to repair client’s websites that have been broken by a Layers update. And it updates CONSTANTLY. A year ago it was v 1.4.x and now it’s at 1.6.5, it’s totally different and I’ve had to rebuilt any client site that updated itself.

    AVOID LAYERS!

    Like

Leave a comment

Leave a Reply to Rastislav Lamoš Cancel reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: