Question

On our SharePoint 2010 Enterprise environment, every page is having some strange behavior with the web part zones. In Edit mode, it essentially looks like this:

enter image description here

In non-edit mode, it looks even worse as text and document library columns are getting hidden underneath the adjacent web part zones. What in the world is going on here?

We tried the suggestions on this blog to add CSS margins and padding to the class "MS-SPzone", but this has no effect if a web part has several columns in a list view (still overlaps).

EDIT: Note that this is a page template based on a custom Page Layout, and that Page Layout uses some custom CSS as well, all made by a 3rd party, which is likely why this problem is occurring in the first place (I assume that SP default page layouts do not overlap zones like ours do!)

EDIT: Here is what I think may be the relevant custom CSS for the page layout (non-edit-mode)

.col-50
{
    float: left;
    width: 49.9%;
}
.col-fluid-1
{

    float: none;
    width: 100%;    
    margin-right:auto;
}
.col-fluid-2
{
    zoom: 1;
    margin-right: 215px;
}
.right-wp-zone-col
{

    float: right;
    width: 200px;
    border-left: 0 solid transparent;
}
.edit-mode-border
{
    border:transparent 1px solid;
    padding:8px;
    margin:1px;
}
Was it helpful?

Solution

You need to make divs to be rendered as tables in edit mode:

<div class="container convertTable">
<div class="row convertTable">
<div class="col-md-6 convertTable">

</div>
<div class="col-md-6 convertTable">

</div>
</div>
<div class="row convertTable">
<div class="col-md-12 convertTable">

</div>
</div>
</div>

here is jquery code:

<!--MS:<Publishing:EditModePanel runat="server">-->
            <script type="text/javascript">//<![CDATA[
jQuery( document ).ready(function() {
var pageEditTableClass="pageEdit-table", pageEditFullWidthClass="pageEdit-fullWidth";

jQuery("table div.container.convertTable").removeClass("container").addClass(pageEditTableClass).addClass(pageEditFullWidthClass);
jQuery("table div.row.convertTable").removeClass("row").addClass(pageEditTableClass).addClass(pageEditFullWidthClass);
jQuery("table div.col-md-12.convertTable").removeClass("col-md-12");
jQuery("table div.col-md-3.convertTable").removeClass("col-md-3").addClass("tableCol-3");
jQuery("table div.col-md-4.convertTable").removeClass("col-md-4").addClass("tableCol-4");
jQuery("table div.col-md-5.convertTable").removeClass("col-md-5").addClass("tableCol-5");
jQuery("table div.col-md-6.convertTable").removeClass("col-md-6").addClass("tableCol-6");
jQuery("table div.col-md-7.convertTable").removeClass("col-md-7").addClass("tableCol-7");

jQuery("table div.col-md-9.convertTable").removeClass("col-md-9").addClass("tableCol-9");
});
//]]>
</script>
<!--ME:</Publishing:EditModePanel>-->

put the script in EditeModePanel to make script work only in Edit Mode

css:

.cell-margin {
    margin: 5px 0px 5px 0px;
}

.tableCol-3 {
    display: table-cell;
    min-width: 24.9%;
}
.tableCol-4 {
    display: table-cell;
    min-width: 33.3%;
}
.tableCol-5 {
    display: table-cell;
    min-width: 41.6%;
}
.tableCol-6 {
    display: table-cell;
    min-width: 49.9%;
}
.tableCol-7 {
    display: table-cell;
    min-width: 58.3%;
}
.tableCol-9 {
    display: table-cell;
    min-width: 74.9%;
}

OTHER TIPS

Open the site in IE or Chrome and use the developer tools (press F12 in either one). You can use the "select element by click" (ie) or "select an element in the page" (Chrome) to visually select the items and see dynamically what CSS is being applied. It will also show what file(s) those CSS rules come from. As was stated previously, I bet there is some custom CSS getting loaded somewhere.

With the developer tools, you can even tinker with the CSS live to identify exactly which changes need to be applied.

DIVS and TABLES do not tend to play nicely together so if you have laid out your zones using DIVs SharePoint will render the web parts as TABLES.

I know the general preference is to avoid tables where possible but try putting your zones in a TABLE and I am pretty sure it will resolve the problem.

from my understanding there are two places that could turn out this kind of result! one is the css as others have noted and the other is the page layouts! the page layouts is what holds the body content! it could be changed or the css could have been changed!

The site in question, has it been modified or not? im talking about page layouts or css (custom)? or is this result from ootb version?

if you dont know you need to change the reference for the page layouts in the masterpage, for css you could change it within the site collection where you change the masterpage!

when i hit that issue along time ago it was partly due to the layouts page rather than the css as i put in some direct css on some html tags lol, it was due to the css tag position that efected other layout positions for all webparts!

you could also get that effect when ammending the layouts within sharepoint designer desing view aswell! changing the layouts reference to the default layouts.aspx would be the first thing that i did to see direct changes :).

Licensed under: CC-BY-SA with attribution
Not affiliated with sharepoint.stackexchange
scroll top