Building the right administration interface for every user

WordPress Stockholm meetup group, January 2017

When building websites a lot of work is put into the frontend of the site – with good reason! But often the experience for content editors and site administrators isn’t given as much thought. However WordPress has a wide array of tools to easily make great admin interfaces.

In this talk we’ll take a look at the ecosystem of administration tools available for WordPress, as well as the different types of users that are likely to use the backend of the sites you build.


Migrating a WordPress Site From HTTP to HTTPS with WP-CLI

It’s as easy as:

Take a backup

wp db export

Test rewriting from HTTP to HTTPS

wp search-replace '' '' --dry-run

If everything is looking good, it’s time to rewrite:

wp search-replace '' ''

Some tutorials recommend adding the --skip-columns=guid flag. The train of thought is that old posts will be visible to RSS readers as new ones. I don’t think this is a big problem, and it’s much cleaner to not keep non-SSL urls in your database. It can also cause issues if you are using the GUID field to grab image urls/ids from attachments. (It’s a very popular way of mapping a URL to an attachment ID). With that in mind, I find it’s best to omit this flag.

Disable GitHub API in Composer to improve speed

If you are using GitHub repositories in Composer, you might notice that it takes a long time to run composer update. This is because Composer uses the GitHub API in an effort to improve performance. Unfortunately, GitHub API is very slow and you might need hundreds of calls for a single repo, depending on the number of tags. You can disable this behaviour by specifying the undocumented no-api flag in Composer. In composer.json, add it like this:

    "type": "vcs", 
    "url": "", 
    "no-api" : true 

This will make Composer check out the repository via Git instead, usually improving composer update times by 2-3x.

Discussion on Reddit with more info on the technical details

More information regarding the no-api flag

DiskCryptor and Windows 10 – does it work?


There’s not a lot of information about DiskCryptor and Windows 10 online. Development of DC has stalled a bit but it’s still a very stable and useful piece of software. Here are answers to some common questions:

Does DiskCryptor work with Windows 10?

Yes, DiskCryptor works with all versions of Windows 10 including the Anniversary Update. (At the moment of writing this blog post, the latest build number is 14393 / 1607.)

Does DiskCryptor work with ReFS filesystems?

Yes, DiskCryptor works with ReFS filesystems.

Does DiskCryptor work with storage spaces?

Yes, DiskCryptor works with Windows Storage Spaces. I have also tried to physically move a storage space from one PC to another while encrypted, and it works just fine on the new computer as well.

dc-refs DiskCryptor running on a storage space that uses ReFS.

Does DiskCryptor work with the software RAID in Windows 10?


Can you boot from an ReFS filesystem when using DiskCryptor?

No, but Windows 10 doesn’t support booting from ReFS disks, so it’s not a DC issue.

Will DiskCryptor work when rebooting to do an update?

Generally – yes. Some of the biggest Windows updates (like the Anniversary Update) might give you issues. It rarely leads to a serious problem other than the computer booting into troubleshooting mode and typically you can just reboot again and Windows will revert any attempted updates.

However, fixing this is trivial. Simply decrypt your boot drive first, and then apply the update. You can then encrypt your drive again once the update is installed. Note that this is only required on the boot drive, not any other drives attached to the system. Typically you also don’t have to uninstall the bootloader, but you can do so if you wish via Tools > Config bootloader.

See the required PHP version for all your Composer dependencies

After building a project using Composer, you might ask yourself what the lowest supported PHP version amongst all the included libraries is. The highest number would also be the the minimum version PHP version that the project would run on.

To quickly check this in composer, run this from the project root:

composer show -i -t | grep -o "\-\-\(ext-\|php\).\+" | sort | uniq | cut -d- -f3-

Your output might look something like this:

php >=5.3.0
php >=5.3.9
php ^5.5 || ^7.0
php >=5.5.9

By checking the list of versions, we can see that 5.5.9 would be the lowest PHP version we would need to run this project.

Snippet source