Archive for the ‘Knowledge Directory’ Category

Server-Side Validation – Deleting Knowledge Directory Cards

Monday, April 29th, 2013

Those of you that are familiar with the WebCenter Interaction Knowledge Directory have likely had a need to delete a batch of cards from a folder. But, if you have a lot of cards and try to delete more than 50 at a time, you’re presented with this little gem:

That’s a Javascript popup that refuses to allow you to delete more than 50 cards at a time – but what if you have 25,000 cards that you need to delete? This scenario presented itself to me recently, and I was definitely not looking forward to the prospect of deleting them 50 at a time – 500 separate deletions, which is more complicated by the fact that the Knowledge Directory shows only 20 cards at a time, so for each deletion you have to change the pagination as well.

Importantly, there is a difference between “client-side validation” and “server-side validation” – doing a check in Javascript to prevent users from doing something is completely different than doing a check on the server side for the same reason. Fortunately for me the original developers neglected to do a server-side check that would prevent the deletion of more than 50 cards. So, using the IE Developer Tools (hitting F12), I was able to add a breakpoint at this Javascript condition, and simply use the “Set next statement” option to get this method to return true:

That way, I could get the browser to submit deletion requests for 1,000 or more objects at a time.

Use this as a reminder as you develop your custom code: always confirm data entry both on the client and server sides if you don’t want users doing things they shouldn’t!

FREE Knowledge Directory Portlet in WebCenter 10gR4

Friday, April 27th, 2012

The Knowledge Directory has always been an instrumental part of the Plumtree / ALUI / WebCenter stack, and several vendors – Integryst included – have made strides in enhancing its functionality over the years by providing a more Windows Explorer-like interface. Adaptive Layouts were nice for getting part of the way there, but until now, Oracle never had an AJAX-type solution.

With Neo, that all changes. The new Knowledge Directory portlet – part of the new Neo Portlet bundle – is a decent portlet that provides most of the expected functionality:

It even has a pretty solid configuration screen (for both admin and personal settings) to choose a base folder, properties that you’d like to have presented, and some formatting options:

You’ll find a special offer after the break if you’re so inclined…

WebCenter Document Hit Counts

Tuesday, November 22nd, 2011

Wondering how popular your Plumtree Knowledge Directory documents are? Sure, you could use WebCenter Analytics, but did you know that Plumtree has always captured card download metrics?

Try this query to get hit counts for each card in the KD, and marvel in the awesomeness that is your popular documents – regardless of how many times your Analytics collector dies:

WHERE     (LASTHIT > GETDATE() - 30) AND (HITCOUNT > 0) and (ptcs.cardid = ptc.objectid)

Interesting side note – notice how all those document hit counts are a multiple of 10? The reason for this is a scalability approach that Plumtree came up with years ago. The idea is that rather than writing to the database every single time a document is downloaded, the code only increases the hit count 10% of the time, but increases the count by 10 each time. So, statistically, the counts are accurate over time, but the database is written to much less frequently.

There’s a WCI App For That 9: OpenerFilter (aka Office 2010 MIME Types)

Thursday, November 3rd, 2011

By now you’re probably tired of the Knowledge Directory saga related to opening KD documents in WebCenter Interaction, but it’s a pretty serious problem. I’ve posted several solutions, but have come across a new problem with the original OpenerFilter configuration. Specifically, for some IE and Office configurations, Office 2007 and Office 2010 documents don’t open properly because the original configuration file used non-specific MIME types.

You can view the original post for the source code and a description of how this filter works, but recently I’ve discovered that the MIME types in the original post should be updated for recent Office documents (.docx and .xlsx). Instead of “application/msword”, the config file should use the MIME types provided by Microsoft. Specifically, the configuration file for OpenerFilter should look more like the following:

<?xml version="1.0"?>
  <removeContentDisposition value="0" />
  <replaceContentDispositionWithInline value="1" />
  <fixContentType value="1" />

  <doc value="application/msword" />
  <dot value="application/msword" />
  <dotx value="application/vnd.openxmlformats-officedocument.wordprocessingml.document" />
  <docx value="application/vnd.openxmlformats-officedocument.wordprocessingml.document" />
  <xlt value="application/" />
  <xls value="application/" />
  <xlst value="application/vnd.openxmlformats-officedocument.spreadsheetml.sheet" />
  <xlsx value="application/vnd.openxmlformats-officedocument.spreadsheetml.sheet" />

  <pdf value="application/pdf" />
  <gif value="application/octet-stream" />
  <jpg value="application/octet-stream" />
  <png value="application/octet-stream" />


Bug Blog 13: Fix Broken File Downloads in 10gR3 (Part Quatre)

Tuesday, October 25th, 2011

When WebCenter Interaction 10gR3 was released, it was a complete train wreck for documents in the Knowledge Directory – the content headers were wrong, docs wouldn’t download in Internet Explorer due to the comical back-asswards Javascript file open mechanism, and links couldn’t be copied or viewed because the anchor tags were malformed.

In our last post in this painful series, I shared some code that will resolve the ALUI / WCI Knowledge Directory links so that users can right-click and copy the links, and the files open as expected when clicked.

Since then, I’ve found that when an admin is in EDIT mode in the Knowledge Directory, the link calamity continues, and a completely different and incomprehensible linking mechanism is used. So for your reading pleasure today, I’ll update that post to handle edit mode as well as browse mode. Again, just add the following HTML to the footer used in your Knowledge Directory (depending on Experience Definition, there may be more than one):

Microsoft Office 2010 (.docx) files are .zip files

Wednesday, March 16th, 2011

Sit back and let me rap atchya, slinging some factasms about the Office 2010 document format (.docx, .xlsx, .pptx).

You’ve no doubt been using Office 2010 for a while and saving files with those new formats that don’t work in Office 2007.  Those .docx, .xlsx, and .pptx files are part of the Office Open XML file format.  What you may not know is that they’re actually ZIP files.  Really – try taking any .docx file you’ve got and adding .zip to the end – it’s a .zip file:

Who knew, huh?  More importantly, what’s this post doing on a Plumtree bog?

If you’re planning on using WebEdit with WCI Collaboration and Office 2010, it’s a very important nuance, because yesterday’s Collaboration WebEdit Hack isn’t going to be practical without this nugget of knowledge.

Bug Blog 6: Fix Broken File Downloads in 10gR3 (Part Trois)

Sunday, June 20th, 2010

*sigh*.  You’ve upgraded from ALUI to WCI 10gR3, and your Knowledge Directory links got all screwed up, didn’t they?  HTML files now throw an open/save dialog, some documents don’t open, you can’t copy links by just right-clicking them and choosing “Copy Shortcut”, and IE throws a popup blocker when you click a link in the Knowledge Directory, doesn’t it? 

You got the “To help protect your security, Internet Explorer blocked this site from downloading files to your computer” blues, huh?

I’ve tried creating a Plumtree Filter, and that worked pretty well, but not quite enough.

I’ve tried tweaking the Portal’s Javascript files, and THAT worked pretty well, but again, not quite well enough.

So, today, my friend’s, third time’s a charm:  rather than trying to fix this on the server side, we’re going to knock out this issue once and for all on the client side.  Check out those previous blog entries for a more detailed description of the problem, but basically, it’s because the portal uses a crazy convoluted way of opening documents via javascript. 

What we’re going to do today is stick some javascript in the footer of the page.  This JavaScript is going to simply find all those back-asswards links and replace them with NORMAL <a href=xxx target=_new> links.  If you add it to the footer of your site (specifically, the footer used for the KD, but the code is smart enough not to do anything if it’s on all pages), it should be able to take care of the rest.  Just make sure you add it to the Presentation Template and not the Content Item, because you-know-who only knows what a mess the out-of-the-box rich text editor is with javascript and adaptive tags.

The code after the break should be self-explanatory, but as always, if you’ve got a question or comment, feel free to post it here.  Also note that this code only fixes the download links; it doesn’t kill that “Open/Save” dialog box for things like HTML files.  For that you’ll still need the Plumtree Filter. (more…)

Bug Blog 4: Fix Broken File Downloads in 10gR3 (Part Deux)

Monday, May 3rd, 2010

Last week I provided portal filter code to fix some elements of opening documents in WebCenter Interaction’s Knowledge Directory (and Search and Snapshot Queries).  This week is another follow-up on that theme, and I’ll provide another piece of code to continue cleaning up the mess that is the Knowledge Directory Downloading Clusterf*ck (in IE at least).

Ever gotten this little present after doing an upgrade to 10gR3, when trying to open a document in the Knowledge Directory using IE7 or IE8?


Ah, the old “To help protect your security, Internet Explorer blocked this site from downloading files to your computer.”  What’s even more ridiculous, if you “accept” the download, it STILL doesn’t work because IE tries to reload the page, and WCI is very stupid about how it opens this popup window (see how that address bar shows “about:blank”?).  It seems this only happens in IE, and only if you have adaptive layouts disabled with “open documents in new window” enabled, so it doesn’t affect everyone.  But I die a little on the inside every time I see that stupid thing: yes, my friends, I am an empty, hollow shell of a consultant.

Fortunately, I decided to seek redemption for WCI and myself by proxy, and checked out the HTML source for a typical file open link.  It’s kinda hilarious:

<a href="#" onclick="var currentWin = PTCommonOpener.openInNewWindow('', 'Opener_18_1322446', 800, 600, true); currentWin.location= 'http://server/portal/'; return false;">Doc Name</a>

Whhaaaaaaa…!?  Sure I know there are dozens of ways you can open a document in a popup window, and many have their advantages (for example, by using JavaScript you can control the size and layout of the window), but I’d be hard-pressed to come up with a worse way to open a document.  I’ve always hated the fact that you can’t just hover over the link to see the URL, and can’t right-click and copy the shortcut to mail to someone later. (Tip: use adaptive layouts and these problems go away!).  Or they could have at least just done a method in that onclick event.  OK, so they wanted to use a wrapper method – that’s fine – but the PTCommonOpener.openInNewWindow actually takes a URL paramater, so they could have just passed the URL into that function, rather than creating a new, EMPTY document and then trying to use Javascript to load the document into that window.  At very least they could have put the document URL in the “href” parameter so it’d work without JavaScript (and be 508-compliant) and users could copy the links with a simple right-click.

OK enough rambling.  On to a solution: (more…)

Bug Blog 3: Fix Broken File Downloads in 10gR3

Thursday, April 29th, 2010

Wow, was WebCenter Interaction 10gR3 a step backwards in opening documents, or what?  I’ve seen wide-spread problems opening docs in the Knowledge Directory, Search Results, and Snapshot Queries, and even written two posts on the topic already.

There are two main problems: poorly implemented document open handlers (which I’ll discuss in my next post), and that pesky Content-Disposition header that tries to force the browser to throw up an “Open/Save” dialog instead of just opening inline (which is definitely useful for HTML and Office files in particular, where users just want to view the documents in their browser without having to save ’em first).  A third but ancillary issue is that occasionally the portal gets the MIME type of the document wrong in the Content-Type header, which is typically using application/octet-stream and doesn’t give the browser any clue about what type of file it is.

In the past posts I’ve described using BigIP iRules to remove the Content-Disposition header, but I ran into another client issue recently where just killing this header isn’t enough.  Take the following response headers for a document transfer that is NOT using the iRule to kill the Content-Disposition header:

This PowerPoint file, when clicked on in the portal, will throw the open/save dialog, but what if we wanted it to give the browser the option to open in-line?  We’d get rid of that Content-Disposition header.  Here’s the problem:  if we do that, the portal is returning a Content-Type of application/octet-stream.  Which means, without the file extension in Content-Disposition, the browser has no idea what type of document this is, so it throws up a “FIND PROGRAM/Save” dialog box instead of an “OPEN/Save” dialog box.

The solution to this problem would be to drop the Content-Disposition header, but use the file extension to fix the Content-Type while we’re at it (to application/  But now our iRules are getting complicated, and not everyone has BigIP anyway.  Fortunately, my love/hate relationship with shifted much more to the former when i found this: How to Eliminate the ‘Save/Open with’ Prompt when Opening HTML Files [ID 971003.1].  Then, of course, it shifted back to the latter when I realized that I found this article by complete dumb luck navigating the terrible interface, and the article is nowhere to be found searching through Google. But that’s another story.

At any rate, a solution was clear: you can write a .NET or Java FILTER to manipulate headers before they’re returned to the browser!  As such, I took the code from that article and expanded on it with a .NET filter of my own, which will:

  1. Remove the Content-Disposition header selectively on different file types
  2. Change the Content-Disposition header to use “inline” instead of “attachment” instead of just deleting the header (this seems to work with some browsers; a brief discussion on the differences is here)
  3. Fix the Content-Type header if the file name extension doesn’t map the MIME type the portal thinks it is
  4. Do all this through a filter and a dynamically loadable varpack that allows different configurations based on the type of file being served.

So while it’s a bit optimized in the sense that it only looks at responses being gatewayed through the portal, it’s still kind of a hack because personally, I think this should be an option in the portal in the first place rather than adding the additional overhead of a filter.

But, nonetheless, it seems to work well, and you can download the code here and the varPack file here.

If you’d like assistance with actually building and deploying this, or porting to Java – drop me a line.

Replacing uploaded documents without breaking the URLs

Monday, March 1st, 2010

Ross Brodbeck has written some excellent posts on how the Document Repository works in the ALUI / Plumtree portal (which is still accurate in WebCenter Interaction 10gR3), so I won’t rehash those details here.

Instead, I’ll give you a quick tip to answer what should be a relatively simple question: How do I replace an existing document that has been uploaded to the WCI Knowledge Directory? At first glance, it’d seem you should just upload a new document and delete the old one. The problem is, especially if your site is large or exposed publicly on the Internet, someone may have linked to the original URL. This URL contains the Object ID of the card in there, so the new file – even if it has the same name – will have a different link. This is even true, for the most part, with Friendly URLs that were introduced in ALUI 6.5 and expanded in WCI 10gR3.

The bad news is that there is no way through the UI to change the file itself; the good news it’s an easy file swap that can be done on the server containing the Document Repository. Just open the properties page for the file, and look at the “Document Upload DocID” field (and the “Document Upload Repository Server”). Then, take your new document, rename it exactly as shown in the properties, and put replace the file in that directory. In the example below, this file would need to be called “D004783E.ACT” in the DR folder at “documents/ptupload/active/F0080AF6/”: