Figuring out how to serve many SSL certificates, part 2.

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. :)

Figuring out how to serve many SSL certificates, part 1.

In the process of figuring out how to configure SSL certificates for hundreds (maybe thousands) of domains in a single nginx configuration without a wildcard certificate, I decided it would be cool to use `server_name` as a variable in the nginx configuration:

`ssl_certificate /etc/nginx/ssl/$server_name.crt;`

Unfortunately, per this aptly named request on Server Fault—nginx use $server_name on ssl_certificate path—that’s not allowed.

Nginx docs explain it more:

Variables are evaluated in the run-time during the processing of each request, so they are rather costly compared to plain static configuration.

So with that, I’m going to have to generate a bunch of `server {}` blocks that point to the correct certificate and key files before including a common config. I can’t find any examples of this yet, so I’m still wondering if there’s a better way.

I’m about to create a repository named something like WSUWP-P2-Common that contains all common P2 related plugins and/or themes for use throughout the WSUWP ecosystem.

It’s purpose will be more of a built package rather than a development area. Development will still occur in individual repositories. When releases are pushed in those repositories, they can be deployed to the central package repository as well.

I feel like I’m reinventing the wheel though and that if I understood Composer enough, I could use that. But then part of me doesn’t care if I’m reinventing the wheel because it will just work with our current deploy process without much effort.

I also wonder if this is better of as a private repository. I guess if we run into a plugin that isn’t GPL compatible for some reason, we can create a separate repository for WSUWP-P2-Common-Private, but I’m hoping that isn’t the case.

If this works as a model, we’ll likely have other “package” repos in the near future for other sites.

#5367 WordPress Cookie Authentication Vulnerability

#5367 WordPress Cookie Authentication Vulnerability takes us back to when the modern password handling in WordPress was born, partially due to a vulnerability report at the time. More because we were ready for it.  It’s great to read through and watch decisions being made as familiarity grew.

In that thread, Matt links to the changeset that brought us from plain text passwords to hashed passwords for the first time.

2013-07-07 14.15.17

v1.1 of Varying Vagrant Vagrants has been pushed

This is a smaller release in the grand scheme of things, though the first (!) as a new organization. The milestone has been ready for several weeks now. Thanks goes to Aaron Jorbin for prodding it along. :)

Quite a bit has been stable since v1.0, so we’re in a good spot to make a couple big changes in the next release including PHP 5.5.

From the changelog:

  • Transition to Varying Vagrant Vagrants organization.
  • Add a CONTRIBUTING document.
  • Add --allow-root to all wp-cli calls in VVV core.
  • Use a new global composer configuration.
  • Add zip as a package during provisioning.
  • Introduce a helpful caveats section.
  • Remove tcp_nodelay config in Nginx. Reasoning in 0cce79501.

As always, feel free to stop by and open an issue if there’s something you’d like to see!

DSCN6618

A Varying Vagrant Vagrants Organization

This is a very transformative moment for the Varying Vagrant Vagrants project.

About a week ago, I reached out to Jake with a proposal to move VVV from under the wing of 10up to an organization of its own. We’ve been cruising along for just over a year, have around 125 unique visitors on the repository a day, and have a nice regular community of contributors. We have received pull requests from just around 40 contributors (!!!) and the issues are constantly a lively place of discussion.

Jake immediately agreed and we were able to talk through the process and the future very quickly. 10up has been a gracious and excellent host for VVV this entire time—the farewell post is great—and I’m looking forward to future steps we can take as a community now that we’re on our own.

I’d like to think that the goal to bring Vagrant to the forefront of WordPress developers’ minds has been accomplished. Through VVV and other related projects, the use of a development environment that closely matches production has come a long way.

I do think that VVV is the best tool out there for contributing to WordPress core. We provide stable, trunk, and develop versions of WordPress and everything needed to run the Grunt build tools and PHPUnit unit tests.

With that in mind, I think we should be able to line up a few goals.

  1. Continue being the place for a WordPress core development environment. This primarily means that we stay on top of the tools that core introduces into the development flow. Providing an approachable way to use these tools and documentation will go a long way.
  2. Directly related to goal one, some of the advancements we make should be around testing multiple versions of everything. If we can make it easy to fire up a PHP 5.x environment and test Nginx or Apache with WordPress 3.x or 4.x, that would be amazing.
  3. VVV has an excellent method for auto site setups. Over time we’ve had some nice demand for a few that could help quite a bit. It would be great to see a couple that provide basic setups for WordPress multisite and WordPress under Apache rather than our default of Nginx.
  4. Bring other tools to the forefront of WordPress developers’ minds. It may be great to see versions of VVV that harness Salt, Puppet, or Chef rather than the bash scripting that we’ve forced upon the project so far. VVV has an opportunity to be a learning tool for all of us in exploring methods of testing, provisioning, and deployment.

Right.

So please chime in with any suggestions that you may have. I’d love to toss the keys to a few new repositories over to anybody that’s interested in building out new tools. Feel free to use the main VVV repository under the Varying Vagrant Vagrants organization to open an issue and discuss your thoughts. We can split things off as needed.

Over time we’ll get more organized and setup a more official forum for discussions as well as some contributing guidelines. I’m going to reach out to a few regular contributors and get them added as committers. We also need to spend some time with licensing to see if we can get away with GPL for everything or if another would be more applicable to the work that we’re doing.

That’s that. Thank you all for being so great. Here’s to the next year of VVV. :)

20131005-IMG_0059

Thoughts on Contributing to WordPress Core

I was an early user of WordPress in the grand timeline of events.

Officially, my first long term installation was WordPress 1.5 in 2005. That site was a chronicle of my dad’s bicycle ride across the country and has been running continuously for about 9 years. It was even “0wn3d” at some point by hackers when I didn’t upgrade and I had some cleaning up to do.

The other day I upgraded this same installation from 3.4.1 to 3.8 and had no troubles at all. That made me happy.

I don’t remember giving much of a thought to contributing for many years. I created many various blogs using WordPress and hunted the Internet for things I could add.

I used Matt’s blog to figure out asides. I created themes with the fancy CSS. I thought BackPress was the future!

It took me until 2009 to register for my first plugin while I joined the excitement around rssCloud. Joseph Scott beat me to it and I never actually populated the repo. :)

I like to think of this as the “They” period.

They released an update. They should include this feature. They make it easy to have a blog.

In 2011 I quit my 12 year career, we travelled around Europe a bit, and then landed in Portland. Without a job—and without knowing the first thing about freelancing—I decided that I should attend that year’s WordCamp.

Mostly because it was only $20 and lunch was included.

The addiction hit pretty hard once I got a sense of the community. For all the grief that unconference sessions can sometimes get, they were amazing for me.

We stood around in a group with Joey and discussed developer challenges and solutions. I started talking about deployment with Zack, a concept we’re still trying to solve today. I watched a fascinating Nacin explain WP Query to a room full of developers. I got lunch!

Hooked.

I quickly started in on my plugins. All about data portability, I made one for YouTube and for Instapaper. A fantastic automatic featured image post creator that the blackhat community LOVES. A way to set the posts per page value for any type of page view. I started following more of the WordPress community, absorbing all the information I could get.

You could call this the “Outsider” period.

I wasn’t necessarily referring to the WordPress project as “They” any longer, but I wasn’t entirely familiar with the goings on. While the community was absolutely approachable at WordCamp, things suddenly seem so different without faces in an online place where everybody else knows what they’re doing.

Hint… that last sentence couldn’t be less true. ;)

In December of 2011, Zack did some great convincing on two sides. I gave in to being bad at freelancing, applied for a full time job with 10up, and Jake saw enough to take me on.

Things changed quick as I was thrust into the world of WordPress full time.

My immediate charge was to build the new UniversalSports site from scratch over the next few months to be hosted on WordPress.com VIP. I learned so much during this period through building and failing and code reviewing and everything.

And the “We” period began.

They” switched to “We” inside my head and I became a community member. I paid attention to dev chats for the most part. I read code. I planned out what WordCamps I wanted to attend and started thinking of topics to speak on.

While helping Helen troubleshoot an issue with one of her client sites, we stumbled on a mistyped character in some oEmbed code. I frantically created a ticket and a patch with her guidance, worried the entire time that all of the people who already know all the answers were going to come in and fix it before I had the chance.

But that doesn’t happen. There’s always a place to contribute. Nobody comes out to bite when you create a ticket, nobody slaps your code down. In fact, the community loves when a new face appears on Trac with any type of activity.

The patch was eventually committed and I felt amazing. On the contributors list for 3.4!

Freaking stellar.

This is where the train starts moving. Once I was past that hurdle, a whole new world opened up. I wanted to contribute!

But finding a place still seemed so hard!

Becoming a Contributor.

I’m going to shift gears a bit, because this story is so long and there’s so much more to tell. The rest is a natural continuation summed up into what I think you should take away from this.

Types of patches in Jeremy’s perceived order of difficulty:

  1. In the process of developing X, I found this quick Y. This is what my first patch came from. While not working directly on WordPress core, something came up. When investigated, it turned out to be a bug. Once character patch, good to go. The best thing that can be done to create patches for WordPress core is to spend time in WordPress core.
  2. I want to fix a bug. There are many, many things in WordPress waiting to be fixed that only need attention. This involves finding a place you’re interested in and testing. If you can reproduce a reported issue, you’re more than half way to a solution.
  3. I want to introduce this enhancement. There isn’t a bug around this issue, but it’s something you think should be added. Open a ticket, make your case, stay on top of it, and be prepared to wait. Don’t avoid voicing an opinion. Don’t avoid creating a patch as a proof of concept.
  4. X is broken and needs to be overhauled. You’re an addict now. And in reality, this is a combination of the first 3 types. Be prepared for the long haul as this isn’t a one day deal. Commit to being involved with the conversation for months and years. In the process, you’ll come across plenty of the first 3 on this list to keep you in the release notes. ;)

Of course, patches very much aren’t everything. I only lead with that because code is usually my focus. Commenting, testing, and sorting tickets make up the majority of work done when making progress as a community.

Types of Trac activity in Jeremy’s perceived order of difficulty:

  1. Comment. Go to Trac, find a ticket, and voice your thoughts. This can be a “+1″ or a “-1″ or an epic tale of how the extra padding on a button feels weird.
  2. Testing. Patches are only as good as the testing that was done on them. So many things often end up stuck only because more testing is needed. Go through the process of downloading and applying the patch to trunk. Ask for help if you need it. And test!
  3. Sorting. Over time, you’ll become more and more familiar with how Trac is organized. As things are created, they need to be filed with proper components and milestones and such. After commenting and participating you’ll wake up one day to find that you’ve been given Bug Gardener status. Now you can help in the due diligence of sorting tickets. Woot!

And one more list. No perceived order of difficulty.

  1. Cultural and language hurdles. Communication via text can be tough. It’s so hard to convey emotion and so easy to read into things that aren’t things at all. Read anything you come across as if it was said with a pleasant tone. Nuances in the English language are hard enough for native speakers and we’re a worldwide community!
  2. Uncommitted patches are not a waste of time. I would be surprised if the number of uncommitted patches on Trac doesn’t exceed the number of committed patches ten fold. Each one of these is progress toward a communal goal—make WordPress better. Submitting a patch and not having it accepted is not a waste of time.
  3. Embracing backward compatibility. WordPress is backward compatible and this can be tough. It’s often much easier to create a patch that solves “my problem” without having to worry about how it affects 20% of the Internet. We don’t have the luxury of tossing those in. From time to time a patch could be held back because there is no immediate approach that can guarantee existing sites don’t break. Submitting this patch was not a waste of time, even if a wait is required.

So that’s that. Jeremy’s path to becoming and guide to being a WordPress core contributor.

There’s a gaggle of friendly WordPress folk waiting in IRC and on Trac to help you jump in when you’re ready. Get on it!

DSCN7706

Routing URL Requests to Sites in WordPress Core

I’ve been thinking a lot over the last many months on how to approach the use of varying URL structures in a single multisite installation of WordPress. Another conversation on Twitter tonight reminded me there are quite a few developers out there itching to improve the process. I’m going to attempt to convey my current thoughts here.

In the comments of a great write up on a potential roadmap for the future of multisite in WordPress core, Andrew Nacin has this thought:

Your comment made me realize I need to stop calling it “domain mapping.” This wording stems from the fact that a top-level domain is “mapped” to an existing subdomain or existing subdirectory.

Multisite has historically been a choice between two options: Am I going to organize all of my sites with subdirectories or subdomains?

  • `http://example.com/sitename1/`
  • `http://sitename1.example.com/sitename1/`

This is great if the structure of sites you’ll be maintaining on your network is planned this way. The wrench usually appears when an entirely new domain needs to be supported.

  • `http://newexample.com/`

It’s at this point when a developer can turn to a plugin solution–likely WPMU Domain Mapping–to map this domain to an existing site in a subdirectory or subdomain structure.

  • When a request for `http://newexample.com` is received, load `http://example.com/newexample/` OR
  • When a request for `http://newexample.com` is received, load `http://newexample.example.com/`

Of course a more complex requirement may come up at some point that involves something more than just a new domain.

  • `http://newexample.com/subsite1/`
  • `http://sitename1.example.com/subsite2/`

The solution required here is some sort of custom `sunrise.php` file to help route requests combined with some process to store domain and path information for each site into the `wp_blogs` table in the database. I’ll offer the sunrise we’ve started to use at WSU as an example.

This is where the true mapping happens, whether it’s done by WordPress core in `ms-settings.php`, a sunrise file provided by a developer, or by the sunrise file provided by the WPMU Domain mapping plugin. A requested URL is parsed into a domain (host) and a path (subdirectory). This information is then checked against something, likely `wp_blogs`, to determine what `$blog_id` and `$site_id` should be used when loading WordPress.

So continues our unfortunate nomenclature. `$blog_id` is telling WordPress what site to load. That site happens to belong to a network which is tied to `$site_id`.

Anyhow. This is how we should think of the entire process:

  • When a request for this domain and path is received, use this site’s information when loading WordPress.

Beyond a few sanity driven technical limitations, such as nested subdirectories, we shouldn’t care too much about that domain and path combination. Our primary concern when a request is received is whether or not that domain and path match an existing site in the database. If they do, then we can properly load all of the data associated with that site and it’s parent network.

There are a few additional caveats that will be related as we figure this out:

  1. Cookie management. If a user is a member of a single site, this should be no trouble. If a user is a member of sites that have different domains, then this becomes a harder issue to account for. One option is to require that user to login twice to access both sites. If we’re good, we can take care of both at once.
  2. Conflicts. When supporting a mix of domains and subdirectories, we’ll want to make sure that those subdirectories don’t conflict with other possible slugs created with content or by WordPress core. If `http://example.com/` has a page slug of `howdy`, we don’t want to allow the site `http://example.com/howdy/` to be created.
  3. Allowed characters. A mixture of rules exists in WordPress core at the moment around user and site creation. We’ll want to confirm what characters we want to allow in domains and in paths when sites are created.

I’m not sure if this all helps us figure out what to call it, but I do think something like routing is more apropos than mapping. This is part of a routing process that takes pieces of a requested URL and determines what to output as a response.

20131201-coffee-001

AeroPress and Gevalia Kaffee Espresso Roast

http://www.youtube.com/watch?v=BY0Nv4ml5Kk

I fell–I know–for a commercial not too long ago that claimed off the shelf Gevalia house blend tasted better than Starbucks off the shelf house blend and I decided that I should try it with my new AeroPress so that I wasn’t missing out on anything. I’m not sure how much of a difference this makes, but I chose the espresso roast because I wanted to make something espresso like.

On the first press, I shot for the stars and tried to make a strong double espresso.

  • 30g of tamped cofee in an upright AeroPress
  • Water 30 seconds off the boil to just above the 2 mark.
  • Wait 10 seconds then press.

It required a bunch of pressure to push through, so I thought I had done well in getting a high-bar press going and that I’d be close to espresso. Unfortunately, while it looked good, the coffee tasted really strange. There was some kind of sour-y acid tasted that lingers around after every sip. It’s not due to the strength of the coffee, because I love strong coffee, but I’m not entirely sure.

The second batch, I used Stumptown’s inverted method with just one scoop. This turned out much weaker than the first, as expected, but that weird taste is still hanging out in the background somewhere. I can’t describe it as sour, but it’s something strange.

Ok, so now I’m completely wired because I tried to figure this all out in the span of 30 minutes.

The third batch is what I’m going to have to stick with for Gevalia. This time I used Stumptown’s inverted method with 30g of coffee with about 95g of water. It didn’t taste great, so I diluted it a bit by adding some more water. This became drinkable and while the weird taste is still back there somewhere, it definitely doesn’t bug me each time I take a sip.

Now to go run around the house a few times because my hands are shaking.