Attended yesterday's HCMC meeting with EGW, MH, GN, EF (see posting).
Preparing Humanities and Continuing Studies contact information regarding lab use/users requested by end of week for EGW/EF.
A while ago I did a bunch of GREP work on some excel files PD sent me to: divide one address field into StreetNum, StreetName and StreetNotes fields. In doing that I noticed that the pointers in that file to records in another table were out by a fixed number so modified that too.
Turns out that the file PD sent me had the address field sorted in the wrong order relative to all the other fields for each record, so he fixed that and I had to re-do the GREP. Having completed that I then set to do the renumbering and noticed that due to the new sorting, the pointers were now off by a gradually accumulating number, rather than a fixed number. It took half a day to get the pointers sorted out.
Sent the updated files to PD. He's satisfied everything's in order now.
I've normalized the data in the census_directory_matches.xls file, so that the address street name and street number appear in separate fields, and so the pointer to the records in the business_directory table are correct.
Addresses:
I've split the addresses from one field into three fields:
AddNum
AddStreet
AddNotes
Some of the numbers contain the 1/2 character. This may matter later as the inclusion of that character means the numbers can't be treated as integers (obviously as they're not), and I'm not sure if they can be treated as decimals either (depends if the software is smart enough to figure out that "1/2" is the same as "0.5". We can certainly always treat those numbers as strings of characters (i.e. do searches on them). We'll cross that bridge when we come to it.
I made no effort to normalize street names, but let PD know that there are apparent inconsistencies in the original data, if that matters.
Record Id's
The copy of the database PD derived the census_directory_matches file from was out of date, so the xls file had values in the "recordId" field which pointed to non-existent records in the 1892 business_directory table.
I created a new field called curDirId in the census_directory_matches file. I copied the values from the recordId field into the curDirId field and then did the following:
For records with old recordId 2585+ : adjust curDirId by +2327
For records with old recordId 2662+ : adjust curDirId by -1
For records with old recordId 4003+ : adjust curDirId by -1
For records with old recordId 6504+ : adjust curDirId by -1
For records with old recordId 8783+ : adjust curDirId by -1
For records with old recordId 12180+ : adjust curDirId by -1
The first step started the numbering at the correct place. I then discovered that the current database has five fewer records than the version PD must have been using, so I had to go through and figure out where to adjust the numbers again to correct for that.
The quantity of comment spam has reached the point where we're no longer prepared to put up with it, so we've turned off comments on all blogs. If anyone needs comments turned on for their blog, let me know.
I also deleted Stew's Placeholder blog (what used to be DeptSites), as it was never used.
The left menu in the main blog home page, showing the list of blogs, was sorted case-sensitively, with lower-case elements such as teiJournal sorting after all the upper-case ones. Investigated this, and found that the sorting code is in this page:
/blogs/skins/_bloglist.php
This code basically creates an array of the blog list item tags, indexed on the blog name, and then sorts it using ksort
. Lower-casing the blog name before it's used as the array key solves the problem, so I've implemented that fix.
We often need to mention <HTML>
<tags>
in our posts, and I was getting a bit tired of typing all the escaped angle brackets. Now, if you highlight a word, then press the "tag" button on the post editing toolbar, you'll see this:
<code><stuff></code>
which will look like this in the final post:
<stuff>
The customization was made to:
/blogs/plugins/_quicktags.plugin.php
As proposed by Greg in this feature request, I added two links to reports on the logged-in user's tasks and activities today to the right sidebar. I don't think there's a need for an outstanding tasks link, because they show in red on the regular task list.
Found a much more efficient way to delete comment spam and blacklist its source. If you go into the antispam plugin settings, and add a url from a comment spam to the list, it pulls out all comments which contain that url and offers to delete them en masse. Neat!