Bug: Empty placeholder with min-height not 'dropable' [4.2.1650] - Bugs & Issues - Bugs & Issues - Progress Community

Bug: Empty placeholder with min-height not 'dropable' [4.2.1650]

 Bugs & Issues

Bug: Empty placeholder with min-height not 'dropable' [4.2.1650]

  • Bug: Empty placeholder with min-height not 'dropable' [4.2.1650]
  • Ok...

    I'm running into an issue where (probl because of a combination of min-height+ 2 placeholders) that I'm not being able to drag content onto a placeholder when editing a page.

    This will be a tricky one to reproduce/explain but I've got the following code on a custom masterpage:

    <div class="leftcolumnb">
        <div class="leftcolumnc">
            <asp:ContentPlaceHolder ID="placeholder_introleftcolumn" runat="server" />
        <asp:ContentPlaceHolder ID="placeholder_introleftcolumnbelow" runat="server" />
    and the css:

    Inside columnb I first got the columnc placeholder (with a min height of 180px) and directly underneath it comes the 2nd placeholder. This way if the top placeholder isn't filled, content put in the 2nd placeholder will always be pushed down 180px.

    I've added the 2nd placeholder, because currently users can drag content outside placeholders, but that's being fixed so I needed that 2nd placeholder.

    However if I drag content onto the top placeholder, it says 'drop here' but it gets automatically pushed down to the 2nd placeholder. (probl because of the min-height?).

    The only way to resolve this (after some hours fiddling) is add the following css-line:
    .zeDockZoneEmptyz-index:999999 !important;


    I filled it as a 'bug' because I've ran into this and several (less worse scenario's) where you'd have to 'cheat' to get something dropped in the right placeholder. But maybe I'm overlooking something because I'm not fully up to speed how Sitefinity transforms a placeholder into a RadDock panel....

  • Different project, similar issues... and another workaround in case peeps are reading:

    <div class="sp-content-right">
        <div class="s-header"><asp:ContentPlaceHolder ID="pl_sheader" runat="server" /></div>
        <div class="s-image"><asp:ContentPlaceHolder ID="pl_simage" runat="server" /></div>
        <div class="s-text"><asp:ContentPlaceHolder ID="pl_stext" runat="server" /></div>

    Only by giving each placeholder a css-style height:auto; I'm able to drag content onto them...

  • Hi Jochem,

    Can you provide us some access to you dev server? A rough sketch of the desired result will be also very helpful!

    From the CSS that you have provided I see that the you use overflow, max-width, min-height which probably causes the problems with the SF Page editor. As you know the editor's elements are higher and wider than the actual content from the provided design and respectively the placeholder wrappers shouldn't have any restrictions like overflow or min-height.

    All the best,
    the Telerik team
    Do you want to have your say in the Sitefinity development roadmap? Do you want to know when a feature you requested is added or when a bug fixed? Explore the Telerik Public Issue Tracking system and vote to affect the priority of the items
  • 302885_sf-fixedplaceholder.PNG
    Hey Jordan,

    Thanks for replying. If you take a look at the first screenshot (sf_fixedplaceholder.png) you see the 'current/desired' backend behaviour. A header with a red background and white text, underneath a 'full-width' image and lastly a text inset on a gray background.

    First (to start of a nice flame) I strongly disagree with your opinion "...the placeholder wrappers shouldn't have any restrictions like overflow or min-height."

    I always surround my placeholder wrappers with a certain class which most of the time have some width/height restriction. Why? Because I can't count on my clients being frontend engineers.

    As an example, you'll see in the screenshot the image (currently in a contentblock, but could just as easily been an image widget).

    A client needs to drop an image there, (s)he select from already uploaded gives it a nice alt description and forgets to scroll down open up the resize menu to resize it. Wham! A 1200px wide image gets dropped on the page, client in panic and I get a call. Even if the client was smart enough to select the resize menu and select a size, the appropiate size isn't visible for the client because (s)he can't tell how wide the side column is...

    So I wrap the placeholder in a <div> with a class, that makes sure it gets a fixed width/height and overflow hidden, so even in worst case when the client drops a 1200px image on it, the website won't break. 

    Yes in an ideal world where end users are front end engineers, I totally agree with this approach not being the correct one, but since I'm dealing with realworld clients, I've found this method to be the most failsafe.


    But back to the issue... I can put an example in an empty project, zip it up and send it no problem. Will be end of the day though.

    But the problem comes from the fact that there's no height assigned. When certain placeholders have a (fixed) height and others don't, the ones that don't have a height assigned can't be used in the backend because the BackEnd editor jumps to those placeholders.
  • Hello Jochem,

    Here is my proposal for this specific case:

    1. Create custom layout element with three placeholders 

    2. Set a class name to the second placeholder
    3. Add the image width:

    .second_placeholder .sfimageWrp
            width: 100%;
    .second_placeholder .sfimageWrp img
            width: 100%;

    With this approach when the user drops really wide image it will fit the container. Also they shouldn't enter any class name by hand.

    Please send me you theme/template files at your convenience.

    Kind regards,
    the Telerik team
    Do you want to have your say in the Sitefinity development roadmap? Do you want to know when a feature you requested is added or when a bug fixed? Explore the Telerik Public Issue Tracking system and vote to affect the priority of the items
  • Hey Jordan,

    My bad...
    Forgot to create an empty project and zip it up, sorry. Will get to it asap.

  • Hey Jordan,

    I've sent an email to support@ containing a sample project.
    Attached you'll see 2 screenshots (one frontend, one backend edit) to describe the 'pain points'.

    First, take the 'Header'.
    Since it has a fixed min/max height it doesn't flow. I've actually made it a tad larger so you can just see the black background in the page editor. When no widgets are dropped on a placeholder it has a solid white background, which as a result nearly hides (or sometimes makes it very difficult which placeholder it is) the area.

    Secondly, I've tried to illustrate the aside/height problem.
    There are 3 areas there, same as in my last example (header, image and text).

    I always wanna show the header, regardless of contentblock being dropped on it, the other two are optional so to speak. If you take a look at the BE screenshot, you'll notice that only 2 placeholders are visible because the placeholders overlap each other.


    As mentioned before, I can work around it and your solution and your proposal is a nice one, because it would be done in page edit instead of hard coded in the masterpage...

    ... however, knowing some of my clients, I can't count on them to use it properly and if they forget, I get blamed for the site being broken.


  • Hello Jochem,

    I have reproduced the customization of the project and the problems that you have faced. 

    About the problems with the sidebar widgets:
    At first I was unable to drop anything inside the placeholders and initially only two placeholders were visible, so I set:

            position: relative;
            float: left;
            width: 100%;

    After adding these rules I think everything works fine. Anyway, I recommend my previous proposal with custom layout element - you can put it in the template, so the content writers don't need to drop it anywhere and will be more flexible if there is a case when you need to reuse it.

    The problem with the header - in this specific case I am not sure why you are using min-height and max-height with same value - is this some kind of restriction for the content writers? 

    Also about the white background that hides the black background and it is hard to recognize which placeholder you are going to use - here is one simple solution for such specific cases:

    #cpw_header .sfPageContainer.zeDockZoneEmpty
        background-color: rgba(255, 255, 255, 0.3);

    Also you can set you custom background. Here is the result of my test.

    the Telerik team

    Do you want to have your say in the Sitefinity development roadmap? Do you want to know when a feature you requested is added or when a bug fixed? Explore the Telerik Public Issue Tracking system and vote to affect the priority of the items
  • Hey Jordan,

    Thanks for the extensive answer even though these are edge cases.

    You're right, I can't 'protect' the site from everything so min-height/max-height and overflow hidden settings should be used less. In this case it was to force a heading to be a height even without content but also forcing the rest to get hidden in case a content writer drops an entire paragraph into it or a wrongly sized image.

    The problem with assigning float:left;width:100%; to the cpw_asidetext is that this way always a background will show, even if there's no content. I was looking for a way that would not show the div when no content's entered but show up when someone drops a widget into it.

    But as said before 'good is better than perfect' and I should trust content writers more.


    Changing the background color is a neat trick with these extra classes, will be very useful in case you are dropping/hovering a widget as well (white text color on a yellow background is unreadable). Thanks, extremely  useful!.