Hosted WordPress instance for CommBlog

Project Discussion
1

@jasonbrooks from Red Hat’s Open Source Program Office has set up a WordPress instance on OSPO’s WP Engine account. Please test things out at https://fedoracom.wpengine.com and send feedback to Jason and me by 19 July. If everything is working, we’ll try to coordinate a cutover during the last two weeks of July.

A few notes:

  • If you click the Login link on the page, you will get redirected to the existing CommBlog. Go to https://fedoracom.wpengine.com/wp-admin if you want to get to the admin console.
  • If you have any Python scripts that hit the REST API, you will need to specify a custom User-Agent in the request header. WP Engine blocks requests from ‘python-requests/*’, presumably as a bot deterrent.

I’ve done some testing and everything looks good, but I want to get more eyes on it before we make the switch. One thing I noticed is the improved performance: my post counting script runs in 4 seconds versus 30. :slight_smile:

2 Likes
2

I had a quick look around and it looks good :slight_smile: . One thing that does not seems to work is the Jetpack plugins to get the statistics but I guess that just needs some configuration to be done.

2 Likes
3

I connected it to Jetpack. We’ll see what happens when we cut the site over — I’m not sure if Jetpack will recognize that it’s the same site or not. I’ll do a little more research on that.

4

I had a chance to poke around and everything looks good to me.

My only concern is the same as @cverna mentioned. There are four years of page view metrics on the previous site and these are really useful for understanding where we are engaging with readers. If they cannot be migrated, we should find a way to archive this data or keep it alive in another way.

5

Here’s what we heard back:

Jetpack stats are tied to a unique blog ID on our end that’s tied to
the URL of your Jetpack connected site. As long as the domain name is
going to stay the same, you should have no issues.

I would recommend disconnecting Jetpack before you move your site so
we don’t get any temporary URLs confusing things. Then, once the
domain propagation to the new host finishes, reconnect Jetpack.

If for some reason this triggers a new blog ID to be generated after
you reconnect - it would appear on your end that you have zero stats -
just get in touch and we can migrate the stats over to the new ID on
our end.

So it sounds like we’ll be in good shape. I’m going to get this scheduled and will report back here when we do that.

1 Like
6

Super! Thanks for following up here @bcotton. :raised_hands:t2:

7

Update: we’re going to do the final cutover on Tuesday, 30 July from 1500-1600 UTC. The outage should be brief, if visible at all, but if you’re editing during the window, you may lose your work.

1 Like
8

The migration is done and everything looks good. Please let me know if something seems amiss. Thanks to @jasonbrooks and @Misc for their help here. It looks like the site stats didn’t transfer, so I’ll follow up on getting that fixed.

I’ll ask Infra to retire the old instance after Flock to give us time to make sure we’re happy.

2 Likes
9

Thanks @bcotton @jasonbrooks @Misc for taking lead on this! :+1:

2 Likes
10

@bcotton @jasonbrooks @misc Did any of you catch this Akismet error?

Missing API key for Akismet anti-spam comment checker
Missing API key for Akismet anti-spam comment checker929×98 8.8 KB

Currently the spam filter for comments is broken until someone adds a (free) API key for Akismet. I could do this myself but I figured it is better to manage this in a more centralized way if possible. It would help to do this sooner than later if possible, since the comment queue is starting to grow large with spam comments.

Also, for transparency purposes, I just unchecked this option to allow search engines to re-index the new site:

Search Engine Visibility: Search engines now encouraged to index this site (likely disabled during testing)

1 Like
11

Thanks, @jwf, I hadn’t seen that yet. I copied the code from the old instance for now. @jasonbrooks, @misc, do we have a key we use on other sites or should I keep using the old one? I’m not sure who originally created it.

1 Like
12

I am digging deeper into the settings and it seems like the site may not be optimized for SEO either. Google is reporting the CommBlog is not mobile-friendly and it looks like the theme is not rendering correctly on mobile devices:

Failed indexability check on CommBlog Dashboard page

Rendered screenshot from mobile device in Google Search Engine tool
Rendered screenshot from mobile device in Google Search Engine tool412×732 48.4 KB

There is an option to use Ryte.com to analyze the site for more detailed feedback, but it requires tying the CommBlog to a name and email address. This might also be a @jasonbrooks task?

13

Woop, sorry, I didn’t see this message earlier, not sure if I get mail notifcation on discourse :confused: And afaik, we do not have any specific key for akismet, Jason would likely know, or I can take a look tomorrow when I am back at work.

14

The mobile-friendliness seems to have resolved itself: https://search.google.com/test/mobile-friendly?id=ribx-Hk_aaIKlrykgRqT6w

I looked at SEO through web.dev: https://lighthouse-dot-webdotdevsite.appspot.com/lh/html?url=https://communityblog.fedoraproject.org

SEO seems to be good, there’s opportunity for improvement on the accessibility side, though.

1 Like
15

So, we had a few problems with Fedora Magazine and a proxy (cf Issue #8109: Fedora Magazine seems to be down - fedora-infrastructure - Pagure.io ) which requires us to do some potentially disrupting change (aka stop using the proxy setup). Since commblog is also affected (even if no one reported anything), I will need to do the same change.

However, this would requires a transfer of the SSL certificate, and that is causing some issues. While fedoramagazine use a separate domain and certificate, commblog don’t and reuse the wildcard certificate of Fedora. I suspect that while I can get the private key for the first one, I will not get it for the 2nd one for security reasons (I mean, with it, I can pretty much MITM the main mirror and a ton of stuff ).

So there is 2 way out of that:
first

  • we lower the TTL of the domain to 5 minutes
  • we wait until that propagated
  • we switch DNS
    from here, people will see https error due to certificate mismatch.
  • after 5 to 10 minutes, we turn TLS certificate using lets encrypt on WPengine

this will result in a new certificate to be issued and installed.

  • TLS will be valid again

This might cause 5 to 1h of TLS error, and while that’s not critical, I prefer to warn in advance.

To explain why we need to do that is because we have a catch-22. We can’t get automatically a TLS certificate from letsencrypt on wpengine before having DNS pointing to the website. But if we change the DNS, the certificate wouldn’t be valid.

However, we also have 2nd manual option, using DNS and getting a certificate in advance. See the fedora infra ticket for the detail. This is something that would be safe in the sense that there is no disruption until that is ready, but that I never did before.

So that’s still experimental, and I have too much experience to think it will go as smoothly as I explained.

In both case, i do not plan to change anything until next week for the commblog. Since the beta freeze is on the 29, I guess I should avoid that date and do it before if I can ?

16

I’m fine with whatever option works best for the long term. The beta freeze isn’t a big deal for the commblog, so as long as we know what day we’ll do the work, I’ll make sure I don’t schedule any posts (in order to minimize traffic)

1 Like
17

So, I am trying the first part of the migration today (getting a lets encrypt cert on wpengine), but it is taking some time. It also seems that one of the Fedora proxy have been blocked on WPengine, I might have to take this one out of rotation if the SSL migration is not finished in a few hours.

18

So, the plan didn’t worked. So I switched the DNS, and I managed to do it wrongly, so the comblog did disappear from the internet for a while (roughly 30 minutes, from 21h30 UTC to 22h UTC). Now, I hope that the SSL cert is going to work, or I will have to get support again.

19

And … I went to support. So now that’s working fine, SSL is ok, DNS is ok. Please tell if anything is broken.

20

I’d recommend using DNS validation, it’s the easiest way to get that done
without changing anything on the server’s config.