Layout identifier

[rogerlos]

Is it my imagination, or is a pre-built layout identifier not available anywhere within the plugin?

For example, if I have a pre-built layout "foo" users can put into their page, there is not a single place the plugin ever references that identifier, once the user has selected it in the admin editor? It's not saved in the page postmeta, it's not incorporated into the panel id, it's not added as an attribute, it's literally completely lost and forgotten?

I feel like I'm missing something, this seems like a crucial thing for any serious use of layouts which aren't just about making a bg blue or some-such. For example, if a user chooses "foo", I want to automatically populate a column with an extra widget on render. Cannot be done, it seems.

This seems like such a simple key piece of info to have available.

[AlexGStapleton]

Hi rogerlos ,

We're currently working on the conceptual stage of this issue and we're trying to work out the best way to implement this. Something that would really help us with this is if you could clarify how you would use this sort of functionality?

[rogerlos]

Up front: Thanks for including as many filters as you do, it does make working with the plugin a lot easier (I have to intercept all of the formatting calls in my sites and convert your html structure to a bootstrap-friendly version, and it's not painless but not as painful as it could be).

Answer: As I recall, when I create a layout, I assign it a slug, essentially, and I would just like to be able to find, within the pagebuilder info array passed to the various filters, that layout slug. If I know that, and some other information from that layout is not in the data passed to the filter, I can grab it, or I can tailor rules to specific layouts.

For example, I might have three different types of layouts, and want to add a section which is hidden from the editor one one of them (ie, always add an advertisement row on certain layout types). Without the identifier, it becomes pretty sketchy to try and figure out which layout is which. With it, it's a piece of cake.

[AlexGStapleton]

Thanks - that helps a lot! :)

The one thing I'm not too sure how we're going to handle at this stage is when do we add, and do we remove the layout slug. For example, if I import a layout and remove 4 out of 6 rows, should the layout slug remain? What about if we only remove a single 1?

Hm. Maybe we should always apply the slug to the page and then the designer/developer will need reference the contents itself via row ids/classes. That way if all of the initial rows have been removed, it doesn't matter just as long as the layout defined row id/class is being used.

That does seem more ideal, but I worry certain users may try a bunch of different layouts for a specific page and then up using only one of them. We could run some checks against this, however.

What are your thoughts on the above? I'm you as someone who would actually use this functionality to ensure we don't overlook anything.

[rogerlos]

That's an excellent question. I'm not sure, honestly. A lot of it is on me, as a dev. If my layout is with-adverts and my pseudo code is something like if ( $row_counter === 3 ) to trigger the advert row, it's probably my job to make sure the layout still has three rows, eh? I mean, at best I might hope your code might add a flag the layout has been modified, but it would be a huge task to try and track all of the rows, cells, etc.

I cannot recall off the top of my head if your code allows me to "lock" a layout, which would definitely be handy for really "senstive" layouts (ie, ones which have a super-tight grid, as designed). But if I know the layout slug, I can do that myself, for the most part.

(On a couple of installs I've used admin CSS and JS to do things like hide the CSS edit areas and cell definition areas on rows and cells, or add my own fields to those areas; this would be handy to be able to trigger from the layout info array, but not essential.)

BTW, and this is a separate issue, I end up completely removing the CSS builder object your code creates and inserting my own empty one because there is not a method available within the CSS builder class to remove an existing rule (or there wasn't last time I checked, which admittedly has been awhile).

[AlexGStapleton]

I mean, at best I might hope your code might add a flag the layout has been modified, but it would be a huge task to try and track all of the rows, cells, etc.
That would be ideal, and likely be something we would do.

It would increase the save time a little bit (more so if we actually detect a layout), but outside of that there honestly wouldn't be a performance hit.

I cannot recall off the top of my head if your code allows me to "lock" a layout, which would definitely be handy for really "senstive" layouts (ie, ones which have a super-tight grid, as designed). But if I know the layout slug, I can do that myself, for the most part.

We currently allow for this via the SiteOrigin Premium Custom Post Type Builder addon so the functionality is there.

(On a couple of installs I've used admin CSS and JS to do things like hide the CSS edit areas and cell definition areas on rows and cells, or add my own fields to those areas; this would be handy to be able to trigger from the layout info array, but not essential.)

You should be able to do that by filtering the row/widget options. The layout specific triggers (code wise), that an interesting one. I'll make a note of that and come back to it.

I end up completely removing the CSS builder object your code creates and inserting my own empty one because there is not a method available within the CSS builder class to remove an existing rule

There isn't directly a method of doing, but you can alter the CSS before its generated/stored by using the siteorigin_panels_css_object filter (for example).

[rogerlos]

(Apologies about making this a sprawling catch-all, I'd be happy to open separate issues if you want me to.)

There isn't directly a method of doing, but you can alter the CSS before its generated/stored by using the siteorigin_panels_css_object filter

I believe I ended up doing it this way mainly because of the lack of slug availability for a layout. By the time I was able to examine the CSS object, several rules had been applied already to the output, but this was awhile ago and my memory is definitely sketchy here. I recall writing a byzantine function which examined the rules and checked them against a set of allowed properties...I eventually abandoned that as nuts and just substituted my own object as I generally work with designers/producers who do not want the site owner to be able to modify visual elements (which sounds draconian, but is the way to keep a site "on brand", which is what they're paid to do)...

I should insist clients use the premium version (we rely on your plugin a lot), so duly noted. I'll go look at the premium page...I hope you have a dev license, as I have a local test box and if the plugin phones home, to your server it might look like I have 10 different sites running it, when in reality those are all on my local network and not exposed to the outside world. I insist clients buy their own licenses for plugins like SearchWP, will do the same for yours. Thanks for the prompt.

I have not used layouts the last few sites because of the identifier issue--instead using the template chosen for a page to prompt specific changes both in admin and the public view, but layouts are obviously the preferred way to do this.

One thing I would like to specify in layouts, and I don't recall being able to do this, is to have certain cells populated with new instances of particular widgets when the layout is chosen, and ideally, if that's possible, indicating somehow they need to be configured when viewing the page in admin (a red "Needs Configuration" line or similar in the admin view or an overlay(?) in the customizer view).

Not having a bunch of widgets waiting to be configured when a layout is chosen is one of the gripes I heard from editors...

[rogerlos]

This is how I would ideally (and incompletely) configure what I'm going to do with the editor. Anything not explicitly configured (or empty) would use Site Builder defaults, though there would be a way (setting boolean false) to completely remove the Site Builder default config.

"layouts": {
    "my_layout": {
        "locked": false,
        "templates": [
            // list of WP templates this can be used on
        ],
        "new_row": "second_row",
        "new_cell": "some_defined_cell",
        "add_rows": true,
        "rows": [
            // row objects or id of row configured elsewere
            {
                "id": "top_row",
                "duplicate": false,
                "delete": false,
                "drag": false,
                "order": 1,
                "columns": {
                    "number": 2,
                    "ratio": "even",
                    "direction": "ltr",
                    "editable": false
                },
                "sections": [
                    "attributes",
                    "my_new_section"
                ],
                "cells": [
                     "page_and_subscribe",
                     "default",
                     // could also directly contain a cell object
                 ]
            },
           "second_row"
        ]
    }
},
"sections": {
    "my_new_section": {
        "row": true,
        "cell": false,
        "fields": [
            // if I reuse a lot of fields, I might define them elsewhere, and ref by name,
            // or these can be "field objects"
        ]
    }
    // also allows standard sections to be modified (ie, fields added, deleted, etc)
},
"rows": {
    "second_row": {
        ...
    }
},
"cells": {
    "page_and_subscribe": {
        "sections": {
            // configured like row sections
        },
        "widgets": {
            // allows instances of widgets to be added by default
        }
    }
},
"fields": {
    // id, type, options, text, etc
}