Posts Tagged ‘wordpress’

Cool Tools 17: WordPress 3

Wednesday, May 4th, 2011

Blogs and Wikis, Wikis and Blogs.  We’ve been hearing it from Plumtree, then from BEA, and now from Oracle for the Plumtree/ALUI/WCI stack.  Remember PEP (Pages, Ensemble, Pathways), and how it promised wiki and blog functionality?  And how ’bout this semi-official Oracle WCI blog that … well, you be the judge.

It’s true:  Plumtree has a checkered past in delivering us to the promised land of user-generated content in the early noughties – to say nothing of the Enterprise 2.0 (Social Networking) trend of the past couple of years.  The WebCenter Suite promises to start getting us there, and there are unconfirmed rumors of WebCenter Collaboration Server getting this much-needed functionality, but for now user-generated content remains largely a pipe dream for those clients still on the WebCenter Interaction stack.

We all have blogs and wikis, so why haven’t we seen a serious contender for one of these products to work well in the WebCenter Interaction stack?  The answer is maybe that we’re looking for too tight of a coupling from Oracle:  the reality is that if you follow the Four Tenets of Portal Integration, you can provide a pretty compelling and integrated experience for your users, which is exactly what we’re doing with this blog and demonstration site:  notice how the URLs of this site change as you click through the tabs at the top?  That’s because some pages come from WebCenter Interaction, and some from WordPress – but the user (that’s you!) is none the wiser.  Administrators (that’s me!) love it:  in addition to the insanely easy setup and configuration and the vast library of third party plugins that can do pretty much anything and everything you might need, there’s also an almost comically easy upgrade process:

That’s right, WordPress knows when it’s out of date, and prompts you to update. Seven seconds after clicking “upgrade Automatically”, we’re all done:


Try upgrading WCI in 7 seconds!

Oh, and while this blog isn’t demonstrating integrated search or authentication, we’ve got that too

Bug Blog 1: WordPress Commenting with Large User-Agent headers

Tuesday, February 2nd, 2010

I love blogging to help others out with Plumtree / ALUI / WCI issues, and to contribute to the “The WebCenter Interaction” portal ecosystem. But I have a confession to make: A big reason I blog is to create my own reference tool. I find myself always forgetting the syntax for Remotely Rebooting Windows Servers just when I need it, or the console command to use when the number of Remote Desktop Connections are maxed out in Windows.

I know I’ve overcome challenges like these in the past, but can’t remember the command syntax or how I did it. So I do a Google search for something like wordpress rather than a general search where I have to dig through thousands of responses.

My first WebCenter-related tip for this post is to use “” or “” in your Google queries for WebCenter tips you know you’ve seen before but can’t quite remember where they are.

Secondly, I’ve been looking at integrating the WordPress blog into the WCI portal.  As of this writing, I’ve basically been getting acquainted with the technology and have gotten the UI pretty much down by simply mirroring the portal UI in WordPress.  This blog is a good example of that, as is the Health Buzz Blog (check out the blog, which is running WordPress, and click the nav links on the left, which link to the portal).  Next up for WordPress blog integration is Authentication, Authorization, and Search.

But that’s not the real reason I started this post. The real reason was that I found myself debugging a WordPress (2.8.6) bug knowing in the back of my mind that I’ve seen this before but forgetting how I fixed it. The bug is that when a user submits a comment to a blog post, the page that comes back is a 404 error and the comment isn’t recorded. Turns out – after a crash course in PHP and way too long doing diagnostics and printing debug statements – my browser has a User-Agent header that’s larger than 255 characters. This causes WordPress to fail deep in its core, and it improperly redirects the browser after a comment is posted without showing or logging any error messages.

The solution (and maybe I’ll remember this the next time I run into it without spending another hour looking for my own bug report): increase the size of the comment_agent column in wp_comments:
ALTER TABLE wp.wp_comments MODIFY COLUMN comment_agent VARCHAR(512) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL;

Astute readers will notice that I’m a little behind in my WordPress versions; the latest as of this writing is 2.9.1.  However, as this is as much of a test/demo environment as a “real” web site, I’m testing out WordPress MU, which is a couple of revs back due to the additional functionality: WordPress MU (multi-user) is what would allow us to provide each portal user and community with their own blogs.

Interested in getting an industry-leading blog integrated with your WCI portal?  Drop a comment here, contact me, and/or stay tuned!