Categories
Meta Wordpress WordPress.com

Why self hosted?

This site still runs the latest version of WordPress but the main difference between this site and my old Watirmelon.blog one is this one is self hosted and not on WordPress.com like my old site was since 2006.

“Why self hosted after 14 years?” I hear you ask. I did work for Automattic who runs WordPress.com for over three years and I am a huge fan of its products and platform but there comes a time when long-standing bugs/missing features weigh you down and make you switch away from something you love.

The first bug was a security limitation on all WordPress.com sites whereby you can’t embed any content from another WordPress.com site.

See I want to embed content from my own site in my knowledge base, but on WordPress.com it isn’t possible – and it just silently fails and falls back to sad looking text hyperlink.

An awesome WordPress embed

WordPress.com offers an awesome feature to email new content to subscribers but the inability to change it from anything but immediately was a constant anxiety inducer: if I accidentally hit Publish before being completely ready it would immdiately email 1000+ subscribers with no undo 😕

I now use MailPoet which enables configuration of when to send emails to subscribers – I send an email once a day at 1pm local time if I have created any new content since it was last sent. This alleviates my publish anxiety as I know I have until 1pm each day to fix it before it’s emailed.

I also really wanted to add an automatically generated table of contents to each page in my knowledge base – there was no way to do this on WordPress.com.

One thing I realised by moving to self-hosted is just how much WordPress.com offers without any plugins. I didn’t realise WordPress doesn’t offer in built site stats – that’s a WordPress.com thing.

I try to avoid WordPress plugins since they’re notorious for slowing down your site, however I did end up a small list of handy things that I need:

  1. Akismet Anti-Spam: name says it all 🐷
  2. List Pages Shortcode: to show child pages of a page in a page – just works on WordPress.com
  3. LuckyWP Table of Contents: table of contents
  4. MailPoet 3
  5. Site Kit by Google
  6. SyntaxHighlighter Evolved
  7. Widget Context
  8. Wordfence Security

One thing I can’t do at the moment is automatically publish to Twitter and LinkedIn, but due to my Publish Anxiety anyway I use a manual process for that.

The final question you may ask is why I didn’t use the Business Plan on WordPress.com that allows most plugins and would have solved most of my issues?

This site runs free of ads and creates zero income or revenue for me. The Business Plan would enable some of the features I mentioned above, but it’s AUD$396 per year. My employment income has fallen due to the economic impacts of COVID-19 and I can’t justify that cost when my current managed host costs approx AUD$50 per year to host the same site (8 times less).

Categories
Automattic Wordpress WordPress.com

Finding a home for your content

I’ve been blogging on WordPress.com for over nine years and I’m very happy with my decision to become both a WordPress.com user back then, and a WordPress.com (Automattic) employee in 2015.

Categories
Meta Wordpress

Testing in Production, Oops, No ‘Undo’

Earlier today I accidentally published a test blog post to this site (titled ‘d’) which meant that the ~450 email subscribers to this site would have received that empty blog post via email. I am really sorry about that: I’ll explain below how it happened, and why it shouldn’t happen again.

The way we do testing at WordPress.com is we test new designs and features against ‘production’ backend WordPress sites, which are typically test sites/blogs we have set up under our own WordPress.com user accounts, or test specific accounts we may also use. As with any testing that touches something in production, there’s some risks involved and this morning I accidentally published a test blog post to this WatirMelon site, which I avoid using for testing purposes.

Like many unfortunate events: the reason it happened was a combination of a few different things: I was testing a new mobile editing feature which happened to have an issue where you can’t see the site you are publishing to when you click publish – so I had no visual feedback that I was using this WatirMelon site. I was also using Chrome dev tools to inspect the DOM at the time, and I thought it was in select mode, when it actually wasn’t – the Chrome UI doesn’t differentiate these modes very well. Finally, clicking publish on WordPress.com is (currently) an irreversible action: as soon as I clicked it I realised I had stuffed up but had no way to undo my actions: the emails were sent, it was too late.

I have been advocating internally an option that allows a grace period to undo the publication of a post or page, similar to GMail’s life saving ‘undo send’ feature, for some time, and I recently raised this as a public WordPress.com enhancement request.

This is to address the ‘publish anxiety’ I have (and I imagine many others also have) knowing that clicking a single button is irreversible.

Allowing user actions to be undone, or emphasising ones that are irreversible, is part of Jakob Nielson’s classic 10 usability heuristics.

User control and freedom: users often choose system functions by mistake and will need a clearly marked “emergency exit” to leave the unwanted state without having to go through an extended dialogue. Support undo and redo.

In the meantime, I wrote a GreaseMonkey/TamperoMonkey UserScript that offers an additional confirmation dialog box when clicking “Publish” on WordPress.com. This extra step should be enough to stop me accidentally clicking Publish like I did today and clogging your inboxes with junk.

My UserScript is available as a Gist if you’re interested in it.

And sorry again.

Categories
Automated Acceptance Testing Automated Testing Automattic WebDriver Wordpress

Running Automated Tests with A/B Testing

Like a lot of modern, data driven sites, WordPress.com uses A/B testing extensively to introduce new features. These tests may be as simple as a label change or as complex as changing the entire sign up flow, for example by offering a free trial.

Since I have been working on a set of automated end-to-end tests for WordPress.com, I have found A/B testing to be problematic for automated testing on this very fast moving codebase, namely:

  1. Automated tests need to be deterministic: having a randomised experiment as an A/B test means the first test run may get an entirely different sign up flow than a second test run which is very hard to automate; and
  2. Automated tests need to know which experiments are running otherwise they may encounter unexpected behaviour randomly.

What we need is two methods to deal with A/B tests when running automated tests:

  1. We need to be able to see which A/B tests are active and compare this to a known list of expected A/B tests – so that we don’t suddenly encounter some unexpected/random behaviour for some of our test runs
  2. We need to be able to set the desired behaviour to the control group so that are our tests are deterministic.

Different sites conduct A/B testing using different tools and approaches, WordPress.com uses HTML5 local storage to set which A/B tests are active and which group the user belongs to.

Luckily it’s easy to read and update local storage using WebDriver and JavaScript. This means our approach is to:

  1. Each time a page object is initialised, there is a call on the base page model that checks the A/B tests that are active using something like return window.localStorage.ABTests; and then compares this to the known list of A/B tests which are checked in as a config item. This fails the test if there’s a new A/B test introduced that isn’t in the list of known tests. This is better than not knowing about the A/B test and failing based upon some non-deterministic behaviour.
  2. When a new A/B test is introduced and we wish to ensure our automated tests always use the control group, we can set this using a similar method window.localStorage.setItem('ABTests','{"flow":"default"}'); and refresh the page.

Ideally it would be good to know and plan every A/B test for our automated e2e tests, but since this isn’t possible, checking against known A/B tests and ensuring control groups are set means our automated tests are at least more consistent and deterministic, and fail a lot faster and more consistently when a new A/B test has been introduced.

How do you deal with non-determinism with A/B tests?