Today’s
topic is another one of those items that has been sitting in my idea queue for
quite some time... since someone recently bumped up against this problem
(again), I figured that it would be good to mention this sooner than later...
First, a
definition...
Form pages - The pages that allow the editing,
creation and viewing of lists and their corresponding items. These pages are
found in the “Forms” folder of any list.
And now, a caveat...
Do not add any WebParts
to form pages. Placing WebParts on the form pages is not supported.
“Wait?
Did you just say that I can’t add WebParts to a form page?”
Yes.
“Don’t
the form pages have WebPartZones? And, therefore, you should be able to
add WebParts to the zones?”
Technically,
yes to both questions.
“So
why is adding WebParts to those pages unsupported?”
Form pages,
although technically web part pages which do contain zones, were not designed, or
tested, to be as fully operational as standard web part pages. They are
in a class of their own. As a result, you may run into weird behaviors when you
add a WebPart to a form page. This is reason the “Modify Page”
link/functionality was explicitly removed from the form pages.
“How
about if use FrontPage? Or can I use the browser UI? How about
adding via a site template? Will that make it a supported action?”
No. The method
by which parts are added doesn’t matter.
Bottom line...
Default
form pages were not intended to be used like a standard web part pages. If
you add a WebPart to a form page, your page will move over to the unsupported
category.
-Maurice