December 2007 Archives

You're no doubt aware that you can go into Administration: Select Utility: Search Service Manager, then click on "Status" to see the status of your Search Server:

You probably also know in 6.1 (if you remember to import the searchserver.pte) that there's also a Search Cluster Manager in Administration.

This tip is about checking out the search status the hard way: by connecting directly to the search server port and asking for it. Its usefulness is relatively limited, as the results from the status check can be found in either the admin UI or using one of the command-line tools like examinearchive, but it could be useful knowledge for some monitoring applications and security awareness.

Basically, you can telnet to the Search Server port (you have locked down direct Search Server access to your DMZ, right?):

telnet localhost 15250

... and when a connection is established, type:

STATUS

... followed by the "enter" key:

Copy and clean up the text, and you've got all the info you never needed to know:

Virtually all text strings in the portal have been extracted to XML files, mostly for internationalization. Check out %PORTAL_HOME%\ptportal\6.1\i18n\en\ for these files. Why should you care? Here are a couple reasons:

1. I had a customer who didn't like calling Communities Communities. They wanted to call them "Spaces" or something like that. By simply doing a search and replace in these files, they were able to do that.
2. Customizing the text that shows up on the login form is also a big feature (explaining to users which Auth Source to pick, for example); simply find the text in ptmsgs_portalbrowsingmsgs.xml, and replace it with whatever you want.
3. New files can be created here that allow you to create your own string files for use in your own code. That way, text can be easily changed later as needs evolve.
4. If you know the index of the string you want to use, you can use Adaptive Tags to get the portal to transform it for you, including internationalization support. For example, suppose you're writing a login portlet; take this section of ptmsgs_portalbrowsingmsgs.xml:

   

   ... and instead of putting the text "Create An Account" in your HTML, you could use:

   <pt:logic.value pt:value="$#1.ptmsgs_portalbrowsingmsgs"/>

   Then, this Logic Tag will automatically transform the text in your portlet into the appropriate language for the string with an ID of 1 ("Create An Account").

Automatically checking links in the portal is hard. The problem is, the same page could have multiple URLs that resolve to the same item. Here, both of the following links open a community with an ID of 200:

• http://server/portal/server.pt?open=512&objID=200&PageID=0&cached=true&mode=2&userID=226
• http://server/portal/server.pt?in_hi_userid=226&spaceID=8&space=CommunityPage& parentid=&control=SetCommunity&PageID=0&CommunityID=200&parentname=

This makes automated crawling a pain, even for Google to some extent.

Today's Cool Tool won't really overcome this issue (in fact, nothing short of a "portal-aware" link scanner would, or "Friendly URLs" - hint, hint). But it's free, and it does a decent job generating useful reports in complex portal environments:

Download it here!

You can do lots of interesting things with Javascript and style sheets. Take printing: there is not only a Javascript event that you could use to get the browser to print a page:

<a href="#" onClick="window.print(); return false;">Print</a>

... you can also use style sheets to dynamically hide or show sections of the page:

<link type="text/css" href="print.css" rel="stylesheet"
     lang="en" media="print" />

We've talked about CSS before, but this little trick lets you show or hide any items in the DOM only when the page is printed.

For example, at pbrn.ahrq.gov, we had a requirement to allow printing, but the text always seemed to get lost off the right side of the page. The solution was to eliminate the left-hand navigation to save page real estate (who needs that when viewing a printout anyway?), and shrink the top header to the bare essentials. All this was accomplished with some simple JS and CSS, and as you can see, the same page can looks quite different when printing:

SSL is great for protecting HTTP traffic, particularly if your portal is open to the Internet. But in some circumstances, it can cause issues with file downloads. If you get a blank page when you try to download a file (particularly using Collaboration Server), or an error that says something like:

The path or file name for C:\Documents and Settings\user\Local Settings\Temporary Internet Files\Content.IE5\CBEFMK\file[1].ppt is invalid. Please check that the path and file name are correct.

... Chances are this is caused by an Internet Explorer option in Tools: Internet Options: Advanced called "Do not save encrypted files to disk":

Because the portal is returning encrypted files over SSL, the browser is not saving them to a temporary location so they can be opened locally. Uncheck that box and you should be good to go!

There is a major change that you need to make to the configuration of Publisher before deploying it into production and it is a change that is overlooked in a lot of ALUI deployments. When you install Publisher, it is not set up to use as much memory as a production instance of Publisher should use. Making this change is easy though, as the recommended configuration settings are actually in the config files, but are commented out. In order to make the change, open up the service.conf file in the ptcs/6.x/settings/config directory and find the following section:





Comment out the lines preceding this section dealing with java parameters and memory usage and then uncomment this section. Restart your publisher service and you are set for production! Check your publisher diagnostic page to make sure that the memory settings took...