These days, I feel like I spend a great deal of my time figuring out how to tweak WordPress to work as a simple but elegant content management system. In the fall, I worked on a site for a family member that finally got me thinking about the possibilities on this front. Then, in November, I turned my attention back to revamping the DTLT Web site in WordPress and using a bunch of plugins to make the CMS thing work. At the time, I settled on installing it outside of UMW Blogs because I thought I was going to need to use some plugins that weren’t available in that environment. A lot of my attention was focused on Flutter, which allows for customization of WP’s internal write post/page panels.
In December, I was asked to fast-track a new site for the upcoming strategic planning process that’s about to kickoff at UMW. That site should get unveiled to the community later this afternoon. This time, I decided to use UMW Blogs because so many of the constituents (and those who will need to work on the site) already know and have accounts in that system. Thanks to Jim, I was able to install a few extra plugins that enabled me to do some more cms-y things there.
The most notable was a very powerful plugin called Widget Logic. Basically, it allows you to use WP conditional tags to govern when a widget is displayed in the sidebar(s). Used well, this means you can have dynamic, contextual sidebar content/navigation for different parts of your site. But there’s a downside to this widget. You have to be willing to delve into conditional tags. I love that kind of tinkering, but I’m not sure many other users in UMW Blogs are going to be willing to go there.
But the bigger challenge on all of these sites has been making sense of the page/post dichotomy. Jim has pointed out to me a bunch of time how broken he thinks pages are in WP, and I have to agree with him.
Take the strategic planning site for example. I knew that I wanted some content to use the features of posts: subscriable, able to be added to categories, displayed in rev. chron order. But, I also knew that the authors of the site would probably want to post some content that didn’t make sense in posts–content of a more static nature. Ostensibly, WP solves this by offering you posts and pages, but it is virtually impossible to get these two to play nicely together.
What I ended up doing was creating an information architecture twice: once in a page hierarchy (so the static-type content could be organized effectively) and once in a category hierarchy (so that posts could be assigned to the appropriate place). But when it came time to make those two hierarchies work together, I had to do a bunch of template massaging and widget logic-ing.
I can, for example, show a navigation menu of pages in the sidebar, that expands and collapses based on where I am on the site. But as soon as I jump out to a post, I lose that context and the navigation stops making sense. What would be nice is if pages could belong to categories! I have no idea why this isn’t a feature of pages now. I see enough people asking about it. I know there are plugins out there that kluge this, but I’m not sure that’s ideal in a WPMU environment. (Perhaps I’m wrong, but since categories exist across the entire WPMU environment, any tinkering with that feature would make me a little nervous).
Oh, and WP really needs a way for users to easily reorder pages without having to use the ridiculous page IDs.
With these two features: page categories and easily reordable pages, I think we might be able to get to a very nice CMS right out of the box. In the meantime, sometimes I feel like I’m jamming a square peg into a round hole. Again, I love doing all this tinkering and massaging, but I’ve got to build something that works well for the users who will be authoring the vast majority of content on these sites. If there’s too much kluge and not enough smooth, I’ll be hearing about it. (ouch)
In the meantime, for your viewing pleasure a bit of 80’s nostalgia:
Hmmm….
hm. hm. hm. hm….
If only ……. nah….. I wouldn’t want to use the “D” word. 🙂
But seriously, I really am starting to worry that 1) we’re doing faculty an injustice with the position that Drupal’s interface is “too hard” (picture pulling the string on the back of “Faculty Barbie” and it saying “Drupal is hard!”). I hear little to nothing about the interface being the problem with the Drupal installations I handle — I hear a lot about how to best take advantage of all it does. 2) we expect too little of them by saying “just use umwblogs because many already know it”. We don’t expect the students to stick to one, familiar tool that they already know (like Blackboard? Like MS Word?), do we? Why do that with the faculty? (Okay, I know some of the answers to that one, but still….)
@patrick Yeah, I was going to address the “why not use Drupal?” question but decided that I would try to avoid another obscenely long post.
I actually have a longer, more focused post brewing in my head about this topic. It’s taking a while because I’m trying to avoid talking about my perceptions of these applications from a “gut” perspective. I want to be rigorous.
In this particular case, however, the parties involved didn’t want to add yet another environment to the landscape. And there was a big emphasis on making sure people would be as comfortable as possible (read: familiar) with the tool(s). Whether or not we’re achieving that remains to be seen.
But, more importantly, you did not comment on the video, so I must ask you to try again. 🙂 Really, this whole post was just a device for posting that little blast from the past. The WP-CMS thing was just to lure people in.
We had some success at Keene State with Google Sites for things like this, though the “signup for another login” bit was not always appreciated.
Of course, I hightailed it out of there just after implementation, so who knows how it’s going.
I also had a failure with running a WP based document/CMS site some years back. But I think a lot of it was I wasn’t aggressive enough with people to say, “look, we are seeing this through and going to make it work, and I’ll help you but retreat is not an option.” It was viewed as “yet another tool” and while there were tech problems with it, I think the biggest barriers were cultural.
Which is great, of course, because cultural problems are the worst to have. But I guess I’m saying I’m not sure it would have gone any differntly if we had used Drupal or Sharepoint.
Martha,
You know why you are so good at your job? Because you get this:
“I love doing all this tinkering and massaging, but I’ve got to build something that works well for the users who will be authoring the vast majority of content on these sites.”
As a user, I just want to say “Thank you.”
So, I’m a little late to this conversation, but hey, I’ve spent a lot of my life being late to various things.
Patrick, in the first comment, makes a lot of sense. The D-word could address a lot of issues here.
The use of conditional logic for sidebar widgets (in Drupal-ese: blocks) is core functionality. Blocks can be shown/hidden based on url path, user role, type of content, etc, etc, etc.
RE: “I can, for example, show a navigation menu of pages in the sidebar, that expands and collapses based on where I am on the site. But as soon as I jump out to a post, I lose that context and the navigation stops making sense. What would be nice is if pages could belong to categories!”
In Drupal, you can do this using the core menu functionality, the core book module, or via core taxonomy.
RE: “Oh, and WP really needs a way for users to easily reorder pages without having to use the ridiculous page IDs.”
In Drupal, pages can be reordered within a book or menu navigation structure via drag and drop. If you want to use a contributed module, the Views module allows you to create specific ways of ordering content. With views, once you set up your ordering rules, new content gets handled/organized automatically, without any additional interventions needed by end users or site admins.
In looking at WordPress and Drupal side by side (which isn’t an easy thing, as they really are apples and oranges — both sweet, juicy, and tasty, but different) Drupal requires more work up front. You need to know your architecture, your user stories, your use cases, your logic, and then you build your site. The flexibility is best leveraged as part of a plan. With WP, on the other hand, you have more flexibility to build it as you go.
Cheers,
Bill