Warning: This is a pretty specific discussion of a pretty specific situation that occurs when you’re moving a bunch of stuff around in Publisher.  If you’re not interested in Publisher and it’s idiosyncrasies,  you should save your time and skip this post.

Anyhow, with the holiday season upon us and all, I figured I’d share the source code for a little Publisher utility I recently put together.  I’m working with a client who is in the process of a major Publisher update: they’re re-organizing their publisher content hierarchy to operate more efficiently.  This is all fine and dandy, except for the fact that many of their content items link to other content items.  As such, when they re-organize their content hierarchy, a bunch of embedded links are going to break :(  For example, consider the following:

The file:

$pub_root/foo/foo.html

contains a link to another content item that looks like:

http://pubcontentserver/bar/bar.html

So far so good, except that during the content migration, the foo and bar directories are getting rolled into one new folder named foobar. When this happens, we’ll end up with the following files:

$pub_root/foobar/foo.html

$pub_root/foobar/bar.html

Unfortunately, Publisher isn’t smart enough to fix embedded links for you when you move stuff around within the hierarchy.  The net result is that our link in foo.html is out of date and pointing to a file that doesn’t exist:

http://pubcontentserver/bar/bar.html

What we’d like to happen, though, is for our link to point to the new location of the file, i.e.:

http://pubcontentserver/foobar/bar.html

This particular client has a bunch of published content items (in the tens of thousands), which makes it pretty impractical to ask someone to manually go through every published content item and look for links that are going to break.  So I volunteered to write a script/program to go through and identify potential problem links automatically.  I have to admit I first volunteered because I thought this was going to be really easy to figure out via. a recursive grep:

From $PUB_CONTENT_ROOT on filesystem

find . | xargs grep -i ‘publishedcontent’

Just to make me mad though, while the grep approach works, it returns too many false positives.  It turns out that a lot of the out-of-the-box content items have links back to themselves, i.e something like:

in the file $PUB_CONTENT_ROOT/foo/foo.html

http://pubcontentserver/foo/foo.html#myTarget

And Publisher is smart enough to fix these self-referencing links when you move the items around, i.e. the link above gets updated to

in the file $PUB_CONTENT_ROOT/foobar/foo.html
http://pubcontentserver/foobar/foo.html#myTarget

What we really need is a piece of code that does the following:

1. Recurse down the published content tree and examine all the published content items
2. Check for links to other published content items in each file.  This can be done by looking for a specific token, which by default, is “publishedcontent”
3. At this point, we have a list of all the links to content items in the file.  However, we need to filter out the self-referencing links that will get auto-updated by Publisher.  To do this, let’s look at the path in the link, and ignore any references that point to the same directory.  For example:
   

   In the file $PUB_CONTENT_ROOT/foo/foo.html
   We’ll capture the link http://putcontentserver/bar/bar,html
   But we’ll ignore the link http://pubcontentserver/foo/mystuff.html because it will be auto-updated by Publisher.

4. Dump all matches found out to a file so the links can be reviewed and fixed.

So I wrote some code that does the above.  Go grab LinkChecker.java if you’re interested.  The code is pretty simple, but it does have a few caveats which are all listed in the comments.  You should be able to compile the code with a JDK 1.5+ compiler without any external dependencies:

javac com\function1\utility\LinkChecker.java

And then run it pretty easily too:

java -classpath . com.function1.utility.LinkChecker my/path/to/pubcontent_root/publish

Note that the code actually generates two output files: published_content_links.log and external_links.log.  published_content_links.log is the list of all the links and files that fall into the scenario outlined above.  external_links.log just lists all links in content items that are to non-published content items (i.e. links to external websites, and other portal links).

Eventually, somebody with a little motivation could evolve this code to the next logical iteration and add functionality to auto-check the links that are grabbed.  Would be pretty simple to do by adding something like:

URLConnection myLink = new URLConnection(currentLink);
int statusCode = myLink.getResponseCode();

But then you have to think about faking portal authentication and all that other good stuff that I’m not really up for tonight.  Anyhow, hope this little utility comes in handy for at least somebody out there on the internet….enjoy the early (admittedly pretty lame) Christmas present from your friends at Function1.

A common, yet cryptic message awaits Publisher users who find the Rich Text Editor mysteriously stops working. When editing a Publisher document, the Rich Text window displays a blank box and cannot be clicked on or changed. The corresponding Javascript error message is anything but useful:

Error: Access is denied

Code: 0

URL: http://[servername]/portal/server.pt/gateway/PTARGS_xxxxxx

So what’s going on? Long story short, there’s a bug in the PTControls.js Javascript implementation. The script tries to set the default source of Rich Text Editor iFrame to “index.html”, making the erroneous assumption that index.html will always exist. In some situations, the resulting 404 error causes Internet Explorer to freak out and report “Access Denied”. Note that there are a couple of solutions to this problem.

1) If you consult the Publisher Release notes, you’ll be told this is a bug in IE, and to turn off ”Show Friendly HTTP Error Messages”. Unfortunately, a) this isn’t an IE bug, it’s a problem with the  Portal Javascript, b) this “fix” doesn’t always work in all environment and c) it’s often unpractical to push an IE configuration change out to your entire user base. Anyhow, if you have a controlled environment, with a limited number of users, you might be able to mask this issue by disabling “Show Friendly HTTP Error Messages” in Internet Explorer.

2) Make sure the default iFrame “src” attribute points to something that doesn’t generate a 404. You can do this by either pointing to a well-know file that is sure to exist (i.e. something like http://myimageserver/dummy.html), or just setting the “src” attribute to a javascript value that won’t cause the browser to bomb. In either case, you’re going to have to update two lines of code in PTControls.js at:

$IMAGESERVER_HOME/common/private/js/jscontrols/LATEST/PTControls.js

Make a quick backup of this file, and then search for lines that look like:

var src = (PTBrowserInfo.IS_NETSCAPE_DOM) ? ” : ‘ src=”‘ + ((this.defaultPageURL) ? this.defaultPageURL : ‘index.html’) + ‘”‘;

You should find two instances of the above. Now change those lines to read:

var src = “src=’javascript:false;’”;

Save the Javascript file, hit the Publisher Editor to confirm things are working, and Bob’s your uncle! With the error fixed, the editor window will allow access to the iFrame and its contents. We can all get back to creating announcements in Papyrus Fuscia, Size 5 like my muse, Ski Utah! If only <blink> was still supported in MSIE.

Since the Portal’s inception during Plumtree days, a set of APIs were provided to programmatically interact with the underlying Portal objects.  The API’s name might have changed through the product’s evolution – Enterprise Development Kit 5.x (EDK) during Plumtree days, Interaction Development Kit (IDK) 6.x during the portal’s short lived years with BEA and it seems that Oracle will retain the IDK name as it just prefixed it with “Oracle WebCenter” and just changed the version numbering to 10.x Yet, the concept remains unchanged: a set of interfaces for Portal objects – portlets, documents, projects, folders, communities, security groups, etc.)

With that said, we compiled a high level example of how to programmatically import content items from an external CMS to UCM/Publisher. In a subsequent example we will address how to export content items from Publisher/UCM to HTML and then load these to a target CMS while leveraging its intrinsic API set.

//initially we want to establish a remote session to the portal where soapConnectionURL is web service end point
IRemoteSession remoteSession = RemoteSessionFactory.getExplicitLoginContext(
new URL(“http://YourPortalserver/ptapi/services/QueryInterfaceAPI”), yourUserName, yourPassword);
IContentFactory contentFactory = remoteSession.getContentFactory();

// get the required publisher object managers from IContentFactory
folderManager = contentFactory.getFolderManager();
contentItemManager = contentFactory.getContentItemManager();
propertyManager = contentFactory.getPropertyManager();
presentationTemplateManager = contentFactory.getPresentationTemplateManager();
dataEntryEntryTemplateManager = contentFactory.getDataEntryTemplateManager();

// create a text property to store HTML content
ITextBlockProperty textBlockProperty = propertyManager.createTextBlockProperty(“htmlTextProperty”, “htmlText”);
IFolder folder = folderManager.getFolderByPath(targetFolderPath”);

// create a presentation template that would use the html property
String templateText = “htmlTextProperty=<pcs:value expr=\”htmlTextProperty\”>unset</pcs:value>\n”;
IPresentationTemplate presentationTemplate = presentationTemplateManager.createPresentationTemplate(folder, “Presentation Template”, templateText);
presentationTemplate.store();

// create a data entry template and attach the newly created presentation template
IDataEntryTemplate dataEntryTemplate = dataEntryTemplateManager.createDataEntryTemplate(folder, “Data Entry Template”);
dataEntryTemplate.addProperty(textBlockProperty);
dataEntryTemplate.attachPresentationTemplate(presentationTemplate);
dataEntryTemplate.store();

//create a content item and set the rich/block text property with the HTML from the source CMS
IContentItem contentItem = contentItemManager.createContentItem(folder, “contentItemNameGoesHere”, dataEntryTemplate);
textBlockProperty.setTextBlockProperty(“Hello <strong><font color=\”#000000\”>World</font></strong>”);
contentItemManager.checkInItem(contentItem, “Initial checkin.”);

// publish the content item
contentItemManager.publishContentItem(contentItem);

The above code sample is a draft for how you can upload an HTML string from a separete CMS into Publisher as a content item, some of these method calls should be refactored outside the main method since, more likely, you’ll be looping through the source CMS content repository. Feel free to ping us if you have any questions.

Thanks.
 

Unfortunately, I just ran into a major problem with this feature in a dev upgrade: the servlet for streaming all this content back doesn’t do any transformations on any of the URLs.  This is bad, since if you’re doing an upgrade, you’ve likely got hundreds or thousands of Content Items with relative links or images in them.  For example, suppose you have an existing Content Item with an image in it (that has been published to the same folder in Publisher).  The reference for this image will likely be:

<img src="myimage.jpg">

This worked fine with the old redirector, as the image tag would be transformed:

http://server/portal/server.pt/gateway/PTARGS_0_1_493_234_684_43/http%3B/ptpublisher%3B7087/publishedcontent/publish/folder1/folder2/image.jpg

But with the new content streaming functionality, this link does NOT get transformed the way you’d expect; the portal sees the relative link as relative to the SERVLET, not relative to the existing Content Item.  So the browser sees a URL like this:

http://server/portal/server.pt/gateway/PTARGS_0_1_493_234_684_43/http%3B/ptpublisher%3B7087/ptcs/PublishedContentServlet/image.jpg

… which obviously isn’t right.

In fact, Oracle seems to be aware of this: in the content.properties file, they changed the LTCUseRelativeURLs setting to “false” (it was “true” in 6.4).  That way, for NEW Content Items, the URLs are all absolute, which prevents this problem from coming up.

I was going to revoke my recommendation to upgrade to 6.5 for now, but came across a really easy fix to get all the benefits of 6.5 without this glaring bug.  Hit the link for the workaround.

The solution:  turn off the servlet in the “Published Content” Web Service.  Oracle left the redirector in there, and while this means you won’t get the scalability benefits of the new servlet, at least it’ll buy you time to check on the hundreds of Content Items you’ve already got.

Just change the Portlet URL for the “Published Content” Web Service from “PublishedContentServlet/proxy” to “published_content_redirect.jsp”, and all of the existing items should work again:

Obviously, the locally saved snapshot can get out of date over time, but it’s nice to have when you need it in a pinch (having been on sites that don’t allow you to connect to their network).

If you want an Excel copy of the matrix, you can download it here.  Keep in mind it’s only current as of the end of August 2008, but for prior versions of the portal, the information should be pretty static. For the latest version, visit one.bea.com (while it lasts).

See the release notes for full details, but here’s a quick summary from the huge list of bug fixes and enhancements:

Adaptive Tag is broken in Rich Text Editor at switching WYSIWIG to HTML editor. (Issue #54748)
Only “Time”, “Page Name” & Community name” transformer tags display the value. (Issue #42867)

Rich Text Control does not support anchor tags ‘#’ in <a href=#</a> links. (Issue #55759)

These issues are reason enough to upgrade to 6.5!  No longer do you have to use Presentation Templates to leverage adaptive tags – the new Dojo WYSIWYG editor doesn’t delete your tags, and even shows them unformatted in the rich text editor that you know they’re there.  Sure, ideally it would be nice if these tags were actually parsed (so the rich text editor would show the actual opener link below), but I’m not complaining – this is a huge step forward.

Publisher content is accessed via a redirect.jsp page which AquaLogic Interaction does not cache. This can cause major performance problems. (Issue #48758)

In a clustered environment, published_content_noredirect.jsp fails to proxy the entirety of the published content page. (Issue #60272)

This is also an enormouse improvement!  Rather than issuing a redirect, the Publisher Redirector now streams the data from the Published Content server directly back to the Portal Server.  Why is this big?  Because now the portal is able to cache all this published content, resulting in dramatically lower loads to Publisher and dramatically increased performance for end users.

Also of note, this was actually an undocumented feature in 6.4, which was discovered by Fabien Sanglier.  In fact, he even fixed the bug about all content not coming back.  Ah, Fabien, always ahead of the times…

When you publish a document to the Knowledge Directory, it uses the description as the filename. (Issue #62669)

We’ve run into this one before – good to know that you no longer need to beg support for the critical fix!

Finally, the new Dojo Rich Text Editor includes a spell checker.  Hit the link for a screen shot of that wonderful piece of functionality in action.

Meh, who needs spell check anyway?  If I ever figure out what’s up with this thing, I’ll post the fix!

Go Oracle!

Update June 9, 2008: Sorry ladies and gents, I just spent the day trying to upgrade our dev environment here.  After downloading hundreds of megabytes worth of installer packages that wouldn’t even open in Winzip, I tried again and was able to open them.  Sadly, they (at least Publisher and Collab, and I assume the rest of them) still required license keys.  I suspect what happened is that whovever uploaded the real updated installers didn’t FTP them as binary files (which would corrupt the files), and they rolled back to the original versions today.  I’m sure it’s coming, but I was also a little disappointed in this false start…

Update June 10, 2008:  OK, my fault.  The link above makes it pretty clear that the delicensed products are on Oracle’s download site and not available through BEA’s download center.

Well, no more.  The wicked witch is dead.  The clouds have parted.  Angels are singing.  Oracle has released generic license keys to legitimately licensed customers.

Now, people, I’m not saying this gives everyone free reign to steal Oracle products or use them in ways they’re not licensed for.  I have no idea what Oracle’s new licensing scheme is – particularly around using instances in development and DR environments (a common sore point with license keys) – so be good with these things.  I understand Oracle focuses more on customer audits than oppressive licensing schemes, so make sure you stay legit – contact your sales person if you’ve got any questions!

Without further ado, you can download the generic ALI keys here. 

Use them responsibly – our customers always maintained compliance at Plumtree without the keys, and I’m sure you all will again (well, I guess they did: I was just a consultant – what do I know?).

I ran into this one a couple months ago with our friends at the American Diabetes Association. (Give early, give often :))

Seems that with the latest build of Publisher (6.4), if you Publish to the Knowledge Directory using a Content Item that has a Description field, that field is used when generating the Open Document URL. And it’s not even an “escaped” string, so even if the description isn’t too long (which it often is), some characters in the URL could still end up breaking the link if they’re not valid URL characters. It’s easy enough to tell if you’re affected by this – just check out the properties of the document in the Knowledge Directory and take a look at the “Open Document URL”. If it looks like this:

… you’re having the problem.

The good news is that this is a known issue (read: documented bug) in Publisher and it has been fixed. The bad news is that the fix won’t be generally available until the next version of Publisher is released. If this is a critical issue for you, though, you can request an untested, unsupported Critical Fix from ALUI Support – mention the critical fix for bug #62669. You’ll need to demonstrate that you actually are affected by this issue, as the patch hasn’t gone through full regression testing, but I can tell you, it’s been working great for ADA for the past 2 months!

One of the cooler things you can do is leverage adaptive tags in this field. So, say you want a portlet that allows you to highlight various communities in your portal, and you want content managers to be able to just select a community from a list rather than looking up and typing in an ID. This is just one example; obviously you could select any object with the tree control, so use your imagination if you’d like to select users, portlets, or any other administrative object.

You can use the Unified Tree View adaptive tag in the “Instructions” field for a particular property, then use the Common Opener adaptive tag in your presentation template to automatically link to the community. Content Managers then don’t have to worry about all the nuances of creating links to other communities, and don’t have to remember community IDs when creating the Content Items.

For example, create a new portlet based off the “News” Portlet Template, and make some minor tweaks:

1. Add a new Integer property called comm_id to the “News Article” Data Entry Template:
   

2. Open the property and go to the “HTML” view for the instructions:
   

   The instructions contain the tree view adaptive tag and a call-back function that changes the text of the property based off the item selected:

   <script language=”JavaScript”>
   function PickerSubmit(arrIn) {
   document.getElementsByName(‘ptext4′)[0].value = arrIn[0].ObjectID;
   }
   </script>

   <pt:standard.tree xmlns:pt=’http://www.plumtree.com/xmlschemas/ptui/’ value=”Pick a Community” class=”gContentSection” pt:windowName=’myWindow’ pt:windowFeatures=’location=no,menubar=no,height=500,width=300′ pt:RootID=’1′ pt:Multi=’false’ pt:SelectMd=’2′ pt:SubmitMd=’2′ pt:Submit=’PickerSubmit’ pt:Title=’Community’ pt:SubTitle=’Pick a Community’ pt:Class=’512′/>

3. Finally, this property can be used in the “News Article” presentation template just like you would any other pcs:value; you can even include it inside a commonopener adaptive tag to automatically create a link to that community.

Now, when people go to create/edit the Content Item based off this DET, they’ll see a button underneath the property field where they would normally see “instructions”. Clicking it opens a popup to get the list of communities, and selecting a community populates the field!