I've faced the same thing.

What I did was create a new Sites template profile - i.e. SPSCustomSites - copying everything from SPSSites.

Then delete the Sites area, and create a new area  called Sites, using the new custom template.

Then hack into 1033\SPSCustomSITES\LISTS\SITESLST\Summary.aspx, which is the default page  for the Sites area, and just below the HTML for the search bar, and the code for the Modify Shared Page link.

So after, this.......

<tr>

<td nowrap align="right" valign="top">

<SPSWC:RightBodySectionSearchBox runat="server" SearchResultPageURL="SEARCH_HOME" FrameType="None"/>

</td>

</tr>

Add this.......

<tr>

<td nowrap align="right" class="ms-vb"><SPSWC:EditModeSettingsLink runat="server" /></td>

</tr>

What kind of change are you trying to make?

I have typically made changes inside of the containers on the Sites Area
Summary.aspx page  using FrontPage and then used GhostHunter to reghost
the page. Let me know if you need more details.

The problem isn't that this page is not a Web Part Page, it is. The
problem is that the Web Zone's are attributed to prevent changes from
within a browser. I don't know _why_ they did this but it is relatively
easy to work around.

The Sites and Home areas, AIUI, are the most
difficult to modify. Remember portal server is a product that isn't
intended to be modified a great deal whereas WSS is a service that also
represents a horizontal development environment in which you can modify
all sorts of things.

I did this and ended up removing it because it was a very delicate thing and I didn’t trust end users to not blow up the page. After I added the Modified Shared page  link and started messing around with some web parts I completely blew up the Sites page. I can’t remember exactly what I did, as it was some time ago, but this solution should be used very carefully and on a test server first.

True, I did run into the same thing. If I remember correctly, what I did that blew up the page  was delete the sites  web part. I forget exactly what happened, so I deleted the area  and started over. Obviously not a great solution if you’re past the point of just starting out, and you already have several sites listed in the directory.

But can’t you just change the security on the Sites area so that end users don’t have the ability to modify  the views of the page? And then you could just train the administrators on the do’s and don’ts.

Or, once you have the page looking the way you want it, you could remove the Modify Shared Page link when you were done.

but isnt it all about the URL string?

?Mode=Edit&PageView=Shared

where is that site with all the strings to pass to sps!

It is partly about the string. The querystring, when it is in there, tells the SPSWC:EditModeSettingsLink control to display with the drop down menu. Without the control, you can go into Edit mode, but you can’t add any web parts.

I did the later, got in, did my business and removed the link.

Training I feel is completely dependent on the installation and the support team’s skill level. Another thing I have found with supporting SharePoint is that you tend to forget how you did something a year ago and the ramifications. I felt safer removing the link personally.

Sure you can:
mindsharpblogs.com/.../285.aspx

Or just replace the URL with this and press enter:
javascript:MSOTlPn_ShowToolPane('2');

The Add Web Parts Tool Pane will render just as if you had clicked on
the SPSWC:EditModeSettingsLink control.

I'm not fond of the SharePoint Portal Server Web Controls (SPSWCs). I've
had it on my TODO list to document the dozens of SPSWCs but, alas, time
is at a premium.

The three most important aspects of real estate may be "location,
location, and location". But for a developer, it must be "time, time,
and more time".