Posts Tagged ‘debug’

Use FireFox 3D view to diagnose CSS issues

Sunday, January 5th, 2014

It’s been a while since our last post as I’ve been busy with my other blog,, but this little gem was too neat to pass up (thanks Aseem for the tip!).

When diagnosing complex CSS or HTML issues with multiple layers, there’s a nifty little 3D view built into FireFox that allows you to rotate around all the various layers, inspecting the elements that may be causing you problems.

Simply hit F12 to bring up the debugger pane (which, incidentally also opens the dev tools in IE and Chrome as well), then click the “3D View” button:

Viewing Experience Definition Debug Page

Saturday, November 12th, 2011

Recently we discussed the Experience Definition Debug page. It’s pretty straight-forward: turn on debug mode in Portal Administration, then click the “Show Debug Messages” link that shows up in the WCI header.

But, what if you’ve customized the portal navigation and aren’t using the out-of-the-box header bar? We’ve gotchya covered – there are actually three ways this can be done.

Add the Adaptive Tags to your own header
The following code comes from \imageserver \plumtree\portal \private\pagelayouts \basepagelayout.html. You can stick this code into any header (or footer, or portlet) to get the Debug link to show up, and it will only show up for the appropriate users.

    <pt:core.comment><!-- DCA - get the Rules Debug link; if we don't have access to the rules debug page, the variable won't exist --></pt:core.comment>
    <pt:ptdata.rulesdebugdata pt:id="rulesDebugLink" />
    <pt:logic.existexpr pt:data="rulesDebugLink" pt:key="canAccessRulesDebug"/>
    <pt:logic.if pt:expr="$canAccessRulesDebug">
            <pt:core.comment><!-- DCA - there should only be 1 --></pt:core.comment>
            <pt:logic.foreach pt:data="rulesDebugLink" pt:var="link">
                <li><pt:core.html pt:tag="a" target="_blank" href="$link.url"><pt:core.html pt:tag="img" src= "pt://images/plumtree/portal/private/img/icon_subportal_rule.gif" alt="$link.title"/></pt:core.html><pt:core.html pt:tag="a" target="_blank" href="$link.url"><pt:logic.value pt:value="$link.title"/></pt:core.html></li> &amp;nbsp;|

Access the URL
The debug Messages page is available at /portal / open=space &name=RulesDebugMSGAS. You can just drop that URL in there and the browser should display the debug page if you have access.

Use the MemoryDebug space
Finally, the portal session object stores this information so that it can be accessed through the MemoryDebug page we’ve discussed before. Just flip your URL to /portal / /debug /memory and you’ll see something that’s a little less readable, but still a functional alternative to the above two methods:

One caveat to all of these methods is if you have Community-based rules. Because sometimes the debug page itself applies its own URL for the rules, in some cases that means you’re no longer in any communities, so that could mean you get a false-negative for that condition. Your mileage may vary.

What Experience Definition is being applied?

Sunday, November 6th, 2011

In Plumtree they were called Subportals. In Aqualogic the name was changed to Experience Definitions, and they continued to evolve in WebCenter Interaction with the introduction of Adaptive Layouts.

Experience Definitions are useful constructs in the portal that allow you to customize the header/footer, navigation, and Adaptive Layouts based on Experience Rules – which can be applied based on the host IP, community, user/group, or user-agent header. So you can apply different rules based on any of those criteria and heavily customize the experience based on any of those conditions.

An useful feature that was introduced with Experience Definitions was the “Debug Mode”, which can be accessed from Administration -> Select Utility -> Portal Settings -> User Settings Manager:

When this option is selected, a new link for “Show Debug Messages” is shown in the standard topbar, or in the out-of-the-box Adaptive Layout:

From this link, you can see the “Rules Debugging Messages”, which explains each rule, whether it matched the condition, and how long the evaluation took:

WCI Health Monitor: Interesting but Useless

Friday, October 28th, 2011

As I’ve dug into the rarely used diagnostic pages in the WebCenter portal, I’ve taken a second look at the System Health Monitor. As mentioned, you can get there through the URL /portal/, /portal/, or just by going to Administration -> Select Utility… -> System Health Monitor.

Here you can see various half-baked real-time diagnostic reports. They’re interesting because you’ve probably had your portal running for years (really, are there any NEW Webcenter Interaction clients these days?) and haven’t seen these reports. But they’re not particularly useful because they aren’t reliable – false “offline” reports are common – and don’t provide a decent interface to tie into a reasonable monitoring solution. A REST-based solution would be nice to be able to query the status of various services, for example.

Maybe I’m being hard too hard on this thing. While the high-level “Related Services” or “Remote Host” reports don’t seem to work all that well, if you click on the “Remote Host” links you get a Web Service report showing the status of the various services running on that Remote Server:

Yeah, I suppose that could be useful. I better go figure out why half my portlets are showing offline. You prob’ly should too…

WebCenter Interaction Debug Space

Saturday, October 22nd, 2011

Years ago I posted about a little-known MemoryDebug Activity Space in the Plumtree portal (or were we already calling this thing AquaLogic or ALUI by then?).

Recently I found a somewhat “meta” page with an activity space name of just “Debug” that links to this MemoryDebug space and two other useless pages. I won’t get into the gory details here, but I stumbled across this when dealing with some code related to varpacks (we’ll get to all those gory details in due time).

The gist for this post is that you can not only view the debug space in your portal by setting the space to Debug (/portal/, but there’s also a Friendly URL for this space: /portal/

In fact, all three of these debug pages have friendly URLs

  • portal/ – a useless ‘help’ page
  • portal/ – the memory debug page, largely only useful for reloading varpacks
  • portal/ – the useless page you can access through Admin: Select Utility: System Health Monitor

This isn’t an entirely earth-shattering discovery, but as I’ve been revisiting this debug space and friendly URL configurations, I’ve made some other interesting discoveries that I’ll post about soon. In the meantime, try out those friendly URLs in your portal and marvel at the completely hidden piece of functionality you never wanted or needed.