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.
For 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.
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 …
… 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) …
Using 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.
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 …
- 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.
- On the old site/host:
- Get a backup of the WordPress database on the old host, using the host control panel.
- Get a backup of the files on the old host by using FTP.
- I added temporary entries to my \windows\system32\etc\drivers\hosts file to point my domain name to the new host.
- On the new site/host.
- 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.
- Use FTP to upload the files to the new site.
- Use phpMyAdmin to import content from the old database into the new database.
- Test that everything is working OK on the new host.
- Add a new blog post
- Remove (or comment out) the temporary host entries in my \windows\system32\etc\drivers\hosts file.
- With my domain name registrar, change the DNS settings to point to the new hosting provider’s name servers.
- 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.
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.