Category: WordPress

WCSF 2014 Talk: Public Universities and Open Source Software

The above is my talk about applying the open source ethos to sharing our work as a community in public land grant universities. I posted earlier with the full textual context and slides.

You may notice that the talk description is very far off from the actual talk. :) I originally submitted an expansive talk on public universities using and contributing to open source software. When I was invited to do a 5 minute lightning talk instead, I chopped and chopped at the original material. Once I reached the 8 minute mark, I had to pick between two paths and this felt the most right.

Boone asked a question after the talk which was exactly related to the other path. And I flubbed the answer. I’m in the process of writing a post now with what I really wanted to say and it’s definitely a topic I want to continue discussing.

I will also note that I loved the lightning talk format. It was the hardest talk I’ve had to prepare for and I’m happy that I recognized that far enough in advance. It was great to be a part of such a wonderful lineup this year at WCSF.

Public Universities and Open Source

The following is a contextual document to go with my lightning talk at WordCamp San Francisco, 2014. You can download the slides, but they are fairly contextless. :)

In 1904, Kenyon Butterfield introduced what he called the Social Phase of Agricultural Education. He believed agricultural colleges should be “the inspiration, the guide, the simulator of all possible endeavors to improve farm and farmer.”

He saw public universities as having 3 functions:

  • Organ of Research
  • Educator of Students
  • Distributor of Information to those who cannot come to college

His work led to the Smith-Lever act of 1914, which established the concept of extension services. These extension services are embedded in public land grant universities and act as a conduit between research and community. This establishes the distribution of information, something Butterfield actually refers to as the democratization of truth.

Today, these extension services are part of the Cooperative State Research Education and Extension Service. Its ultimate goal being to “Advance agriculture, the environment, human health and well-being, and communities.”

The core mission of the WordPress project is to democratize publishing through open source, GPL software. It’s at this intersection of ideas between WordPress and public land grant universities where I get the most excited.

We also have a long way to go.

If you look at the criteria for an associate professor in a public land grant university on track to tenure, you’ll notice an alignment with Butterfield’s vision: Teaching, Research, and Service – three things a professor must focus on to become tenured faculty.

If you talk to an associate professor, you may hear other criteria – Research. Funding of research, publication of the research, citations of your published research in the research of others…

While service, or the distribution of information, is important, it’s often the money or prestige coming into the university that can trump all.

This actually isn’t that far off from other public non-land grant universities. A professor on track to tenure there is likely focused on Teaching and Research, without the specific instruction to distribute information to their community.

With that in mind. I’ve been focused on two questions lately:

  • How do we encourage sharing of work with the community?
  • How do we make it easier to share work when one is ready to do so?

WordPress makes the second question pretty easy. We can setup a site within minutes with all the functionality needed to start publishing in an interface that actually makes it pleasant to create content.

The first question is the hard one. It involves a change in mindset.

If I talk about my research as I’m doing it, what will stop a competing researcher in another university or company from leap frogging my work and publishing before I do? Do I lose the right to my intellectual property, possibly prevented from working on something because of a patent I should have gotten?

My favorite response so far is “Who Cares?” What is the absolute worst that will happen from somebody stealing your research?

I’m not trying to trivialize the work somebody is doing. I really do thing answering this question can help answer a larger question.

What can we do to make it easier to share work while also protecting the work that someone is doing?

I think if we look to the ethos of open source, we can find the answers we’re looking for.

The free software foundation defines the four freedoms of free and open source software as such:

  • The freedom to run the program as you wish, for any purpose (freedom 0).
  • The freedom to study how the program works, and change it so it does your computing as you wish (freedom 1). Access to the source code is a precondition for this.
  • The freedom to redistribute copies so you can help your neighbor (freedom 2).
  • The freedom to distribute copies of your modified versions to others (freedom 3). By doing this you can give the whole community a chance to benefit from your changes. Access to the source code is a precondition for this.

Some of this freedom is already accounted for with the rise of open access publishing. Many universities are creating policies where final research works must only be published in open access journals or, when published elsewhere, be part of an open access repository housed by the University.

However, if we really are distributing information to the community, should we not share the beginnings of our work as well, or at least the process?

Yochai Benkler, who has written a lot of great material on open source and communities, wrote that “the most precious of all public domains” is “our knowledge of the world that surrounds us”.

He also says:

“Information, knowledge, and culture are central to human freedom and human development.” – Wealth of Networks

I like those sentiments, that state of mind.

And I would like it if you gave thought to how we can, in the process of democratizing publishing, also find ways to help public universities democratize the truth.

#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.

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!

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.

Hi WordCamp Europe, My Name is Jeremy

Hey fellow WordCamp Europe attendee!

A week from tomorrow I’ll be making the long series of flights from Pullman, WA to Amsterdam. From there it’s a short train ride to Leiden, where I’ll spend the next week hanging around, doing some work, enjoying the area, and attending WordCamp Europe.

At Washington State University, we’re proud sponsors of the first WordCamp Europe and I’m very excited to be attending.

I have a few things on my checklist to accomplish while I’m there:

  • Meet you all! It’s going to be great to have so much talent from across the world in the same room and I can’t wait to learn from everyone.
  • Talk with anybody involved with WordPress in higher ed. I’m starting to become more and more aware of prior art at the university level and I’d love to sit down and chat with anyone about their experiences.
  • Talk with anyone who has tackled WordPress Multi Network. We’re building out a large central platform at WSU and my focus over the next year is going to be directly on improving this experience as much as possible. I’m hoping for this to be my focus on contributor day as well, though at that point I’ll help with anything to make 3.7 ready to ship.
  • Talk your head off about development environments and deployment techniques. Primarily Vagrant, but I’m a geek about all of it. If you have any questions about VVV (started here just 9 months ago), I’m more than happy to walk you through the answers. If you’re looking to make the next step into a Vagrant environment of your own, I’ve got opinions!

I enjoy coffee. I enjoy beer. I enjoy walking around new places. If you’d like to join me for one of those while we’re in Leiden, leave a comment here, ping me on Twitter, or send me an email. Let’s do it!

As far as non WordCamp activities go, there are a few things I’m looking forward to.

I’m excited to arrive with perfect timing to celebrate the end of the siege of Leiden. I’m planning on heading out to the De Molen brewery mid-day on Friday to get from the source what is supposedly the best beer in Netherlands. And on Tuesday, after all the WordCamp Europe festivities have died down, I’ll be grabbing a train down to Brussels to be a tourist for the day.

See you all there!

My First WordCamp Talk

On Saturday I had the great pleasure of speaking at WordCamp Vancouver. It was my first time speaking at a WordCamp, and my first time ever really speaking about anything at length. I really, really didn’t want to bomb this, because the idea of talking WordPress and geek in general with a bunch of likeminded folks is awesome and I wanted to kind of mitigate the possibility of a discouraging first experience.

So I picked the brain of friend, coworker and amazing speaker, Zack Tollman, and got a few tips.

The biggest takeaways were preparedness and practice.

  • Really researching and knowing the material rather than winging it.
  • Actually going through your talk a few times so that you know where your problem areas are before you get to them.

He also recommended Confessions of a Public Speaker [Scott Burkun], which turned out to be a fantastic read. Because of Zack’s advice and the added info from Scott, I actually ended up doing a bunch of mental preparation about the approach I wanted to take before I finally dove in on the presentation itself.

When I did dive into the presentation, I decided to try and get as many of my thoughts down and organized before worrying about a slide. For this I used an outlining tool, WorkFlowy, and ended up creating the entire talk this way. It did become difficult to transfer this data in the way I wanted for my article and slides after the talk, but other than that it was perfect. I may explore different outline options directly in WordPress for the next one.

After completing a decent draft of the talk, I then gave it a few practice runs to make sure things were feeling right. At this point I was able to remove material that didn’t flow and sharpen a few points that were getting lost. Once I started to feel satisfied that the stuff was working, I dove into Keynote land to create the slides.

Keynote ended up working out so much more awesome than I thought it would. I think next time I’ll leave myself with a lot more time to create the slides as I think I could have been more efficient and creative at the same time. Being able to use my iPhone as a Keynote remote was an added benefit, though the presenter notes ended up being a bit of a crutch.

I went through the full presentation a couple more times after the slides were created. This enabled me to figure out where I needed notes and to take out some stuff that was still feeling forced. I ended up not doing a full run through in the morning before my talk in favor of an extra hour of sleep, but I think that was one of those good decisions.

At first I wasn’t sure about being first on the schedule, but I think that played to my benefit. I was able to sneak into the room alone, walk around and kind of get a feel for how people saw the front and how it felt to say a few words. The tech setup was great, so I really didn’t have much to worry about.

The talk itself went well. I was less nervous than expected, though any time I lost track of my thoughts and tried to cheat with the presenter notes I felt it. The reaction from everybody throughout the talk was wonderful and I was surprised many times at how well less obvious humor got across. Everything went super fast and I was on the last set of slides before I knew it. I only forgot a few things, but nothing that hurt any of the points I was making. And the Q&A session went perfect. We had some really good questions and I find a lot of comfort in that back and forth discussion.

My overall thought on the next talk is to move prep time back by at least a week. I’d love to be in a place where the last week is less about slide prep or content creation and more about practicing the talk itself. I think I’ll try to find an alternative to the presenter notes in Keynote Remote. The iPhone was a perfect slide switcher, but the small screen is too distracting when you want to take a quick look. Depending on the room, a piece of paper with a few notes would have probably turned out better.

And that’s it. Eating my own dog food and documenting myself.

Anybody that was there – thanks a ton for sharing that experience with me and for the positive reaction throughout. I had a blast.

And now, a bunch of tweets from awesome people! Thanks, #wcyvr!

Continue reading My First WordCamp Talk

Calm and Simple Code With Purpose WordCamp Vancouver 2012

Calm and Simple Code With Purpose – WordCamp Vancouver 2012

The slides for my talk at WordCamp Vancouver are available in PDF via the link above. I’ve put my notes together in a decent enough form below to help provide context for each of the slides as they’re pretty content light. Enjoy!

Continue reading Calm and Simple Code With Purpose WordCamp Vancouver 2012