As I write this, we have the WP REST API enabled for 1083 sites across 54 networks on our single installation of WordPress at Washington State University. It’s probably worth noting that this only counts as one active installation in the WordPress.org repository stats. 🙁 It’s definitely worth noting how we use it! 🙂 Our… Continue reading How we’re using the WP REST API at Washington State University
Tag: WSUWP
A Method for Managing Mixed HTTP/HTTPS Sites in Multisite
This is a brief rundown of the method we’re currently using at WSU to manage mixed HTTP/HTTPS configurations in a multi-network WordPress setup. Our assumptions: Sites that are HTTP (HTTPS optional) on the front end should be forced HTTPS in any admin area. Some sites should be forced HTTPS everywhere. This may be because of… Continue reading A Method for Managing Mixed HTTP/HTTPS Sites in Multisite
First thoughts on our new wsu.edu
Today we launched a gorgeous new home page at WSU. For the most part everything went as planned and definitely without catastrophe. We’ll have a full stack write-up at some point soon on web.wsu.edu with more details (still a few more things to launch), but I’ve had a few thoughts throughout the day that I… Continue reading First thoughts on our new wsu.edu
Deployment Workflows, Part 1: The WSUWP Platform
This post is the first in a series of deployment workflows I use to get code into production. Many of my weekdays are spent working on and around the WSUWP Platform, an open source project created to provide a large, multi-network, WordPress based publishing platform for universities. Conceptually, a few things are being provided. First,… Continue reading Deployment Workflows, Part 1: The WSUWP Platform
I’ve been pretty happy over the last couple days with our A+ score at SSL Labs. I almost got discouraged this morning when it was discovered that LinkedIn wasn’t able to pull in the data from our HTTPS links properly when sharing articles.
Their bot, `LinkedInBot/1.0 (compatible; Mozilla/5.0; Jakarta Commons-HttpClient/3.1 +http://www.linkedin.com)`, uses an end of life HTTP client that happens to also be Java based. One of our warnings in the handshake simulation area was that clients using Java Runtime Environment 6u45 did not support 2048 DH params, something that we were using. I’m not entirely sure if LinkedIn has their JRE updated to 6u45, but I’m guessing that anything below that has the same issue.
I generated a new 1024 bit dhparams file to solve the immediate issue and reloaded nginx without changing any other configs. LinkedIn can now ingest our HTTPS links and we still have an A+ score. 🙂