Hard to select parts inside layouts

Enonic version: 6.4.1
OS: OSX

We’ve created two layouts, one for a single column and one for two columns. Great success. Adding content to these is pretty easy, but when I want to change something inside that part, I can’t select the part - only the layout.

Instead, I now have to click the inspector tab and select the part from there - which is kind of sub-optimal.

This happens in Chrome (newest) on OSX - haven’t tested any other browsers.

Would be great if this could be prioritized for fixing in the next patch or minor release. :slight_smile:

Hmm, works fine for other sitrus we have. This sounds like some kind of css issue related to your code. We need to see the actual code to understand what’s happening.

The CSS is pretty straight forward - it uses the Bootstrap grid (so floats).

HTML:

<a data-th-href="${link}" class="entrance-box" data-th-classappend="${design}">
    <div class="entrance-box-inner">
        <div class="entrance-box-image"
             data-th-style="'background-image: url(' + ${image} +')'"></div>
        <div class="entrance-box-content">
            <h2 class="entrance-box-heading" data-th-text="${heading}"></h2>
            <p class="entrance-box-text" data-th-text="${text}"></p>
        </div>
    </div>
</a>

SCSS:

/****************/
/* Entrance box */
/****************/

.entrance-box {
    border-bottom: 0;
    display: block;
    padding: 0;
    text-align: center;
}

.entrance-box.mod-grey-border {
    border: 1.2rem solid $color-grey-lighter;
}

.entrance-box.mod-orange-border {
    border: 1.2rem solid $color-secondary;
}

.entrance-box.mod-white-border {
    border: 2.4rem solid $color-white;
}

.entrance-box-inner {
    background-color: $color-white;
    @include clearfix();
}

/************************/
/* Entrance box content */
/************************/

.entrance-box-content {
    padding: 1em;

    .entrance-box.mod-white-border & {
        padding: 0;
    }
}

.entrance-box-heading {
    @include font-size(3.6rem);
}

.entrance-box-text {
    @include font-size(2.2rem);
    line-height: 3rem;
}


/***********************/
/* Entrance box images */
/***********************/

.entrance-box-image {
    background: no-repeat center center;
    background-size: cover;
    padding-bottom: 56.25%; // 16 / 9
    width: 100%;
}

/*****************************/
/* Full-width entrance boxes */
/* (only for laptops and up) */
/*****************************/

@include laptop {
    .col-xs-12 > .entrance-box {
        text-align: left;
    }

    .col-xs-12 > .entrance-box .entrance-box-content {
        padding: 9.7rem 5.3rem 2rem;
        float: left;
        width: 33%;
    }

    .col-xs-12 > .entrance-box .entrance-box-heading {
        @include font-size(2.8rem);
        margin-top: 0;
        margin-bottom: 2.5rem;
    }

    .col-xs-12 > .entrance-box .entrance-box-text {
        @include font-size(1.8rem);
        line-height: 2.6rem;
    }

    .col-xs-12 > .entrance-box .entrance-box-image {
        float: right;
        padding-bottom: 37.125%; // 16 / 9 (divided by 66%)
        width: 66%;
    }
}

/********************************/
/* Quarter-width entrance boxes */
/* (only for laptops and up)    */
/********************************/

@include laptop {
    .col-md-4 > .entrance-box .entrance-box-heading {
        @include font-size(2.8rem);
        margin-bottom: 2.5rem;
    }
}

Is this the part called “Entrance Box”? I need the controller, and the Layout too. I will download all these from Github and try this out locally and see why this behaves odd. Have not experienced this myself before.

Seems like the reason for this behaviour is that you have <a> in the root of your part and we don’t disable links in the root. I don’t think there is any reason for not disabling them, so we’ll fix that. Meanwhile you can wrap your part inside a <div> element - this should show a border around selected part and also disable links inside.

Hi again,

I have tested this with your code and found a few issues:

(1) To define a layout in XP we have a best practise / recommended way.
You do this:
<div class="row" data-th-attr="data-portal-component-type=${component.type}">
Update to this:
<div class="row" data-portal-component-type="layout">

In your code it is “dynamic”, the controller sends the data to this and populates it. You can make your code simpler by just setting it to “layout”. Since this always will be a layout it’s no point in letting the controller change this. Also it could fail in the future, or behave unexpected.
Use “data-portal-component-type”-commands “raw” without coding.

(2) Part “Entrance Box” crashed when I first use it because the controller code expect the part config to be set from the admin first. It helps the user a lot if empty config is captured and handled in the part.

(3) Our bad =) See comment by @ase

@ase - Ah, so that’s what’s causing the issue. Thanks :slight_smile:

@bwe - Ah thanks. Please update the docs on layouts to reflect this best practice :smile:

About your second point - what should be the correct behavior? If a part crashes when a required field is not filled out - perhaps that should be something XP actually handles by default instead? Perhaps it could show a “required fields are missing - click here to fill them out!” box instead of the default red error box? It’s a pretty common use case, so it would be a pain to implement for each part you implement.

Good catch, didn’t know about that. I have now updated 6.4 and master-branches on the docs for that specific page. There is no meaning in making it dynamic so we shouldn’t confuse people with that type of code in the docs. Thanks!

I usually send in an object of null, like “articles”, and handles that in the wrapper element - “Part not customized”. But yes, maybe you have an idea there, that an invalid part shouldn’t even get passed to the controller. However, there might be some issues down the line with that approach, even some corner cases might stop working. Anywho, since this is a fairly easy manual fix in the controller I don’t think a feature like that is very close in the making.

Great about the docs :slight_smile:

although we can definitely do what you suggest - to handle this in a controller - it’s a task that’s going to be re-implemented again and again and again for all parts that’s ever created with any kind of required fields. Many users will find it easier to just skip requiring fields - while implementing a “click here to configure” feature would save tons of developers lots of time.

I’ll implement it for our part, but I strongly suggest you consider implementing some kind of “shortcut” in a future release.

cc @tsi

1 Like

Just found out that the entire attribute “data-portal-component-type” has been made redundant (in 6.4 or 6.3)! So you can just delete the whole thing and your layout will still work. It is injected by XP instead to make the Page Editor behave.

1 Like

FYI - I believe component type has not been required ever, we fixed that just before we launched 5.0.

Also, in terms if validating part forms, The reason they are not validated yet is simply that we need to create some nice UI to reveal what is not valid in The page. Its in The backlog :slight_smile:

2 Likes