Archive for the ‘Software’ Category

Jun 17 2010 at 9:58am

Improving the default content, comments, and user admin pages in Drupal using Views

If you’re like me, you may find the default content, comment, and admin pages in Drupal to be somewhat inadequate. For example, the default content admin page (for nodes) does not allow you to filter by author name, keywords in the title, taxonomy, or publish date. The comments page does not have filtering options at all. The users page does not allow you to search for a user name or join date (you can search for users using  Drupal search, but this does not allow you to perform bulk operations on them).

I have created some views to replicate these pages with more filtering options. View Bulk Operations does come with a sample view for content, but I found that this view didn’t contain the options I wanted. Each view comes with two pages: one to replace the default admin pages (admin/content/node, admin/content/comment, and admin/user/user) and one for a tabbed interface of all three views. It would be nice if these could be the same page but you can’t have more than one URL for a page. Read more…

Apr 02 2010 at 1:49pm

As it turns out, we did choose Drupal

Back in September I wrote about an agreement by the University of Waterloo to use the Open Text Web Content Management system. Well, as it turns out, that decision was “revisited” in February and UW will be using Drupal as it’s official web content management system.

I have been on maternity leave since October so I’m not entirely sure of the reasons for this decision. I know that some people went for training on the Open Text system in November and found it to be very cumbersome and difficult to use (something I thought was evident from the beginning, to be honest!). I think there were some other issues as well but I don’t know too much.

Needless to say, I am thrilled!  There is a tiny bit more information on the Kitchener Waterloo Drupal User’s Group, as well as in the UW Daily Bulletin.

Sep 08 2009 at 8:04pm

Why we didn’t choose Drupal

Well, actually, we didn’t really “choose” anything. Something was chosen for us in the form of a “donation” from  OpenText of their web content management products to the university. I co-chaired the committee that was charged with investigating content management systems in the fall and winter 2008/2009. This “donation” was arranged completely outside of our committee. In fact, we didn’t even know it was happening until the deal was essentially done.

I did do my best to sell the benefits of Drupal to the committee, and to explain why the OpenText product (formerly called RedDot) was not a good solution (phrasing it politely). However, I’m not sure that, given the chance, “we” would have chosen Drupal anyway. Why? Here’s a few of the biggest objections given by others in the group:

  1. Sever models – the other two systems under consideration used a “push” model where static pages would be published to outlying web servers. This was considered to be preferable to a centralized model where pages are served by a database. Why? Mainly because many units within the university really want to run their own web servers. They also liked that the main system was “behind the firewall” and therefore more secure. This issue was focused on by some people to the exclusion of any other factors (usability? functionality? extensibility? who cares?). A few people actually said that since these two systems used the same publishing model then they were “really the same”.
  2. “It’s not enterprise” - I’m not sure what this is actually supposed to mean but it was a big problem for some people (and I’ve heard this in other higher ed circles as well). Maybe if it had a sticker price of half a million dollars and  obscenely complicated server requirements, then it would be “enterprise”??
  3. Security – there are still many people out there who believe that open source must be insecure because it’s developed by “some guy in his basement.”

There might have been other issues, had we ever gotten around to actually testing Drupal against the other two systems. Drupal isn’t exactly known for its usability, but from what I saw from the others Drupal isn’t any worse and might actually be better. To be honest, our presentation from Acquia didn’t do a lot to make the benefits of Drupal more clear.

May 29 2009 at 10:25pm

Universal IE6 CSS and memories of NS4

There was been a lot of controversy last week over Andy Clarke’s proposed Universal IE6 CSS. Most of the arguments against it seem to revolve around the level of IE 6 usage and clients’ needs to maintain their brand image. Valid points, in many cases.

However, as Zeldman notes:

No hammer fits all nails, and no solution, however elegant, will work for every situation. But if we’re open minded, Andy’s proposal may work in more situations than we at first suspect.

Read more…

Aug 29 2008 at 1:08pm

Moving from Mac to Ubuntu: Why I’m switching

When I started my new job in October the computer that I had to use was a Power Mac G5. This wasn’t my choosing – the guy before me really liked macs and had the whole office switch over several years ago. I was allowed to get a new laptop as well, and chose a Lenovo Thinkpad T61 and installed Ubuntu.

Until now the Mac has been my primary machine – home of email, web browsing, scheduling, and my main design activities. Why? Because that’s the way I set it up at first, before my laptop arrived. I used the laptop mainly for harder development activities, and file transfers (more on that later).

This week I finally decided to move to the Ubuntu machine for my primary activities. Why? Because I just don’t like OSX that much. It hinders my activities in some pretty significant ways.

Why I’m leaving Mac

  1. Crap file management.The Finder doesn’t work for me. No location bar and no tree strucure side panel makes it difficult to navigate folders and move files around the way I want to.
  2. Insufficient panels & customization. In Ubuntu I can have as many panels I want, can put all kinds of stuff on them, and can arrange them however I want. In OSX You just have the dock, and you can really only put applications or files on them, and you can’t even put in a separator to keep them organized.
  3. Various other annoyances. Such as:
    • program menus are glued to the top of the screen on one monitor only, which detaches them from the window. This is especailly annoying when the program you’re using is on the second monitor.
    • the date/time doesn’t open to a navigable calendar. I often use this to check dates in the past or future.
    • you can’t see hidden files unless you run a command from the terminal to turn them on. Thus, hidden files are either always on or always off.

Why I’m keeping Mac

I’ll keep the Mac around for some tasks (I have a KVM switch set up so I can easily toggle between the two), including:

  1. Those pesky .docx files. Correction: Open Office is now able to open .docx format. This must be new because when I tried last week it didn’t work.
  2. Dreamweaver – until we get a CMS in place I still need to manage sites built with DW templates.
  3. Photoshop – because sometimes the Gimp isn’t enough.

Update 02/09: My apologies for the tone of this post. I didn’t mean for it to be inflamatory in any way. I actually had made some edits that were accidentally lost (how, I don’t know!). Sorry about that!

Update 03/09: Comments on this post are now moderated.

Jul 11 2008 at 9:11am

Quick WordPress plugin installation with ssh and wget

Have you ever wanted an easier way to install WordPress themes and pugins? If you have ssh access to your website you can install them directly on the sever with a few simple commands. No more downloading to your computer, extracting the zip file, and uploading again. This also works really well with Drupal Modules or any other script you need to download from another site.

(Unfortunately, most shared hosting accounts don’t have ssh access, but hopefully this will be useful for anyone on virtual hosts or dedicated servers who don’t already know how to do this!)

  1. SSH into your website. Don’t know how? Try this:
    1. open a terminal
    2. type ssh username@yourwebsite.com
    3. agree to any host authenticity messages
    4. enter your password at the prompt
  2. Navigate to your wp-content directory. Depending on your hosting setup the command will look something like this:cd httpdocs/wp-content/plugins/ or cd httpdocs/wp-content/themes/
  3. Get the URL for the plugin or theme you want to download. The full url to the zip file. (This makes it really annoying when plugin developers hide the full url!)
  4. Type in wget http://linkto.com/theplugin.zip
  5. Wait for the plugin to download onto your server
  6. Unzip the file by entering unzip theplugin.zip. If you have a .tar.gz file use tar -xvzf theplugin.tar.gz.

Done! Now you can go into your wordpress admin panel and activate the plugin or theme.