Labels

accessibility (2) ADF (1) archiver (3) cmu (1) contributor (13) cookie (1) DAM (3) date (3) download (3) dynamic list (4) ephox (5) fatwire (1) fck (1) filters (1) folders (4) headers (2) IBR (3) ImageAlchemy (3) java (4) javascript (2) layout/template (4) link (6) locale (2) multilingual (1) rendition (3) replicator (4) rules (1) schema (1) search (11) sites (1) sitestudio (24) ssp/sspu (5) SSUrlFieldName (2) stellent (4) timezone (1) urm (1) weblogic (1) workflow (2)

Friday, 5 September 2008

Surprise! ssWeblayoutUrl

I put a bit of inline javascript in a content item to do an image rollover. After it published though the script was mangled - my mixed use of single and double quotes were all replaced with double quotes.

My code looked fine in Ephox. I tried a few edit+saves and realised my mixed use of quotes was sometimes failing. I complained to the Ephox folks who quickly checked & assured me it was not their product causing the issue. So I went to Content Server and viewed the content item's XML. Sure enough I found the problem - my image references were rewritten as a new Idoc URL format that inserts its own single quotes.

Observe my original code...
<img src="/serverroot/somepath/contentID1.gif" onmouseover="this.src='/serverroot/somepath/contentID2.gif';" onmouseout="this.src='/serverroot/somepath/contentID1.gif';" />

Now see what XML (unencoded) is stored in my content item...
<img src="[!--$ssWeblayoutUrl('somepath/contentID1.gif')--]" onmouseover="this.src='[!--$ssWeblayoutUrl('somepath/contentID2.gif')--]';" onmouseout="this.src='[!--$ssWeblayoutUrl('somepath/contentID1.gif')--]';" />

Hey wow! My URLs are magically replaced with some new Idoc link format... that screws up my quote groups! Gee, thanks guys.

Anyway I got around the problem by making my javascript first use an empty string and then appending the URL. Here's how it gets stored now..
<img src="[!--$ssWeblayoutUrl('somepath/contentID1.gif')--]" onmouseover="this.src=''+'/serverroot/somepath/contentID2.gif';" onmouseout="this.src=''+'/serverroot/somepath/contentID1.gif';" />

UPDATE:
I was fumbling around metalink when I discovered this gem: ssWeblayoutUrl can be configured to only use dDocName - no path required! Yay! Now we can fiddle with our image security without fear of broken links (except in javascript, of course :)) just put this in your config:

SSWeblayoutUrlUsesDocNames=true

Refer to metalink article 579457.1

UPDATE #2:
I'm playing with the new format, here are my findings...
* apparently it is only used on img tags - not links. Bummer...
* it will redirect to the latest available revision - contributor mode links to revisions in workflow, non-contributor mode gives you the latest released instead. Nice!

here's how it looks:
<img src="[!--$ssWeblayoutUrl('contentID')--]" />

UPDATE #3:
The bad news is that if the contentID is invalid or does not exist, it throws an error... more importantly, the editor will fail to load any content at all! Youch!

The good news is that the latest release of sitestudio(build298) is supposed to resolve the bug and also uses the new URL format on link tags.

UPDATE #4:
Finally got authority to upgrade and yes, ssWebLayoutUrl is a total kickarse auto-replacement for image src URLs but no, it doesn't seem to replace other weblayout links automatically. Maybe I should update my validation script to do it...

Wednesday, 30 July 2008

No new LinkWizard, just recommendations

Good new and bad news, folks.

The bad news is my employer refused to let me write a LinkWizard replacement. The good news is that I sent Oracle a reasonably comprehensive report about link management - what the problems are and what the solutions might be.

Naturally my first recommendation was to replace the LinkWizard. A new version should take any URL entered by the user and convert it into a SiteStudio link. This kind of pre-processing would eliminate common mistakes, like entering a SSPU-published URL. I even supplied a new interface that does away with the "wizard" style of annoying steps and offers an intuitive "properties" style interface. I also recommended they junk AJAX and just use a simple (fast) IDOC/JavaScript combination.

I then suggested that ssLINK tokens should be enhanced to include the file format of the target. This would allow a contributor to link to a content item and choose the web page version, PDF version or the native file version, without having to be trained in copying URLs from the Content Information page.

Next I proposed a "friendly" URL solution where horrible Content Server URLs like /content/groups/public/documents/doc/contentID.pdf could be replaced with intelligent URLs like /about/link-management.pdf. Wouldn't you love that!

I had a couple more suggestions including upgrades to the LinkManager component. I have no idea what will come of the report but here's hoping that they will do something about links.

Sunday, 8 June 2008

Useful SSPU logging

Well I haven't started rewriting the hyperlink wizard, my apologies. I've been wrestling with SSPU which has failed to publish our site repeatedly over the last two weeks. In an effort to work out what the hell was going on we turned on all the logging, right up to "debug for all". It was too much to be helpful... so after reviewing the logs I was able to come up with some meaningful logging levels.

PRIMARY LOG (FILE)
default: ERROR
syndicator: INFO
date-time: CRITICAL
analyser: CRITICAL
replicator: INFO
packagemanager: INFO
ice.cache: VERBOSE
delivery: INFO
delivery.ice: VERBOSE

SECONDARY LOG (DATABASE)
default: ERROR

Ok let's start with the database log. I know it sounds counter-intuitive but database logging slows down the software tremendously - it needs to read the entire database to display the SSPU status page (so make sure you purge often!) When you're viewing the SSPU website the only thing you care about is errors. Ignore everything else.

The primary log file is what you turn to when there is a problem. Set Syndicator to INFO to report the overall status of SSPU. It also includes info about database purges. Set Analyzer to CRITICAL to ignore messages about malformed links (they won't affect the publish anyway.) Set Replicator to INFO - this reports which files are actually being processed. It also includes final summaries and error counts. Set Delivery to INFO to report when a job is pushed to the subscription client/FTP (subagent). Set Delivery.ice to VERBOSE in order to report the status of the subagent's delivery and see an actual confirmation message that the publish succeeded. Finally there is a meaningless bug in the interface so I set date-time to CRITICAL so it won't get reported.

There are two additional settings you might consider. Set Packagemanager to INFO in order to see exactly which files have been selected (or skipped) for update. Set Ice.cache to VERBOSE in case there are some undelivered files floating around - it reports what items are waiting to be delivered.

One final important tip - Delivery.ice may report warnings about ice 501 errors. These can safely be ignored. They simply mean that SSPU was asking for confirmation that the job was finished but the subscription client (subagent) was too busy processing the job to respond. SSPU will keep resending the job until it receives a 200 confirmation - but subagent will only process the first push and ignore the rest. Once subagent finishes it sends confirmation, SSPU stops pushing and subagent discards all the repeated pushes. This is the intended behaviour.

Oh and the problem with our publish? Too many broken links!

Tuesday, 3 June 2008

The achilles heel of Oracle UCM - hyperlinks

UCM is a great document management system but its websites are sure awkward. The most obvious blunder was the editor so thank god that's been fixed! This leaves us with the biggest weakness in the system - hyperlinks.

Let's look at exhibit A - the Hyperlink Wizard. The new UCM spots a brand new fully AJAX interface for creating links. There's an amazing amount of code and effort put into it - just to make it work exactly like the old one! Fair dinkim guys, it took a pHD* to understand the old one so why replicate its horrible functionality? Did you expect your users to be so fully engrossed in the old way that they would be incapable of doing it any more simply? Why did you waste your time reinventing the wheel when it is just as square as the old one? I wonder if they have ever tried to create a link...

The first thing it does is ask "do you want to link to a section, file or URL?" What? Why do I have to choose? What's the difference? I want to link to another web page... who knows? Click on file. "Do you want the current item, existing file from server, upload a file, new file, or new word doc?" Hmmm, I'm editing this link so I don't want the current item (duh). Why would I create a word doc? I'm trying to make a link to a web page! I guess I'll have to choose existing, good thing I already know the content id. Once the initial search results finally load, i have to search again using my content id. Ok, I have selected my content item. Now it asks "use default web section metadata, choose a section or just link to URL?" Do i care? What does a section mean anyway? I think i want a URL but I know my page is already used in website x, so I'll drill down into that website until i find a "section" that sounds like my page. Click click click click click. Click next and it displays some ugly code and calls it my "link URL" (i thought i chose a section!) asking to me confirm. Hmm that looks nothing like the link i expected to see. Click finish and hope for the best.

Wow, what a pointlessly verbose experience (and i even removed a step!) Steve Krug says, "DON'T MAKE ME THINK!" so my contributors skip all that by simply pasting the published URL into the first "URL" field. The system however does not recognise published URLs, decides there are no links to that page, and deletes it from the published site. D'oh!

And take a look at the URLs it publishes. Every one ends in some seemingly random number! Why? Because the system must give every page a unique id. C'mon guys, most free CMS software generates human-sounding URLs even before Web2.0 happened. Is it really that hard?

And so ends another rant. Hopefully my next post will be about a replacement Hyperlink Wizard that I have written for you to download and enjoy.

* I work at a uni, my contributors are academics and they screw up the links all the time.

Tuesday, 27 May 2008

Unlocking the power of Ephox

The geniuses at Oracle have added Ephox as the new Contribution editor - but crippled it to make it look like their old editor. Newsflash to Oracle - the old editor sucked, why are you making the new one pretend to work the same as the old one?

Ephox comes with a WordCount feature, Find/replace, forms editing and even multimedia support. It has a menubar and can be configured for multiple toolbars. Why did Oracle remove these features?

Anyway, to turn that stuff back on you just need to edit the XML config file. Naturally the Oracle guys thought that was too simple so they generate the XML "on the fly" from a Javascript file. To edit the config for the wysiwyg element, hack this file:
/weblayout/resources/wcm/sitestudio/elements/wysiwyg/wysiwyg.config.js

The XML syntax you need can be found in the Developer guide at the Ephox website.
http://www.ephox.com/developers/editliveforjava/v60/DeveloperHTML/index.html

Overall I'm pretty happy with the Ephox editor. My big gripe is that it uses a Java applet - Ephox seem to have abandoned any non-Java versions. Applets are horrible on websites - all your contributors will need Java on their machines. I've seem some weird repainting from the applet and it can be unstable, it's slow to load, who knows which Java version to trust. I mean, I'm on a webpage, I'm editing a webpage, it's rendering a webpage - why force it through Java? Hmmm I appear to be ranting, let me start again...

Overall I'm pretty happy with the Ephox editor. Apart from relying on a silly applet :) the code it produces is clean and well structured. Ephox have some nifty features like Accessibility reports, thesaurus and WordCount. I've upgraded to SiteStudio260 and the Ephox java is quite stable. The only hiccup I've had was that it couldn't tell the difference between a print and a screen stylesheet. I put a few support requests through to the Ephox people and they responded promptly and helpfully. If you're considering an upgrade, go for it.