Tag: WSUWP

How we’re using the WP REST API at Washington State University

Posted on by Jeremy Felt

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 primary use for the WP REST API is to share content throughout the University via our WSUWP Content Syndicate plugin. With the simple wsuwp_json shortcode, anyone is able to embed a list of headlines from articles published on news.wsu.edu.

And just by changing the host, I can switch over and embed a couple of recent headlines from web.wsu.edu.

Having the ability to share information across the University is very useful to us. It helps various groups and sites throughout the ecosystem feel more connected as visitors and as site owners.

Of course, we could have used a pre-existing syndication format like RSS as a solution, but a REST API is so much more flexible. It didn’t take much work to extend the initial plugin using things like register_rest_field() to support and display results from the central people directory we have in progress.

That’s me, pulled in from our people API.

This kind of data flexibility is a big part of our vision for the future of the web at WSU. Soon we’ll be able to highlight information for research faculty that may help to connect them with other groups working on similar topics. We’ll have ways to create articles on the edge of the network and have them bubble up through the various layers of the university—department, college, central news. And we’ll be able to start tying data to people in a smarter way so that we can help to make sure voices throughout the university are heard.

And that’s just our first angle! One day I’ll expand on how we see the REST API changing our front end workflow in creative ways.

A Method for Managing Mixed HTTP/HTTPS Sites in Multisite

Posted on by Jeremy Felt

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 form inputs or because it’s a nice thing to do.
  • New domains may not immediately have certificates. We can measure risk and provide brief HTTP admin support—usually with trusted users on a wired network.

To force HTTPS in admin areas, we use the WordPress constant FORCE_SSL_ADMIN. To determine whether this can be enabled, we start with the assumption that it should and then check for a stored option attached to the currently requested domain telling us otherwise.

A bit further down, we use this information to actually set the constant.

This option is managed through our WSUWP TLS plugin, which tracks new domains and allows non server-admins to start the process of CSR generation and certificate upload. Once the domain goes through the entire process and is verified as working, the foo.bar_ssl_disabled option is deleted and admin page loads will be forced to HTTPS.

While the domain is going through this process, it will be accessible via HTTP in the admin, though the cookies generated on other wsu.edu sites will not work as they are flagged as secure. There’s probably some stuff I’m not aware of here, which is another reason to keep this very limited. 😬

Forcing HTTPS everywhere is much easier, as we can redirect all HTTP request for a domain to HTTPS in nginx (or Apache). At that point, we’ll set siteurl and home for the site to HTTPS as well so that WordPress generates HTTPS URLs for everything.

Screen Shot 2015-04-24 at 9.21.18 AM

I love that screenshot.

In a nutshell. Assume all admin requests are HTTPS, but have a config flag that allows you to offer temporary HTTP access. If a domain can be forced HTTPS everywhere, then handle that in the nginx/apache config.

First thoughts on our new wsu.edu

Posted on by Jeremy Felt

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 wanted to note.

Screen Shot 2015-03-24 at 11.24.01 PMWe’re HTTPS only. And that’s pretty freaking cool. It was a year ago today that we flipped the switch on WSU News to SPDY and ever since then I couldn’t wait to get the root domain. I had anticipated some push-back, though I don’t know why, and we haven’t heard a peep. I plan on running a script through a massive list of public university websites to see how many do this. Many don’t even support TLS on the home page, let alone force it.

Screen Shot 2015-03-24 at 11.28.24 PM

Our root domain is on WordPress. Typing that address in for the first time today after everything went live felt really, really cool. I don’t think that feeling is going to wear off. Even though this is site ~600 to launch on our platform, it’s a huge statement that the University is behind us on this. I don’t remember all of our conversations, but I don’t think that having the root on WordPress was really on our radar for the first 2 years. Dig it.

We’re pretty damn fast. That’s become a lot easier these days. But we have a lot of content on the home page—and a really big map—and we still serve the document to the browser super quickly. I actually screwed up pretty big here by microcaching with Nginx at the last minute. It made things even faster, but cached a bad redirect for quite a while. Lessons learned, and we’ll keep tweaking—especially with image optimization, but I love that we went out the gate with such a good looking waterfall.

And as I stormed earlier in my series of “I heart GPL” tweets, every part of our central web is open source. We publish our server provisioning, our WordPress multi-network setup, our brand framework, our themes, and our plugins. 134 repositories and counting. Not everything is pretty enough or documented enough, and will often serve more as an example than as a product. But, everything is out there and we’re sharing and doing our best to talk about it more.

Lots of this makes me happy. More to come! 🙂