Preparing for 2017

As we the end of the year draws close, and we look ahead to the coming year, it is time to assess where we are at and where we are going.

The past six months have been challenging – new server equipment, moving the server hardware to a new hosting location, new ISP, and dealing with physical issues (one of which is ongoing.) We have just upgraded to the latest stable release of WordPress, and a dozen or so of the opensource and commercial plugins, themes, etc. We have added a Piwik server for counties which wish to monitor their site traffic, and increased storage for all sites dramatically.

In the next six months we hope to add an installation of WebTrees, a collaborative genealogy presentation and management software, and an authentication platform which will work across our primary services (but has yet to be determined.)

Another security update…

There has been another security update, so here is a brief run-down (this one is simpler than the previous one:)

What we did about it

We have installed the upgrade, which updated the two third-party libraries which had newly-discovered vulnerabilities.

What the vulnerability was

There were two, separate, vulnerabilities; both were in third-party tools used in WordPress.

The first issue was in Plupload, a tool used for managing file uploads, which in certain circumstances could allow a remote person to perform actions on the site which the user did not initiate. This is called a Same Origin Method Execution (SOME) vulnerability. In this case other security measures in WordPress limited the risk, and it only affected the 4.5.1 release, therefore not a high-profile (but still high-priority) issue.

The second issue was in MediaElement.js, a tool used in WordPress to stream audio and video content through WordPress syntax. This was Cross-Site Scripting (XSS) vulnerability, and there was little mitigation of the risk, and so both a high-profile and high-priority issue. Effectively a maliciously formed url could be fed into the javascript and the remote person could execute code on the server.

What this means for you

Nothing, as far as we are aware. The issues are completely fixed.

However, it exposed that WordPress is not strictly using HTML5 audio and video. Everyone on the internet should be using a modern browser which supports HTML5; there are inherent risks to older browsers which simply cannot prevent certain types of internet security and privacy attacks which have been resolved in newer browsers. By supporting old, vulnerable browsers (by using MediaElement.js) WordPress is enabling users to continue being at risk rather than encouraging them to update/upgrade.

Upgrades and vulnerabilities

WordPress released a recent upgrade to address a security issue[1], and also warned operators of servers using ImageMagick of security issues possible when processing insecure images[2].

What we did about it has upgraded to the current stable version (we always do, usually within minutes of the release.) We have also addressed the so-called “ImageTragick”[3] vulnerability in the ways currently suggested by the ImageMagick developers. But, just for your own peace of mind (and ours!), please ensure that your regional site does not allow users, forum posters, or commentors to upload photos. Also, please do not ‘upload’ images using urls as this is another vector for this exploit to be used. If you are using the PressThis tool to republish articles from the internet, this is another way to infect your site.

What the vulnerability was

The issue addressed by WordPress potentially allowed someone to run a script in a visitor’s browser when displaying/streaming certain kinds of media. Obviously could not directly affect your website, but it could get your site blacklisted as a source of malicious scripts even though it wasn’t really your site doing the harm to the visitor. This is completely fixed by the security update.

The issue with ImageMagick potentially allowed remote code execution (RCE) on the server. When images are used in WordPress they are processed in various ways using ImageMagick – to create thumbnails, or change a photo’s dimensions, or in other ways – and during that processing ImageMagick could be convinced to execute instructions on the server. This could in theory do almost anything the webserver has the ability to do, including severely harming your site or the webserver itself. This is not completely fixed by the security update from ImageMagick, and so the vulnerable portions of ImageMagick have been disabled. Most likely this will not affect your site, but be aware of possible issues if you use .svg or .mvg graphics. There are known attempts to use this exploit in the wild, but sites should no longer be vulnerable.

What this means for you

Nothing, as far as we are aware. When a more-complete fix for ImageMagick is available we will re-enable the possibly vulnerable portions again. In the meantime, if you have any issues with any media on your site (especially media which do not resize correctly) please use the secure contact form to get in touch with us immediately.

[1] WordPress 4.5.2 Security Release
[2] ImagMagick Vulnerability Information
[3] ImageTragick

Unexpected downtime / server upgrades

Well, it’s always frustrating when there is unplanned server downtime.

Today we upgraded the operating server operating system, and most of the server stack as well. This was expected to be a relatively brief outage after making backups of everything. Unfortunately the system upgrade took more than two hours, and another stretch of time for the 800+ packages involved. There are still a couple of sites offline awaiting non-essential manual over-rides.

For which I am deeply apologetic. I plan to address this over the next couple of weeks, developing an alternative model for system upgrades.

Slider captcha

Captchas are attempts to identify automated processes to keep them from abusing resources. The most common abuse of CMSes is spam – in comments, in forums, in usernames… if you can think of it, it has probably been tried as a method of spamming people.

Many of the methods used to combat spam are also problematic. One of the most common tools on the web is reCaptcha, a “free service” provided by Google. Like everything “free” on the internet, you are the product being sold. Google uses captcha to A) spy on your users, B) get them to ‘solve’ a problem (like identifying street signs) which they then use to improve their mapping software and data. In the past they ‘borrowed’ computer cycles to work on distributed computing problems, and they may do that again in the future. Other ‘free’ captcha services have had similar histories of privacy invasion and/or bandwidth/cpu theft. has limited bandwidth and storage, and encourages all County Coordinators to use methods to avoid spam and related abuses. CCs are encouraged to register an Akismet account and enable Akismet anti-spam, even though this gives some access to spy on visitors. They are also encouraged to use a captcha for at least registration and login, but preferably not a known bad-actor like Google’s reCaptcha. (The site uses Slider Captcha, which as far as we know does not involve any spyware.)


One of our hosted sites, Marshall County Minnesota, is building a collation of Obituaries.

from Nashville Funeral and Cremation
from Nashville Funeral and Cremation

This is an interesting idea, but it really isn’t the best way to do this job.

The USGenWeb Project has a range of archive efforts underway, including an Obituary Project. The Minnesota page of the obits project includes a Marshall county page, which includes links to a collection of obituary text files. Assuming this site has a good history of resilience and has a back-up plan/system in place, this is where the obituaries should be collected.

However, such archives should likely be made available via a standardized API allowing multi-modal CRUD. The Archives Project of USGenWeb is static.

So, until a better option is made available, Marshall County can (and should) continue to host these obituaries any way that works for that county.

Surnames: Forums versus contact lists

from Commons.Wikimedia.Org
from Commons.Wikimedia.Org

We have all come across them – a list of people who are all researching the same surname as you are. Excitement! Compatriots! Cousins! You click on a name and up pops your e-mail client, and you feverishly type away a quick note of introduction, explaining where you found their e-mail address and your shared interest in the ‘Doe’ surname, and send it off with a flourish. On to the next name in the list!

And in a few seconds you get a notification from a mail server explaining that it cannot deliver the e-mail because the [inbox is full/e-mail address not found/account is inactive]. Or fill in the blank. And the same is true for all, or most, of the names on the list you found.

There are a few ways around this. One is, as a regional coordinator, to use a forum, rather than an e-mail contact list, because then a question asked and answered is available to many other people to find. And asking the question once may have many people view the question, increasing the chance of an answer being found.

A problem with forums is: people need to visit them to see the questions. So if you have a forum, you need to advertise it – hopefully on every page of your site!

And you need to use it. An active forum, where things are regularly changing and updated, questions answered accurately, will convince people to ‘sign up’ for receiving e-mail notifications of new topics. Or to add a ‘feed’ to their news browsers. Or just to stop by regularly. Your forum needs to become a valuable resource to people.

But the nice thing about that is – as it becomes valuable, more people will become involved, which makes it more valuable yet!

bbPress logo
bbPress logo of course supports forums. Right now we have the WP ‘bbPress’ forum enabled, but there are other forum integration options as well. Do you have a preferred forum software? there’s probably a way to run that on

Geolocating your rural cemetery for the world

Working with old cemeteries and burials, online or on the ground, often means trying to explain to others where, exactly, it is located.

Google’s maps have become the number-one goto resource for all things geolocated; to find restaurants, parking spots, even the faster route during morning rush hour. But it is woefully under-representing small cemeteries in the countryside. Sure, you can drop a location pin and create a map or list of directions – but that’s like marking an X on a paper map: it only exists on that one map, and only you and maybe the person you shared the url with know what it means.

Enter OpenStreetMap.Org.

On OpenStreetMap.Org (OSM) you can add your cemetery’s information to the database, or edit it if someone already did (and maybe got a detail or two wrong.) You can mark a point (such as the location of the church or chapel), or a line (like the road between sections), or an area (for example, the outline of the entire cemetery, or a section within the cemetery, or even a single grave plot.)

As soon as you save your edit, you can look at it on the map – it still hasn’t been shared around the world yet, but it will be over the next hours. And, once you can look at it, you can create an image of it, or you can create a url to share your map point, or you can create a blob of html to embed the map in your web page.

SVG map generated by OpenStreetMap.Org
SVG map generated by OpenStreetMap.Org

Now, here comes the magic: when I created the entries for St. John’s church and cemetery, Google Maps just had the church. Now Google displays a green field for the cemetery, and will probably soon have a name on that green field. Mapquest had nothing, but now has the church and cemetery. Bing, Yahoo!, and all the other search engines with maps will soon, if not already, have the name of the cemetery and its location in their database. And the spiders now search for mentions of St. John’s Catholic Cemetery near Argyle, MN, so the Marshall County page will become higher-ranked and appear in more search results.

Creating a regional coordination page on is set up primarily for the purpose of hosting regional coordination pages like the County Coordination sites of the state-level organizations of The USGenWeb Project. And it does so using the open-source WordPress software.

WordPress is popularly known as one of the, if not the, pre-emminent blogging platforms. But a regional coordination site is not a blog, in fact almost nothing like a blog! Yes, and no.


The software is actually a content management system (CMS), an application for publishing, modifying, organizing, deleting, and curating all kinds of content and media on the internet. It also offers tools to support collaboration in doing so. Although they are intended to avoid the need for hand-coding html, CMSes may also facilitate writing code by hand.

One of the ways a CMS reduces the amount of html-writing is with reusable templates, so you can focus on writing what goes into a page rather than putting most of your effort into creating what each page looks like. With WordPress specifically, every page loads with a similar look-and-feel with some variations for type of page content and depending on the specific ‘theme’ you select.

wordpress-logo-simplified-rgbWordPress, while it is a great blog, also lets you display a ‘static’ page instead of a blog when visitors first arrive at the site. You can edit this page within the same editing environment used for writing blog entries. This editor lets you choose either a WYSIWYG view (Visual), or a source code view of the almost-raw html code (Text).  And you can flip between the two views with a mouse click. Now the magic of this static page is that it, too, is displayed inside that look-and-feel template, allowing you to add the USGenWeb and state project logos and links to every page in your site.

The step-by-step process

Once you have your account and domain, the steps are extremely simple.

  1. Create your landing page.
  2. Tell WordPress to use it as your static page.
Create the page

Go to your site’s Dashboard, which is the control panel for site administrators. Select Pages from the left sidebar, and then Add New to create a new page. (Normally we abbreviate this as Dashboard->Pages->Add New. Less typing for me, and I am lazy.) This brings up the page editor, with two primary editing fields – the title field and the larger body field which has several editing toolbars above it.

Enter the title you wish to use for your landing page; Welcome or the name of your region are pretty good choices to start.

In the body field you can do almost anything you like to create your new home page. The editing toolbars are self-explaining, for the most part. Use the ‘Preview’ button in the right side-bar to load a new tab with exactly how it will look for your guests (minus that top toolbar – guests don’t get that.) You can change this at any time, so for now just throw some text up there as a place holder – LOREM IPSEM…

Now save it by using the ‘Publish’ button in the right side-bar. The page is now published on the internet. But it is not your landing page, yet.

Tell WordPress to use it

Once you have the page how you want it, hit the publish button in the right sidebar. This page is now available on the internet! but it is not your landing page yet.

Go to Dashboard->Settings->Reading. The top item is ‘Front page displays’. Click the radio button beside ‘A static page (select below)’. Select the page you just created from the ‘Front page’ drop-down menu. Then click the ‘save changes’ button.

Voilà! your visitors will now be landing on the page you created! BUT – what about the posts? Most of us will still want to use WordPress’s blog abilities to make announcements, report news or events, or even to keep subscribers organized. Create another page – and it can be just a title and no body – and go back to Dashboard->Settings->Reading, select the ‘Posts’ drop-down menu, and select this new page, and save changes again.

You will probably want to add a link to your new Posts page from your new Front page, but that is another how-to article at a later date.


By creating a static page for WordPress you magically turn a blogging software into a website management software, and you can still blog on it. Using the WordPress ‘themes’ you can focus time tweaking your ‘look’ once, and it will be applied everywhere all the time. With WordPress you can arbitrarily add pages filled with your own html code, or you edit from a WYSIWYG editor view.

But don’t start dreaming up menus and sidebars yet – because WordPress has that all covered for you, and makes it so easy you won’t believe it.

Registration is (slightly) broken

Always fun to find something not working in a new system!

WordPress simplified logo, from WordPress.Org
WordPress simplified logo, from WordPress.Org

Apparently newly registered users – the ones who do not have a website created for them – are linked inappropriately to an administrator profile when logged in. This means the handy link in the upper-right corner of the logged-in views does not work for them, and they may get “you do not have permission”-type errors if they follow that link.

The best link to a user’s profile page is http://[projectname.][yourusername], which unfortunately is not displayed anywhere except on a forum topic to which you replied. This is not optimal! but it does work.