• R


    Be able to include/exclude specific rows from a post's grid call.

    Exemple as the main display function parameter :

    get_laygrid($id, $type,$rows);

    My usecase

    I am using layGridder for my posts inner content.

    On my "archive/home" page, I would like to fetch the first rows of every post listed to be able to have a "rich thumbnail" that use what we love about LayGridder :
    easely configurable background color, image, video + foreground image, video, html, text.

    To do so I could use something like this :

    $rows = array(
        "fetch_type"  => "include",
        "numbers" => array(1)

    This would only fetch the first layGridder row of my posts.
    I could even lazyload the content of my post later afterwards, on user action for exemple with ajax and something like
    "fetch_type" => "exclude", "numbers" => array(1)"

    We could also manually loop through every row to do all sorts of things if we can get the total number of rows from a post :

    while( $i < $numberofrows ) {
        $rows = array(
            "fetch_type"  => "include",
            "numbers" => array($i)

    Also maybe there is already a way to do any of this. Even less straightforward I would be interested to know about it.

    posted in Feature Requests read more
  • R


    I would like to suggest the ability to have more than one gridder per post.
    That would enable having more complex designs. With sections unreveable, or queried under certain conditions

    I though of this solution after my previous feature request didn't have much success :

    This would fix my first request, but could also be a fix to :

    (ability to add multiple gridder as "fields" and add conditions)

    (separate gridder thus enabling to set "id" to each one and scrolling to them)

    (different gridders for different languages)

    Whether or not going through ACF, I believe it could probably give users many ideas and possibilities.

    posted in Feature Requests read more
  • R

    I wanted to share this. It is not a bug per se but more of what I see from here as a design limitation that translates in unreliable editing.
    But maybe I don't see the whole picture and it is as good as it gets and the fix i'm suggesting would break more things that it would actually fix.

    It is about the use of "vw" over "%" in some cases.

    First, they are shown as "%" in the back-end, which to me is confusing to see "vw" in the debugger.


    Also I believe "vw" is sadly unreliable because it include the scrollbar in windows, but the viewport limits the content before the scrollbar. Which makes the unit unreliable depending on wheter your page has a scrollbar or not, if the user is using mac or pc. But that's all W3C's problem and that is not (not really) the issue here.

    For layGridder, the use of vw translates in proportion issues :

    If the gridder in our webpage is not full-width : those 56% of space-above in the exemple screenshot can become way out of proportion.

    In the back-end, an element with 56% space above could be the same size as another element, and in the front-end, that first element could have doubled in height.

    More over, in the sole back-end : if you resize your editing window, elements will start to change in proportions, and you will have no idear how it will actually look until you save, refresh, see for yourself on the front-end at a certain window width.

    And while padding-top : 56vw; shows those limitations padding-top : 56% works perfectly in my tests within the gridder, always keeps the same proportions in front and back-end and no matter how you size your gridder in the page.

    This is to me the way to go for layGridder because it needs to integrate into other peoples code as a plugin while layTheme can easely use vw because the whole sctructure evolves around the same system.

    But Pierre, you could easely calculate how many vw is your padding-top: 56% :
    My gridder is 70% of page width so : 70*0,56 = 39.2vw
    So here we are : I just put space-above 39.2 and problem solved !

    That's only assuming my gridder has a width based on "%", not px AND that that % is consistent. It us actually my case but some other layGridder users could alternate between 50, 60, 70, 80% depending on viewport size or even on user action.

    But even for me, because of that W3C spec issues about how vw is calculated :

    • if there is a scrollbar, padding-top:56% will actually be 38vw.
    • If there is no scrollbar : padding-top:56% will be 39,2vw.
      And that difference is specific to my screen resolution and would be again different for someone else.

    So if there is no conflicts in the code, I don't see why we shouldn't use "%" instead of "vw" right away for element space-above, space-below ? And maybe a few other inputs could benefit from this also

    If there is technical conflicts and it's not a 10 seconds fix as I thought :

    I think it would be a very interesting addition to the lay family to offer more control around vertical space.
    Just as we can "use browser height for row height". Maybe we could see a "set row height" option, with the ability to set a row height in "%" of the width (to have a fixed width/height row ratio) or set a custom "vh" height to have more control over how much we see at the same time.
    Maybe could even have the option then to have "sub-rows" instead of "columns" (horizontal grid instead of vertical).

    Testings (here, i'm forcing row height via custom css just to test out. The "green" element is my stack with padding-top: 56vw // 56%) :
    vw :

    % :

    If someone wonders why I want a 56% padding-top on a empty stack element : it's because it results in a 16/9 aspect ratio to show to have every row the same size = the best size for video backgrounds.

    posted in Bug Reports read more
  • R

    @rsepierre I just checked. I think laytheme already behaves this way.
    Both mobile and desktop menus are in the DOM (one with display: none;).

    But for the actual Grid, laytheme swaps them completely (not sure if it's from a variable or ajax) so there is only one grid in the DOM at the one time.

    posted in Bug Reports read more