App failure

As a software developer I well know that software and information systems can have bugs. But it still astonishes me when software from big companies that is being used thousands of times each day across the world has egregious errors.

For example, look at this screenshot from the Malaysian Airlines iPhone app, where the top of the screen has a prominent and scary message about there being no e-mail address provided, while the bottom of the screen has a notification that an e-mail has just been sent to the address which is supposedly not available. And yes, an e-mail was received.


Salesforce Summer ’19 issue with ADFS single sign on

This is a work related techie blog post for the benefit of others who may experience the same problem.

We have a production Salesforce Org and a number of sandbox Orgs, all set up with a Salesforce “My Domain” and configured to use Single Sign On authenticating against Microsoft ADFS. On the weekend, after our sandbox Orgs got upgraded to the Summer ’19 release, we were unable to login to any of our sandboxes using Single Sign On. We were just getting a very unhelpful “An error occurred” message on the sign-in screen.

Comparing the Single Sign On settings in our Production Org (which was still working), I noticed that where the “Login URL” SAML endpoint used to have an “so=OrgID” parameter, this was now gone in the updated sandboxes. Jumping on to our ADFS management console, and editing the relevant Relying Party Trust to remove the “so=OrgID” parameter from the Endpoint was all that was needed to fix the problem.

Curiously, when I checked the release notes for the Summer ’19 update (which is 480 pages long!), there appears to be no mention of this change in Single Sign In configuration.

Production (not yet updated to Summer ’19) had an “so=” parameter in the Login URL SAML endpoint
Sandboxes that had been updated to Summer ’19 release did not have the “so=” parameter in the Login URL SAML endpoint
Removing the “so=OrgID” parameter in the ADFS settings fixed the sign in problem.


I have a grand (and probably unattainable) dream of inventing a word that will make its way into widespread usage in the English speaking world. I’ve tried with “unvaporia”, “shufflendipity”, “unprivacy”, “undergommed”, “disagreeaphobia”, “eco-busted”, “optionitis”, and “misambulist”.

I’m now having a try with …

accusurance. noun. A word or phrase that can either be an accusation or a reassurance, depending on the tone of voice you use.

As an example, in Microsoft SharePoint 2013 and later, if you initiate an action that doesn’t complete immediately you get told that the system is “Working on it …” along with the reassuring message that “This shouldn’t take long.”

Usually it doesn’t take long, but sometimes it does. Sometimes it drags on interminably, and leads to an accusatory response by the user of “This shouldn’t take long!”

Another example of accusurance is the phrase “nice one”, which can either mean a reassuring and gentle expression of appreciation, or a sarcastic accusation of having f***ed up.

Firefox 41 and the New Tab override

firefoxFor years Firefox has been my preferred browser. When I open a new tab I like to have it open to a custom page on my local drive rather than the standard Firefox new tab page. I was able to configure this using the “browser.newtab.url” setting available in the “about:config” page.

As of today, with the release of Firefox version 41, for security reasons this setting is no longer supported. Fortunately there is a New Tab Override add-on that can be installed to provide the same facility.


Holden MyLink and the cover art conundrum

My Holden car has a MyLink music system with a colour display in the console. One of the things it does is show the cover art of MP3 tracks as it plays them from an attached device. It seems that it gets the cover art from an embedded database of coverart (sourced from GraceNote) or from the MP3 file itself.

I put together a USB drive with my favourite MP3 tracks, but the conundrum was that for some tracks, the cover art would display correctly, and for other tracks, a generic image (based on the track’s genre) would display. There seemed to be no rhyme or reason why some would work and others not work, as most of the tracks had cover art embedded  in the file.

This weekend curiosity got the better of me. Using the TagInspector ID3 editing program I observed the pattern that tracks where the cover art image DID display, had the text encoding of the APIC frame set to ISO8859_1 …

ID3ISO… whereas all the tracks that DIDN’T display the cover art had the text encoding of the APIC frame set to UTF_16_BOM (Unicode) …

ID3UTFUsing the UltraID3Lib library I did a test by changing the text encoding of a track with UTF_16_BOM over to the ISO8859_1 encoding. After doing this, the cover art displayed correctly on the MyLink system. What’s curious about this is the encoding value is the text encoding of the Description field of the image (not the encoding of the image). The text description of the image isn’t displayed at all by the MyLink system, so it’s kind of odd that the encoding type of the text field would prevent the display of the image.

A short bit of coding later and I had a utility that changed the text encoding on the APIC frame of all my MP3’s that I play in the car, and the cover art conundrum is closed.


Migrating WordPress

More for my own benefit than for anyone else, in case I need to do it again, these are the steps I used in migrating my web site from one hosting provider to another, keeping the same domain name. In practice it was a bit more bothersome than what’s described below, as I took a few wrong paths and had to backtrack. The two pages that I found useful in doing the migration were …

In summary, the steps I took were …

  1. Sign up with a new hosting provider, choosing the option to use an existing domain and configure DNS to point to the new site when ready.
  2. On the old site/host:
    1. Get a backup of the WordPress database on the old host, using the host control panel.
    2. Get a backup of the files on the old host by using FTP.
  3. I added temporary entries to my \windows\system32\etc\drivers\hosts file to point my domain name to the new host.
  4. On the new site/host.
    1. Create a new MySQL database, with the same name, user, password as on the old site. All the details I needed were in the “wp-config.php” file in the root directory.
    2. Use FTP to upload the files to the new site.
    3. Use phpMyAdmin to import content from the old database into the new database.
    4. Test that everything is working OK on the new host.
    5. Add a new blog post
  5. Remove (or comment out) the temporary host entries in my \windows\system32\etc\drivers\hosts file.
  6. With my domain name registrar, change the DNS settings to point to the new hosting provider’s name servers.
  7. Wait for the new site (with its new blog post) to appear when the DNS change has propagated. (The domain registrar page suggested that this can take up to 48 hours, in my case I made the change about 8pm one night, and it had propagated by the time I got up the next morning.)

One minor obstacle I had in attempting this migration was that after uploading the content to the new server in step 4 above, the front page of the site was working OK, but clicking on any links to content elsewhere resulted in a “404 not found” error.

It turned out that in step 4.B above, when I was uploading the website files, I didn’t upload all the files in the root directory, as I knew that some of them were specific to the old server not the new server. e.g. files like the error log, or config files for the fantastico installer. I got this mostly right but unfortunately one of the files that I thought I didn’t need to upload was “.htaccess” – but as this forum article steered me straight – it is needed. After uploading the “.htaccess” file, the site sprang to life as it should have.

UPDATE 06-Jun-2014

For another WordPress site where I wanted to create a copy of the site for dev/test purposes I used the Duplicator plugin, which was pretty straightforward.

Goodbye Windows XP

WindowsXPWallpaperToday, 8th April 2014, Microsoft stops support for Windows XP, which is a bit sad. I always had a fondness for Windows XP, being the first decent, stable, consumer operating system from Microsoft. Over time I even got used to the Teletubby themed default wallpaper. I still have 2 PC’s at home running Windows XP and for what they do (basic web browsing, looking at photo’s, watching TV) the OS performs as well now as it did when it was released.

I really don’t want to upgrade to Windows 8, and the hardware on those PC’s would struggle with Windows 8 anyway, so I’m still undecided whether to retire them, replace them, or upgrade them.

WordPress wp-events plugin breaking the dashboard

I run a WordPress based website that uses the wp-events plugin to manage a calendar of events. It’s been mostly working well, but recently after some update of WordPress, and I’m not sure which one, I found that on the Dashboard page of my WordPress site that I wasn’t able to toggle the various modules to expand or collapse them.  By a process of trial and error and comparing a few different WordPress sites that I have access to I found that the problem was the wp-events plugin – if I deactivated the plugin my problem on the dashboard page went away.

Unfortunately the wp-events plugin is no longer actively maintained, the author having moved on to other things, so I decided to see if I could locate/fix the problem.

Be warned – although I am an experienced programmer, I am a complete newbie in the world of WordPress plugin development, so there’s no guarantee that my ‘fix’ below won’t do really bad things.

Anyway, again by a process of trial and error, commenting out various bits of the plugin code I found that commenting out a single line of code in the wp-events-functions.php file fixed the problem …

function events_editor_admin_init() {
#  wp_enqueue_script('post');

After making this change, deactivating and reactivating the plugin, my dashboard was working again, and the events plugin appears to be working the same as before.

Conjecture mode ON

As far as I can tell this function is including a link to a script file in the page for the purpose of enabling rich text functionality in the event editor form, but I suspect that some update to WordPress made linking to this script redundant, and worse made it break stuff because different scripts were being loaded in the wrong order

Conjecture mode OFF