I wrote a feature to deploy a couple of pages into a Pages library on a site. The idea was that these were search pages, and they’d be going into a Search Center. My feature had an Elements manifest of:
<?xml version="1.0" encoding="utf-8"?>
<Module Name="CustomSearchPages" Url="Pages" RootWebOnly="FALSE" Path="Pages">
<File Url="advanced.aspx" IgnoreIfAlreadyExists="TRUE" Type="GhostableInLibrary">
<File Url="contentresults.aspx" IgnoreIfAlreadyExists="TRUE" Type="GhostableInLibrary">
Yet when I activated this on my Search Center, the pages weren’t installed. This was weird, ‘cos I’d done nearly exactly the same thing to install my custom Master page. I began swapping bits of the Master Page feature into my Search Pages feature to see if they worked, which at first they didn’t. Then, by accident, I tried installing my Search Pages on my root site, and they did install.
There followed a bit of wild, stab-in-the-dark guessing. I’d seen lots of examples of installing new page layouts, or installing new master pages. These should all go in the root site (or ‘root web’), and so their Module node would specify
RootWebOnly="TRUE". I could find very few results, though, where
RootWebOnly="FALSE", which is a little unusual on Google. What if the thing that made a module only install on a root site was the presence of a
RootWebOnly attribute, rather than the value of it? I tried:
<Module Name="CustomSearchPages" Url="Pages" Path="Pages">
for my module tag. Well, that’s what it turned out to be. I removed the
RootWebOnly="FALSE" attribute, and suddenly my pages would install. I guess I was stupid for trying to be explicit in saying that this feature was not only for the root site. I’ve gotta be honest, that sucks, and it wasted me 4 hours. Clearly, it shouldn’t just be the presence of the attribute; by setting it to False I was saying specifically that the feature was not for root sites only. Someone was shoddy in their processing of the XML.