Recently, I noticed when I have the following code, my text wraps and ignores my padding for the second line.

<style>

.menuItemLvl2 {

Padding-left: 24px;

}

</style>

<div><a class=menuItemLvl2 href=#>Restructuring & Recapitalization</a></div>

I wanted the hyperlink a tag to wrap and respect the padding. I also had highlighting on the A hyperlink tag for :hover state, so I coudnt use Margin-left:24px.

I applied the following CSS to fix my issue: ( I only add the green highlighted text to the above code)

<style>

.menuItemLvl2 {

Padding-left: 24px;

Float:left;

Width:200px; /* Note: you cannot use 100%, as the padding pushes the element out of its container that has a width of 224px. Use container width minus padding of this element*/

}

</style>

<div><a class=menuItemLvl2 href=#>Restructuring & Recapitalization</a></div>

And on hover: (note, I did not include the code for a:hover in this example, but just set the background-color: #666666 or whatever color)

Works in Firefox and IE7.

My last post offered clues as to why Data View web parts break. All my previous web parts were using custom Layouts to strip out all the surrounding layout tables.

Here is a rough idea how the default Layout is constructed.

Figure 1- The above is a default Multi-item XSLT Data View web part template without paging (Display all items). Notice how there is a Table Row (TR) for each data row.

Normally, in the past, I did not want my data to be separated in its own table row (TR). I wanted my data to be separated with a line break, or all on the same line, or all in the same row. I would change the layout.

The problem with this is, after multiple re-saving of the ASPX page in SharePoint Designer, the page begins to auto insert generated code into the page or DataView web part. This causes the web part to break and you can lose your template.

The workaround:

Instead of changing your layout, try to work with the existing layout. That’s it!

Here is a diagram of what I wanted:

Figure 2- Basically, it’s the same template as above. I removed the TH text, but left the code. For the Green TD above, I used XSL:Text disable-output-escaping=yes to construct all my conditions.

The above is just my example, as there is a lot of formatting. Basically I have Id’s, Classes, and Numbers I sort by and place in their own TD’s, TR’s (Every 5 cells), and headers for every certain number. Each class has its own TD. (specific to my data schema)

The point I am trying to prove is that outside of the For-Each is intact. All my modifications were around this for-each, but not to my TH class, or any other template.

I got the following error when developing my web part and having my manager log in to check the page. But the page worked fine for me, and was not checked out, as I was not using Publishing Features.

Unable to display this Web Part. To troubleshoot the problem, open this Web page in a Windows SharePoint Services-compatible HTML editor such as Microsoft Office SharePoint Designer. If the problem persists, contact your Web server administrator

The Problem

The page would load fine for me in browser. In SharePoint Designer, I would have an older data set in my data view web part. I would break the web part when I did a Refresh Data Source, so I left it as it was. I had enough data to continue building out my template.

Once I had my manager review my work on his computer, the page gave him the error Unable to display this Web Part. So, I logged in as myself (To make sure the old template was not cached on my computer) and it worked for my user.

The Solution

Follow-up: This is not a solution, but a work around. Upon Re-saving the page in SPD, the error occurred once again. See future post on 10/15/09 about XSLT layouts and why they break your data view web part.

At one point, I did have the page checked out, but it seem to automatically disguard it when I tried to check it back in. Really weird, so I made a copy of the Default.aspx page that contained my web part. I right clicked the copy and said Reset to Site Definition.

I noticed the web part was still on the page. I guess since web parts don’t support versioning, resetting the page only resets the code around web part zones. My web part was still on the copy. I suspected that if I reset the page and that it just might work now. I logged in as another user and it worked.

Here are the steps:

1. Make a copy of the ASPX page containing your “Broken” web part
2. Reset the COPY to Site Definition
3. Try the newly reset page and see if it works for your users.

Summary

I have noticed a lot of XSLT web part errors. I am starting to log them in one place as an archive of solutions, rather than abandoning my web part and starting over each time I get an error.

Unable to display this Web Part. To troubleshoot the problem, open this Web page in a Windows SharePoint Services-compatible HTML editor such as Microsoft Office SharePoint Designer. If the problem persists, contact your Web server administrator.

This error could be caused by missing double quotes around your HTML markup attributes. For instance, the error below is missing double quotes around the table width=”600″ attribute. Simple change width=600 to width=”600″ and everywhere you have an attribute value (This includes classes, etc.).

Figure 1- Unable to display this Web Part. To troubleshoot the problem, open this Web page in a Windows SharePoint Services-compatible HTML editor such as Microsoft Office SharePoint Designer. If the problem persists, contact your Web server administrator.

If you have seen this error, there might be a very simple solution.

The Solution:

Make sure all HTML template attribute values are contained in double quotes (eg. “value” and not just value.).

In my above example, I modified a Table tag inside my body template of the Data View web part. I replaced <table width=”600″> with <table width=600> and got the above error. This happens with classes and all HTML tag attributes (class=”Testing” is valid for an XSLT template in SharePoint, whereas class=testing causes the Unable to display this Web Part error.

This error is really broad, and I’m sure it won’t help everyone, but it’s a good start and easy fix for some situations.

Eric Schrader goes over his best SEO Tips. First, always post your keywords as a page title. This is the number one way to get to the top of search engines.

Second, Make sure your HTML output is complete, and not patched together, or all images. You want the text to be indexed.

Third, Add links next to your sites mission statement, like More about Eric, etc. When people click on these links, your region towards the top of your page becomes indexed. Div layer templates are a good way to get your mission statement to the top of your HTML, and position it on the right or below navigation by floating the layer. I have found that location or having a link indexes the content as a Google description of the site.

Why am I writing this post? Well, I wanted a blog post that had my name. Right now, my name is #16 when I Google “Eric Schrader”. I want to be 1^st. Give it a few weeks and after I forget about it, I will probably be in the top 2 or 3 results for Eric Schrader.

Also, keywords that have to do with your blog will help as well. For instance, I will say SharePoint a lot, just to make clear that’s what my blog is about. Notice how this is also in my title.