Adding filtering to the ‘Recent Comments’ WordPress widget
I recently started using WordPress‘s dynamic sidebar functionality for the side column on this blog which contains things like lists of recent posts, recent comments etc. My main motivation for doing this was to get access to the ‘Recent Comments’ widget so I could list the most recent comments on my posts.
To activate the widget and the dynamic sidebar I did the following:
- Logged into the WordPress admin dashboard.
- Clicked on the ‘Design’ tab.
- Clicked on the ‘Widgets’ sub tab.
- Added a sidebar.
- Enabled the ‘Recent Comments’ widget.
- Clicked save changes.
- Reloaded my blog’s main page in another browser tab and noted the normal side bar had disappeared to be replaced by the sidebar that currently contains only the ‘Recent Comments’ widget.
- I then added some other widgets to replicate the original functionality in my original sidebar.
I then noticed that my ‘Recent Comments’ widget contained not only user comments but trackbacks and pingbacks too, this was annoying as I only want user comments to be listed and nothing else. After some searching around the web for a simple solution, followed by some experimental tweaking of the WordPress source code, I can now present the simplest solution I could make to filtering out all non-comment comments from the ‘Recent Comments’ widget:
- Open your WordPress installation folder via ftp or locally.
- Open the ‘wp-includes’ directory.
- Make a back up copy of the ‘widgets.php’ file, just in case.
- Open the ‘widgets.php’ file.
- Search for the following line in the function ‘wp_widget_recent_comments’ (it was at line 981 in version 2.62 of WordPress): $comments = $wpdb->get_results(“SELECT comment_author, comment_author_url, comment_ID, comment_post_ID FROM $wpdb->comments WHERE comment_approved = ’1′ ORDER BY comment_date_gmt DESC LIMIT $number”);
- Make the following addition (in red) to the line: $comments = $wpdb->get_results(“SELECT comment_author, comment_author_url, comment_ID, comment_post_ID FROM $wpdb->comments WHERE comment_approved = ’1′ AND comment_type = ” ORDER BY comment_date_gmt DESC LIMIT $number”);
- Save the modified file.
- Upload the updated file to your web server.
- Reload your blog’s main page, you should now only see comments in the ‘recent comments’ list.
For those that are interested in what this change actually does, here is an explanation. The line of php code we are changing queries SQL database that is part of your WordPress installation and searches the comments table for the latest user specified number of approved comments. The addition we are making adds an extra clause to the SQL query that searches for the latest approved comments: this extra clause specifies that we are only interested in comments when the comments table’s comment_type column has the value ” which is the value WordPress uses to designate user comments and not trackbacks or pingbacks.
Note: This change was made and tested with WordPress version 2.6.2, I don’t know how well it will work with older versions of WordPress. Also if you upgrade your WordPress installation you will need to make the above change again, unless the new version already implements it.
User Population Vs User Expertise
Mapping user expertise against the user population of a product tends to result in a bell shaped curve. Indicating that most of the user population for a piece of software has an intermediate level of expertise. This is an important observation when developing software as developers (as expert users themselves) will tend to develop more expert features and customer support will push for more beginner features. There is then a high probability that the largest part of the user population (the intermediate users) will be ignored, at the cost of increased product adoption or sales.
Useful Status Reports
Status reports are a way of life for most developers, however there is no standard way to write a status report unless you have a manager or team leader that is supplying some sort of template to fill in. This lack of examples leads to a lot of confusion about what information to include, the type of details to supply and the size of the report to deliver. There is always the suspicion that these reports are seldom read and the urban legend of the engineer that wrote their reports in a foreign language to see if their manager would notice, which allegedly they didn’t.
In my experience I’ve only ever had one manager who I know who would read and understand the reports given to her by her engineers in whatever format their engineers chose. Most managers are not usually as flexible as this or as technical which leads to problems with them not understanding the reports and the potential for developers using technical terms as a smoke screen.
I think the best way to think about how to write a status report is to think about what the motivation is for the person who is asking for the report, what do they want to know? In most cases what they want to know is:
- The work that has been completed since your last report: the gains.
- What could cause problems in the future: the risks.
- Things you’ve encountered that caused problems: the issues.
It is also worth considering how they want this information presented:
- An easily digestible format: the use of technical terms for non-technical individuals is counter productive. Even if your manager or team leader is a technical individual it is quite likely their superiors are not technical or not closely familiar with your teams problem domain.
- In a concise manner: most managers or team leaders usually have to supply reports of their own to their superiors so having to distill the reports given to them during the preparation of their team reports is inefficient.
- In a single sentence: The more senior a person is the more likely they are to skim reports given to them due to time constraints. This makes concise non-technical summaries very important for getting the key points of the report across.
Below is a template I currently use for my end of scrum status reports for my team, which I supply to my non-technical manager as an email. The colour coding seems very popular and makes it easy to skim. There are notes in the template that I write over that I added for myself to guide me while I write the report, which takes no more than ten minutes. I keep this template inside a task in Outlook which I have set to recur at the end of each sprint, so I don’t forget to write the report or lose my template.
Summary sentence, avoiding technical terms and picking out the most important points, as this sentence may be as far as some people read.
Gains:
- List of completed features.
- Concise as possible.
- No technical terms!
Risks:
- Possible future risks and potential solutions.
- Concise as possible.
- No technical terms!
Issues:
- Problems experienced and the solution(s) used.
- Concise as possible.
- No technical terms!
Holiday
I am on holiday until Sunday 19th October 2008. So most likely no posts until then.
Cost, Quality & Performance
It is generally regarded that there are three primary properties of a software product: cost of development, performance (speed/memory etc) and software quality. It is believed that you can only ever obtain two of these properties at the cost of the remaining property e.g, you can have high performance and high quality but it won’t be cheap to develop.
My experiences over the years tends to confirm this rule of thumb but I can’t help wondering if that fictional high performance, high quality and low development cost software has ever been made?
Small frequent changes
When I first started using version control software (originally SourceSafe, now Perforce), I used to have a large amount of changes over many files checked out all at once, which I would work on over a week or more and then check in at once. As I have become more experienced I have started to favor many small stable check ins containing a few hours to couple of days of work to large monolithic check ins which represent a week or mores work. The reason for this is that I’ve had to support at various times software I did not write, which means I don’t know the full history of the source code and there is usually no documentation or original authors to quiz either. Software in this state forces the maintenance programmer to relay only the only two remaining sources of information available the source code itself and the version control history of each file in the project.
Having to relay on version control history of files for investigating bugs highlights just how much of a bad idea large monolithic check ins are, especially those with short check in notes and lots of changes. The problem with large check ins is simply that the check in contains many different changes for potentially many different tasks e.g. bug fixes, new features, refactoring. Which makes it much harder to quickly and easily see the changes for the particular task you are interested in. This problem can be exasperated by refactoring being combined with other work in a single check in as it makes it even harder to separate the refactoring from the bug fixes or new features.
I have also become much more picky about the descriptions entered in the version control software for each checked in file, I used to be brief but now I find myself being more detailed in my description of the work contained in each check in. I find that doing software maintenance, especially on systems where all the original authors are no longer available, really presses home the need for descriptive check in notes. As without a detailed note of what each check in contains the poor maintenance programmer is forced to sift through every revision of every file in a project when looking for a bug, which only has to be experienced once to make even the most terse note writer a believer in descriptive check in notes!
I’ve also found myself developing the habit of checking in the skeletons of new programs as I write them for example I will create the build, configuration and source files for my application and then get these files building and then check them into source control. This lets me easily see the differences when I start working on the first feature, as otherwise all the files would appear new in version control which would limit the effectiveness of the source control & comparison tool combo as a means to detect changes.
Code reviews have also highlighted how not checking in the application skeleton can make it much harder on reviewers who now need to work out which changes are just program structure related and which are feature related. The most unpleasant code reviews are those of whole programs that have been developed from scratch to fully functional without a check in. It is unrealistic and unfair to expect a worthwhile or comprehensive review of such a check in, unless the application is a tiny single source program of under a couple hunderd lines or less, as the review will simply be swamped by the sheer volume of the changes.
Part of my passion for source control is driven by my love of file comparison tools like Beyond Compare, which allow the visual display and highlighting of the differences between many types of file. File comparison tools ares especially useful when viewing the history of a file in version control, when hunting for bugs, remembering and reviewing what you’ve changed and performing code reviews. One of the first things I will do when setting up a new workstation is to install Beyond Compare and set it up as my default file comparison tool in Perforce. I will regularly diff files with Beyond compare over the course of a day: to review my work so far, to review work before I submit a code review, to check a files history, to verify program output versus expected output etc…
In my mind the ideal check in:
- Contains only changes related to one type of task: skeleton source code, refactoring, bug fixing or a new feature.
- Has a detailed note attached: anyone who submits ‘updated’ as a note should be challenged.
- Represents a short peroid of work e.g. an hour up to a couple of days.
- Contains no unchanged files: this is a personal bug bear, nothing clutters up file histories like check ins of files with no changes. If possible disable this on the source control server or client.
- All files should be manually checked with a comparison tool, to check for test code, unessessary changes and temporary hacks.
- Should NEVER break the contineous auto build.
- Is fully tested using all available testing resources.
- Has be code reviewed by a peer.
