Category Archives: PHP

Two WordPress Plugins To Improve Your User Management Page

This is a two part post that will give you the code for plugins that will modify your WordPress user management page with some useful additional information

wp-users

This post will give you the code for the highlighted area on the left. This code adds two bits of information for every user, their last login date and time, and the last date and time they they were active. When you hover over the “Last login” and “Last active” text the tooltip shows you the exact date and time info. Continue reading Two WordPress Plugins To Improve Your User Management Page

PHP Pagination Class – Version 3

It’s been a while since the popular PHP pagination class has received any of my attention, so a few months ago I set out to re-write the class to be more up to date. This version takes advantage of both code and security updates as well as updates to PHP and MySQL. I’m also planning on moving the code over to GitHub where it should be easier to manage.

Here is the new and improved PHP pagination class for your enjoyment:

Download

See the example files for how to use. I’ll create step-by-step instructions shortly.

Demo

Note that the demo uses MySQL’s free “world” database available at http://dev.mysql.com/doc/index-other.html

  • Example 1 (basic paginated database result set)
  • Example 2 (Form variables passed via pagination class)

PHP Pagination Class Updated – Version 2

Based on feedback (and the long time between updates), I’m releasing an updated version of the PHP pagination class.

Changes

  • No more SQL errors if using the class on a query with no results (although I fail to see the point of using it on an empty query anyway, but the bug is fixed)
  • When selecting ‘ALL’ only one page is displayed, and if you are using the display_items_per_page drop-down menu, ‘ALL’ is now selected as well.
  • If a page less than page one, or greater than the total number of pages is requested, no results are displayed and the appropriate prevous/next links are disabled
  • The items per page array that populates the display_items_per_page drop-down menu is now an option that can be configured when instantiating the class. Previously this was hard-coded to the class.
  • The $high option has been removed from the class (it was never used).

Note that if you receive a PHP notice about undefined indexes that you should turn down your error reporting. This notice may be displayed when loading the page for the first time when no $_GET variables are present. The class accounts for this, however PHP throws a notice about it.

Examples

I’ve also added license info at the head of the class (CC Attribution-ShareAlike 3.0 Unported (CC BY-SA 3.0)).

Download

Narrow Minded

Recently I was checking out some code written many years ago by another developer, and as I was hacking it up to be re-used, I started wondering why he had decided to split up his lines of code so that they were very narrow. Comments, for example, that were a few sentences long ended up spanning nearly a dozen lines when they could easily exist on just a couple of lines. It was then that I noticed that he had been wrapping his text at 80 columns – in other words, each line contained no more than 80 characters. It’s been a long time since I forced myself to wrap code at 80 columns, either because what I had written was concise to begin with, or because no one else would be looking at the code and it just didn’t matter, and I had almost forgotten why people did this in the first place.

I’ve seen code wrapped at 80 columns plenty of times before, but something about picking apart this code at that moment made me suddenly ask why. What was so special about this 80 column “standard” and why was it seen throughout the programming world? When I first started out coding this was just assumed to be the way to do things but I had never fully heard an explanation as for why this was done.

As it turns out the answer lies in old technology and tradition. In the early days of coding,  text based terminal displays were only 80 characters wide, so any lines longer than 80 characters needed to be wrapped. There just wasn’t any choice in the matter. Remember that GUIs and mice didn’t exist back then and scrolling was typically done only vertically. Some people believe that the even older computing method of using punch cards, which also typically had 80 columns, is the reason for this style of coding, however while it may have influenced the design of those old terminals, I don’t believe that punch cards directly gave way to practice of coding text at 80 columns.

Now since virtually no one uses an old terminal to write code, and today’s monitors are larger and have larger display resolution than older machines, why do we still see this? The answer? Tradition. Well that and readability. While most modern code editors will let you type a single line for as long as you want, reading that line becomes a huge pain in the ass. You’re forced to scroll horizontally to the right to read the code or comment, and then scroll back to the left to get back to the rest of the code. While an 80 column limit might seem constrictive or limiting, it actually makes code easier to read, and can help you write better code by making you find ways to shrink your code down to fit in one line. Another advantage to limiting the characters per line is code comparison. By staying with the 80 column rule you can usually fit two files side by side and examine them line by line quite easily.

Oh and while 80 columns is sort of a standard, 72 and 76 column layout are also quite common, but slightly more restrictive. Personally I am lazier than I like to admit and I often don’t pay a load of attention to how many columns each line of my code takes up. But that’s being both a bit lazy and selfish. By making your code readable, it helps you and anyone else looking at it…and you just know you’re going to need another set of eyes looking at your code at some point to help ferret out a bug down the line. And while I’m no advocate for 80 columns, if you stick with a layout that makes your code easy to read why not pick something like 100, 120, or 132 columns now that most people have larger monitors? Being lazy I also don’t think that any of this should be a rule but more of a suggestion or guideline. Bottom line, once you get your code to work the way you want it to, why not make it look good and improve the readability at the same time?