Here’s an example:

So what causes it, and what can be done about it?

It seems as though the disparity between the homepage and other pages is caused by the browser switching between the Standards and Quirks rendering modes. I’ve performed cursory testing in Firefox (v4.0), IE (v8.0 and v9.0) and Chrome (v10.0) and they all render the PeopleSoft homepage in Quirks mode by default and other pages in Standards mode.  I suspect that this is due to the lack of a doctype in the homepage – as this is present in other pages.

There’s an excellent bookmarklet here which tells you which render mode you’re currently in (although you can also use browser specific tools like Firefox developer’s toolbar and the IE Dev Tools).

Regardless of which mode Firefox and Chrome are in they render the page correctly (and by this I mean ‘as we are used to seeing it’, it may not be syntactically correct!).  The same is true for IE8, it’s just IE9 that displays the page differently if in Standards mode (which it will be for all pages other than the homepage.

So, how do we fix it?  I basically insert a directive into the PeopleSoft HTML template for all non-homepage pages telling IE to act like an earlier version.  It’s not the most elegant solution but it seems to do the trick, at least until something official comes along.

Open PT_HNAV_TEMPLATE and look at the 4th line.  It should look like this:

<meta http-equiv="X-UA-Compatible" content="IE=8">

Comment this line out and add a line below, thus:

<!--<meta http-equiv="X-UA-Compatible" content="IE=8">-->
<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7">

You shouldn’t even need a Web or App Server reboot.  The new template forces IE9 to behave like IE7 and displays your PeopleSoft pages correctly.

This is all very good when the field is in a nice empty page, where there’s plenty of space for a large toolbar.  Many pages have a lot of fields on, and the addition of a bulky toobar might make the page appear busier and more crowded.  Also, some users may get confused with the wide choice of buttons available.

I faced a similar issue today.  I needed to have the user enter some text and be able to embed links, but because of the design aesthetics of where the results would be output, I wanted to discourage the user from having lots of different colours, font sizes etc. So I wanted to reduce the toolbar so it had just two buttons – add link and remove link.

It turns out that there’s a pretty simple way of customising the toolbar. 

Against the Page Field properties of the Long Edit box there is an Options tab (you probably used it to make the field Rich Text).  The first drop-down allows you to select alternate configurations (they’re all HTML Objects).  There isn’t a delivered one that did what I wanted, so I took an existing one and modified it.

I opened an existing one (‘PT_RTE_CFG_PTPPB’) and took a look at the contents:

<!%
FCKEditor configuration file for Pagelet Wizard HTML Data Source
-->
CKEDITOR.config.skin='office2003';
CKEDITOR.config.toolbar =
[
['Source','-','Maximize','Preview','Print','-','Cut','Copy','Paste','-','Undo','Redo','-','Find','Replace','-','HorizontalRule','Table','imageUPLOAD','Link','Unlink','SpecialChar'],
['Format','Font','FontSize','-','Bold','Italic','Underline','Strike'],
['JustifyLeft','JustifyCenter','JustifyRight','JustifyBlock','-','NumberedList','BulletedList','Outdent','Indent','-','TextColor','BGColor']
];

It’s pretty clear to see that each toolbar button is represented by an entry in the CKEDITOR.config.toolbar section. I cloned the delivered one and reduced the toolbar section down to:
CKEDITOR.config.toolbar =
[
['Link','Unlink']
];

This had the desired effect of reducing the toolbar to exactly what I needed, but it had introduced an unwanted bottom section which shows the HTML tags for the edit box.

There was nothing in the config file that I’d specified that had introduced this, so where had it come from?

It turns out that when you specify a config file, it overwrites the default values.  After a good deal of searching I located them in:

<ps_home>\webserv\<domain>\applications\peoplesoft\PORTAL.war\<site>\ckeditor\config.js

Not only does it specify the defaults for the toolbar, but it also contains the lines:

config.resize_enabled = false;
config.removePlugins = ‘elementspath’;

Once I’d added these two lines to my config HTML object my rich text box displayed exactly as required – a much simpler and more compact edit box containing just the toolbar buttons that I want:

Pleasingly, it’s now actually slightly easier to achieve (and will appear on all pages, not just the Home Page).

Open up App Package PT_BRANDING, the Class BrandingBase and search for the string ‘add &addjs’.  Immediately preceding that line, add the following line of code:

&greeting = "User: " | %UserId | " on Database: " | %DbName;

(Plus some comments identifying the customisation etc.)

This will do the trick, but the end result looks a bit big and blocky.  It’s a piece of cake to alter the greeting style to achieve a much better looking result.

Open the PSHOMEPAGE Freeform Style Sheet, locate the greeting style class and replace it with this:

.greeting {
color: #FFFFFF;
font-family: Arial, Helvetica, sans-serif;
font-size: 10pt;
margin: 0 0 0 70px;
line-height: 24pt;
}

The end result will look something like this (I’ve also added bold tags around the UserID and Database for clarity):

Now I’m all for being warned if I’m doing something unsupported and I know Windows 7 isn’t supported yet, but probably will be in the near future.  I’m not going to swap my client OS just to keep the PIA happy, but I don’t want to be warned every single time.  Also, it’s not a very well formatted error message as it throws out the alignment of the logon screen and it just looks a little messy.

I wasn’t going to do anything about my niggly annoyance until someone else wondered how to remove it then it piqued my curiosity.

As far as I could see there are two ways to fix this, find a way of adding Windows 7 to the supported OSes, or hide the warning message.

I tried many variations of OS codes in the browser.xml file as that appears to be where the supported OSes are read from (the sharper eyed among you may have noticed that I’ve added Windows 7 to the list in the above screenshot).  This had no effect however, so I admitted defeat in trying to fix the cause and resigned myself to just trying to hide the symptom.

The HTML behind the signon page is ‘signin.html’ within ‘<PIA_HOME>\webserv\<domain>\applications\<site>\PORTAL.war\WEB-INF\psftdocs\<node>’.  We can’t just comment out the error sections as we only want to hide this specific error message, other errors like ‘invalid password’ we still want to see.

The first step is to hide the browser error message.  Search for ‘id=”browsercheck_error”‘ and you’ll see this section.  Comment out as shown.

<div style="text-align:center">
<h1 id="error_img" style="display:none"><a id ="error_link" href="javascript:setFocus();" tabindex="1"><img src="<%=psCtxPath%><%=psHome%>/images/PT_LOGIN_ERROR.gif" alt="<%=130%>" border="0"/></a></h1>
<h2 id="login_error"> <%=error%> </h2>
<h2 id="discovery_error"> <%=ps.discovery.error%> </h2>
<!--<h2 id="browsercheck_error" style="text-align:left"> <%=browserCheck%> </h2>-->
</div>

This prevents the text from showing, however we also want to prevent the warning image being displayed for this warning also.

Search for ‘setErrorImg’ and you’ll see this function.  Comment as shown and add the line below.

function setErrorImg()
{
var login_error = document.getElementById('login_error').innerHTML;
var discovery_error = document.getElementById('discovery_error').innerHTML;
/*var browsercheck_error = document.getElementById('browsercheck_error').innerHTML;*/
var browsercheck_error = "";
login_error = login_error.replace(/^\s+/,"");       // delete leading spaces
discovery_error = discovery_error.replace(/^\s+/,"");
browsercheck_error = browsercheck_error.replace(/^\s+/,"");
if (login_error.length != 0 || discovery_error.length != 0 || browsercheck_error.length != 0)
{
document.getElementById('error_img').style.display = 'block';
document.getElementById('error_link').focus();
}
else
setFocus();
}

Bounce your PIA and now the message won’t be displayed when you use Windows 7, however other error messages will still appear as desired.

Note: Updated 27th Jan after Jim Marion’s suggestion below on my incorrect commenting syntax.

Previously, if you had a rough idea of how it all fits together and knew the colour scheme that you were moving to you could do it in a day or two.  Now however, I think it’ll take a bit longer.  Here’s why:

The routine used to be:

• Clone the delviered style sheets
• Locate the HTML code for the colour you wish to change
• Locate the HTML code for the colour you wish it to become
• Convert both into the database equivalents (using Hex functions in Excel is normally easiest)
• Update the database, replacing all instances of the old colour with the new colour where the style class is within your new style sheets
• Repeat until all colours have been swapped
• Then, go through each image and make the colour consistent

Since I did this last there’s a plugin for Firefox called FireBug that makes the whole process of identifying which Style Class is responsible for the colour of an on-screen element, so the process should be much quicker (no more than a day or two).

With Tools 8.50 came the advent of FreeForm Style sheets.  While these might be quicker to write and more flexible for entering complex CSS (and I’m sure the Tools 8.50 UI couldn’t have been delivered without them) it makes it a lot harder to track down where an element is inheritting its style from.

Freeform style sheets are the equivalent of a straight text CSS file, but they are stored in HEX in PSCONTENT.  This means that you can’t search them easily or do a find and replace on a colour code using SQL very easily, so for every colour that you need to change within a FreeForm style class you have to manually find it and change it.

The job I’ve just finished required me to change 14 different style sheets, 6 of which were FreeForm.

You also have to bear in mind that if you’re rebranding portal, whenever content is drawn from another application (in this case HR), you have to apply the style changes to that database also.

Yes, this is Tools 8.50!

These are the changes you need to make:

Main Menu->PeopleTools->Utilities->Administration->PeopleTools Options:
Style Sheet Name: PSSTYLEDEF_SWAN

Main Menu->PeopleTools->Portal->General Settings:
Navigation Type: Drop-Down

PeopleTools->Portal->Portal Utilities->System Options:
Style Sheet Name: PTSTYLEDEF_SWAN

That’s better!

Thanks to Bauke Gehem for commenting on Nicolas Gasparotto’s blog with the above advice.

When you install a fresh 9.1 environment this is set by default.

First up is the new menu system:

It takes a couple of goes to get used to it, as you need to click the items in the top menu to get the menu to drop down, but you only need to hover over the menu items in the drop down menu to get them to unfold.  If you click on a folder in the drop down menu then it loads the navigation collection for that folder.  It’s pretty intuitive when you think about it, it just seemed inconsistent to begin with.

Once you’ve navigated into a component then you don’t need to go back to the root menu to find the next page, you can pick up the navigation from any step on the way by clicking the appropriate item in the breadcrumbs:

Also new are modal prompts (partial page refresh instead of reloading the entire page):

and also Hover Panels (probably not their real name):

I also liked the autocomplete on prompt fields:

and the automatic results display for portal registry search: