In our environment, we have a small number of custom web parts that work with our company intranet. Let’s call them “Current News – Left” and “Current News – Right”. They take information from the “Current News” list and show them in two different columns on the page. All in all, it works.
The problem is that some people see the Left and Right web parts and think they want to have the same layout on their page. They put the page into Edit mode, add the web part, and BOOM! Their page now throws a generic error and they have no idea how to get back into the page, much less what to do to fix it.
The problem is that the way these two web parts were coded, they require that the “Current News” list already exist. If the list exists but has no items, that’s fine. The Left and Right web parts are empty. But if the list doesn’t exist at all, the page blows up.
In order to get the page into a mode where I can delete the web part(s), I go to the URL of their page and add “?contents=1” at the end. That gives me the Web Part Page Maintenance screen for that page, and I can close, reset, or delete the web parts from that interface.
Once I remove the “Current News” web part(s), the page works again. The other way I could fix it is to add the “Current News” list, but knowing about the “?contents=1” trick gives me a lot more control, and can be used in various situations.
So, yesterday I’m working away on migrating a form we have into a SharePoint list. I build all the columns, and then start customizing the form with InfoPath. All is going well. That is, until I made changes to the list columns. I found out very quickly that you need to pay attention to when you do this in relation to the InfoPath form editing.
If I make the column changes in the list and then open the form up for editing in InfoPath, I get the following message:
Basically, the list has changed, and would you like to have your InfoPath form updated with the new list of fields? For me, the answer is yes.
The mistake I made was once again updating columns in the list, but neglecting to close the InfoPath editing session first. That gives you *this* message when you save the InfoPath form:
Basically, you changed the list columns, but the InfoPath form doesn’t know about those changes. So I’ll just overwrite the column changes and make the list match this InfoPath form, OK?
No, not really!
The two different situations make sense when I think about it, so that’s not really an issue. The problem is that it’s easy to think you’re answering the wrong question if you don’t pay close attention and just quickly choose the option to continue. Fortunately in my case, the changes I lost were to two new fields that I could quickly recreate. It could have been much worse.
Recommendation… Make sure your InfoPath editing session for the list is closed before making column changes. THEN you can open up your form and continue…
This’ll teach me to not try new things on the spur of the moment… 🙂
I was setting up a new site collection, nothing fancy. Normally when I do that, I base it off the Team Site template, just because it gives me a few of the lists that users might want. This time, I decided to go with a Blank template.
I’ll just keep it basic, I thought…
All was fine, custom list created, columns added. Now time to customize the list forms in InfoPath, and… Where’s my Customize Form ribbon bar button for the list?
I hate things that should be so simple to “fix”, but still take me a long time to figure out. Turns out that many of the Site Collection Features I take for granted by basing a site off of the Team Site template aren’t there for a Blank template. After some back-and-forth comparison, I found that I needed to activate the SharePoint Server Enterprise Site Collection features option. Once I did that, I got my Customize Form icon back, and I can carry on.
I’ll note that here so when I forget about it in three months and hit it again (because I don’t learn), I’ll vaguely remember… “Hey, didn’t I solve this once a while back?”
It’s one thing to be able to build a Hello World application using a new technology. It’s another thing entirely to take the next step and build something that is actually useful. That’s the jump that Microsoft SharePoint 2010: Creating and Implementing Real-World Projects makes. The authors, Jennifer Mason, Christian Buckley, Brian T. Jackett, and Wes Preston take ten different business scenarios, explain the business requirements, discuss the different architectural options (along with why they chose a particular path), and then proceed to build the solution in a step-by-step fashion. The book isn’t perfect, but I think it has some significant value for SharePoint developers.
Introduction; Building a Project Management Solution; Building a Training Registration Management System; Building a Basic FAQ Solution; Building a Learning Center; Building a Help Desk Solution; Building a Remote Teams Activity Site; Building a Team Blog Platform; Building an RFP Response Solution; Building a Contact Management Solution; Building a Resource Scheduling Solution; Resources; About the Authors; Index
SharePoint is flexible in that you can accomplish a task or build a solution in multiple ways. That’s also a problem because you could easily build yourself into a corner without understanding how you got there. Having a real-world solution architecture analyzed by experts is extremely valuable, and you can apply those concepts in many other areas. I also appreciate how the analysis of the business requirements takes place, as it gives you a feel for how SharePoint can be applied to your own organizational needs. The actual solution they build is almost secondary to the value I get from those first two points.
A number of the reviews have mentioned that there are errors when trying to follow the step-by-step instructions on building the solution. That’s unfortunate,as people new to SharePoint will end up getting confused more than they already are. This is a case where I’d recommend getting the e-book version and then bookmarking the errata site. If this was one of many tech books covering the same topic in the same fashion, I would probably recommend bypassing it. But there’s too much value in the overall content here to go that route. I’ll take the value of the analysis and real-world scenarios, and figure that the troubleshooting is just a bonus. 🙂
I’m looking forward to working through all these sites and making them available as demos for my customers. Microsoft SharePoint 2010: Creating and Implementing Real-World Projects will definitely improve my overall SharePoint skills.
Obtained From: Publisher
In my life as part of the IBM Notes/Domino community, I run a blog called Lotus Jobs. This was a “pay it forward” project of mine to share potential job opportunities I’d run across on Google News Alerts, in hopes that people who were out of work could find a new home somewhere. I worked at Enron at the time of the implosion, so I know what that unemployed feeling is like. It’s NOT pleasant… I post whatever I find in a single daily post, and then tweet it on an account called @LotusWatch. That account follows no one, as it’s more of a broadcast mechanism to reach people who are interested.
I’m taking this concept and starting the same thing on the SharePoint side. I realize the effort of finding a SharePoint job is far easier right now than finding a Notes job, but still… if it helps someone, it’s worth doing.
The new blog is SharePoint Jobs. The new Twitter account is @SPJobWatch. When I make my daily job post on the blog, I’ll tweet it on my personal Twitter account along with the @SPJobWatch account. I’ll probably also put a link on Google+ just to make things more visible.
If you’re interested, feel free to follow the Twitter account, subscribe to the blog, put the blog on your RSS reader, etc. I’ve done the Lotus Jobs blog concept for over a year, so it’s an ingrained habit. Unless I get some major negative feedback over this new effort, I think this should become part of my daily routine.