SaaS CMS has officially launched! Learn more now.

Content area horizontal placed blocks in edit mode


How do you set the content area if the content should edited in vertical or horizontal mode?

On the Alloy template site on the standard page there is a teaser / promo content area that in edit mode is shown as horizontal blocks. Using firebug I can see that EPi has added the class dojoDndHorizontal to do this.

But I cannot figure out how Alloy triggers this dojoDndHorizontal to be added.

The site I have is not built on bootstrap as Alloy is, instead we use Foundation.


Jan 31, 2014 14:14


Alloy never triggers anything regarding how the content should be edited. The UI, that is a layer on top of the site, will query the nodes inside the content area to try and determine if the underlying layout is vertical or horizontal. Of course, there might be scenarios that we dont handle here. I'll post the actual code that is used to determine this so perhaps you can see if you have a case that we don't handle:


if(/vertical|horizontal/.test(this.layout)) {
horizontal = this.layout === "horizontal";
} else {
horizontal = array.some(this._getBlockNodes(), function(node) {
var style = domStyle.getComputedStyle(node),
floating = /left|right/.test(style.cssFloat),
inline = /inline|inline-block/.test(style.display);

return floating || inline;

Jan 31, 2014 16:11

I am having this same problem and cannot figure out how to make this work.

The content area overlay is rendered with the correct position, width and height. However, the individual block overlays are rendered at the top of the content block, with a full width and minimum height. The problem is the same as shown in the screenshot in the comments at the bottom of this blog post:

The page template currently has the following code to render and edit the content area:

<div class="container">
            <div class="wrapper-100" @Html.EditAttributes(m => m.CurrentPage.FeatureBlocks)>
                @Html.DisplayFor(m => m.CurrentPage.FeatureBlocks)

Note that I am using a combination of 'EditAttributes' and 'DisplayFor' because when using 'PropertyFor', the problem is the same, but even worse because the edit overlay does not wrap over the entire height of the content area. 

Within the content area there are 2 blocks with the following markup:

<article class="page-feature">
    <!-- Some content here -->

The article elements have a left float, so if the code posted above is true, then I would have thought this would work already? They are also 50% width, and I have tried changing their widths to fixed pixels to see it would make a difference, but it didn't. No matter what CSS I change, they block overlays always have a CSS class of 'epi-injected-minSize'.

If anybody could give any further insight into how to make this work it would be most appreciated.



Edited, Jun 26, 2014 10:20

I have now managed to fix this, it seems to be a combination of 2 problems. I'll detail this here in case somebody has the same issue:


The overlay height issue can be fixed by adding a custom CSS class as described here:

However, the ViewDataName for adding the CSS class has changed to simply 'CssClass'. So the template code to render the content area is now:

@Html.PropertyFor(m => m.CurrentPage.FeatureBlocks, new { CssClass = "video-feature-content-block-edit-area" })

A special CSS file containg these classes is added to layout when in edit mode:

@if (PageEditing.PageIsInEditMode)
        <link rel="stylesheet" href="/assets/css/onpageedit.css">

In the CSS file the content area overlay and the individual block overlays need their overflow set to hidden:

.video-feature-content-block-edit-area {
    overflow: hidden;

.video-feature-content-block-edit-area div.epi-injected-minSize {
    overflow: hidden;

2. As the article elements have percentage widths of 50%, they only take up 50% of the div overlay added around the block. Therefore, the widths need to swap, with the div overlay set to 50% instead and the article set to 100%. Additionally, the overlay block div needs floating left. The complete CSS looks like the following (note that the 50% article width was only ever needed for screen width's >= 768px):

.video-feature-content-block-edit-area {
    overflow: hidden;

.video-feature-content-block-edit-area div.epi-injected-minSize {
    overflow: hidden;
    float: left;

@media only screen and (min-width: 768px) {
    .video-feature-content-block-edit-area div.epi-injected-minSize {
        width: 50%;

.video-feature-content-block-edit-area div.epi-injected-minSize {
    width: 100%;

It does seem odd that the UI can't seem to handle percentage widths for the block elements, hopefully this is something that EPiServer can improve in the future so that custom tweaking is not required.

Jun 26, 2014 12:44

Did someone ever fix this properly? Preferably with some form of manual override or the like. I'm using display: flex, which seems to end up being vertical. Which just doesn't fit at all.

If there is no such override, there should be one, instead of assuming the CMS knows best every time. Stuff changes quickly on this The Internet.

Feb 26, 2016 14:32

+1 We're using display flex grids too and Episerver guess about layout is wrong. Would be nice to have a way to configure it.

Mar 23, 2016 13:42


Bootstrap 4 uses flex box, so we really need this!

Mar 06, 2017 14:30

I'm just going to leave this here :

Let me know if it works, we're not using flexbox as far as I know but at least you should be able to force the direction.

Edited, Mar 07, 2017 19:07
* You are NOT allowed to include any hyperlinks in the post because your account hasn't associated to your company. User profile should be updated.