Month: March 2015

WCSEA 2015: Panel — WordPress at Scale: Enterprise, Media, and Education

I’m at WordCamp Seattle today and will be post­ing notes from ses­sions through­out the day. These are posted right after the session, and could be a little rough.

This was a panel discussion moderated by Grant Landram, with Evan Cordulack, Jeremy Felt, Josh Kadis, and Nathan Letsinger. Follow those links to their Twitter pages. Here is the WordCamp.org session description.

Introductions

Moderator — Grant Landram: Senior project manager at 10up.com, previously with FreshMuse.

Jeremy Felt: Platform Manager at Washington State University. Previously senior engineer at 10up.

Josh Kadis: Internal and external product development at Alley Interactive, and Seattle dev meetup organizer. Previously the senior technologist at Quartz.

Evan Cordulack: Engineering manager for the Seattle Times.

Nathan Letsinger: Product lead at Grist, designer and developer.

Topic 1: What is “Scale”?

What does scale mean or look like with you and your organization?

Josh: Scale means traffic, pageviews, load on server. But there’s also internal users, scale of code base, database.

Evan: Scale means the bigger the database gets, then the things we thought WP was good at out of the box left us with some hangups. We still fight with that every day.

Nathan: Scale means we needed to deal with just the shear number of users. 2 dozen or 600 users who need to login raises a lot of concerns. Could be security. Many people logging in at the admin level means you should evaluate security. We have 700 bylines for posts, and didn’t want that many fake users in WP.

What special considerations do you have?

Jeremy: When you’re no longer running a single WP site, a lot of caching considerations get really complicated. Also a lot depends on your budget. With more money, have a sysadmin work on this for you. If you don’t, there’s a lot you can get away with on a single Linode with Memcached. Even if you’re paying someone to do this for you, it makes sense to understand what they’re doing for you, so you can write code that works well in sync with the systems you have in place.

Josh: The use case most people have for WP is one where every non-logged-in user gets the same HTML markup. If you’re working on a BuddyPress site, then that’s a totally different story. But normally, traffic can quickly become a non-issue with full page caching.

Evan: We try to use caching at every level. We use Akamai, then Varnish, Memcached… and at the WP API level, we use transients everywhere to take advantage of the Memcached object cache. We managed to totally kill page loading speed early on in develompent. Once we started taking advantage of caching APIs, it shaved off seconds. There are things built-in that get you really far, really fast — whatever level you’re at, even if you don’t have object systems in place. And it’ll make you feel like a pro.

A lot of managed hosts disable caching for logged-in users. So if you have high logged-in user traffic, you need to be more strategic about your caching strategy.

Nathan: You want to worry about caching. For us that meant full page caching. A story about this: Before we were on WP, we had that problem. Our best days for editors had huge traffic spikes. Those were our worst days for our developers, when we were having to spin up new servers, etc. We learned about Batchache from the WordPress community, and ported it over to our old system. But in the process we learned enough about the WP ecosystem that it convinced us to embrace WP generally.

Nathan: You need to know the constraints your caching systems should have in place, so that you know what not to do to break things. For example, we can’t add database tables without also having to modify our caching systems to accommodate those. I actually found these constraints freeing.

What other tools are you using?

How do you make choose which systems to use?

Nathan: It also depends on your passion. We’re not sysadmins, but we were playing that role part time. Can we hire someone to do this for us? We decided to pay somoene to just solve this for us. Even if we felt we were paying too much, there’s a lot of value in peace of mind. So when your traffic is spiking on a Saturday, I can keep sipping my Manhatten and not worry about it.

Topic 2: Scaling Strategies

Dev Team Sizes for your organizations

Jeremy: 20 or so on the team doing content, design, dev, everything. We’re supporting 600 sites and around 1,000 users. Central univ support.

Josh: We have 40 people at Alley Interactive including non devs (PMs, design, etc.). On a given project we may have as few as a dev and a PM. But sites we support with caching strategies are as large as the NY Post, which is one of the largest WP sites anywhere. They’re hosted on WP.com VIP which handles scaling, traffic, caching in the same way for us as it does for anyone else. That enables us to be the dev team for them with a relatively small team because we don’t need to worry about it.

Evan: Dozen devs. While there are a lot of users in the system at a time, there are also content being injected from various places constantly.

Nathan: It’s 2 devs and myself at Grist.

Key parts of your tool set (tech, process, organizational) for scaling

Jeremy: Have a local environment matching production as closely as possible is important. Then after that I rely on Ngynx and MySQL (although Zach Brown would recommend alternatives to MySQL like MariaDB).

Josh: For sites with very large database, e.g. New York Post which has a million database rows, we use Elasticsearch for queries (not just user-facing search). Even if you already know the ID of a post, in a large database a post-specific query can be expensive.

Nathan: Lots of users writing means you need something like a calendar for scheduling, and some kind of chat program so everyone’s in touch w/ each other. This is pretty essential for the overall team.

The Reliability of Elasticsearch

[A question from me, hence the greater detail in this document:] Josh mentioned depending on Elasticsearch for Queries. Kyle Kingsbury posted some research into Elasticsearch last year that raised questions about its reliability. Have you encountered that or had to deal with it in production?

Jeremy: Automattic makes heavy use of Elasticsearch, with people doing the work full time. If they can trust it and they’re using it at insane scale, even though they have to rebuild their indexes occasionally, then it’s probably fine.

Evan: There are a lot of queries that are surprisingly taxing at scale. Times Elasticsearch has failed for us are usually times that we did something wrong. You can write integration stuff that’ll make your life easier. Inevitably you’ll have to reindex and it’ll be a drag.

Zach Brown, from the audience: Basically, don’t use it as canonical. It’s just a way to access info quickly.

Workflow for content to moves from outside of WP into WP

Jeremy: Even though we think TinyMCE and DFW are neat, nobody uses it, because people pass things around in Word and then copy/paste them into WP.

Josh: At Quartz it became the policy that stories had to be written in WP. I could still tell who wasn’t doing that. But we were able to help allay concerns from journalists just because people get a little put off by the interface because if it’s a little off-putting to them, it’ll become familiar eventually. “Word was new to you too, once, and this will get better eventually.”

Evan: We don’t have anything like an editorial calendar, and we don’t have a good way to do this.

[After a Follow up question from audience about content/workflow policy governance and enforcement:] We rely from WP for curation; what shows up where. That’s where WP does the most work for us. Revisions of the story will happen in a different editing platform, reason being we have to feed the printing press. Some would like to do digital first, but “that is not my department”.

Nathan: Autosave has been great for the concern about browsers crashing.

Do you run your sites through performance analyzer tools?

Jeremy: I obsess over websitetest.org. On launch days I’m refreshing every 10 minutes trying new things, trying to get others out.

Josh: We’re taking the opposite approach: Starting a project by structuring build tasks, so that when you get to the end, Grunt or Gulp or whatever you’re using has already been done. [In other words, this is a philosophy of beginning with high performance as your baseline, rather than revising to get it right at the end.]

Evan: Since these tools are easy to use once you show someone, then everyone cares about performance. This is good and bad because meetings get really weird really fast (talking about which DOM events matter with non-devs is strange), but good to have everyone considering it.

Do you use tools to find performance issues specifically in code?

Jeremy: John Blackbourn’s Query Monitor plugin. Using things like xdebug or PHPStorm with step debugging can identify loops that are running multiple times and slowing things down.

Josh: Peer code review is huge for performance because you can rely on the experience of your team, seeing what things are slow, what’s caused problems for them in the past, etc. Leverage your embodied experience.

Besides plugin updates and installs, what changes when you move to a multiserver load-balanced environment

Jeremy: I’m only running one VM, but… it becomes more to manage, more pipes to keep connected, so more things to worry about going down. But, scaling horizontally by having more redundant things can be a less painful thing where everything’s beefy and fast…

Evan: We have a ton of internal conversations about this, and everyone has an opinion. Whatever it is, take your time. If you’re using a cloud platform, you can experiment with scaling things up and down. (If you’re having to do this in production, that’s another story.)

For large editorial teams, how do you manage training as you make continual changes?

Jeremy: Every Friday morning we have an open lab on campus for people to come talk. We say “we’re working on this, here’s a preview” and we get good feedback.

Josh: It’s important to treat dev of internal WP functionality as a UX problem in the same way you would treat a design change on the front-end. Without completely redesigning the admin interface there is still a lot you can do to make a feature intuitive and easy for people to figure out (or totally baffling and unintuitive). There’s a degree of design thinking you can apply to internal plugin dev that I’ve found helpful — even briefly and semi-formally for an internal plugin can really help speed up adoption.

Evan: If new changes require one-time actions before you can use them or before the UX returns to normal, and people don’t know about it, that upsets people. It’s important to give people a heads-up about changes that are coming.

Architecture constraints migrating to WP from other platforms

Josh: The constraint is less about the total number of content objects than it is about the differences in information architecture. The great thing about migrations is that you’re typically not that concerned with performance (within reason). So when you start the migration script if you’re talking about 6 hours or 10 hours to finish, it doesn’t matter so much… But if you can’t get a clean map of information architecture, that can be difficult.

Evan: We had a lot of problems with DB performance. It would get to a certain size where we were timing out, particularly around post_meta. It was failing in mysterious ways. We were in a hosted environment where there were settings we didn’t have access to. Lots of little roadblocks to clear, remove one, hit another, so we had to get through a bunch of that.

Nathan: We use EditFlow, which includes the editorial calendar. There are many media companies and even mid-sized blogs using this who need a calendar. This is an area for growth. We’re testing CoSchedule, which is monthly paid service, and has great features, but is off of WP’s architecture. I think this is an area where media companies have a need.

Have you encountered bloat from leaving revision management active?

Josh: On one occasion I’ve run a wp-cli script to clear out revisions on very old posts.

Nathan: That’s WordPress.com VIP’s problem. :)

What do we need to know about what’s coming?:

Jeremy: The easy answer is the JSON REST API and having everything available to you via JSON.

Nathan: Improvements to taxonomy terms will open a lot of opportunities.

This post is part of the thread: 2015 WordCamp Seattle Live Notes – an ongoing story on this site. View the thread timeline for more context on this post.

WCSEA 2015: Amanda Blum — Long Term Relationships – Creating Sustainability in WP Client Handoff

I’m at WordCamp Seattle today and will be post­ing notes from ses­sions through­out the day. These are posted right after the session, and could be a little rough.

This is a talk from Amanda Blum, project manager and pretty darn good friend of mine. Find Amanda at @amandablum on Twitter and at howlingzoe.com on the web. The WordCamp.org session description is here.

We need Client Empathy

We’ve become good at development as the community has matured, but still need to get better at client relationships, and client happiness. Amanda’s started to hear the term “client empathy” get thrown around lately, and she likes the trend. Here are her ideas for what we need to do to deliver better experiences for our clients.

Allegory: Getting Amanda’s Garage Ready for the Kiln

Amanda’s been working on getting a ceramic studio into her garage, which needed work first. “tl;dr — it sucked”. A man who only spoke Russian offered to do the garage drywall project for free, which she knew she needed, but she couldn’t say Yes! because she was overwhelmed by everything he was trying to communicate that she couldn’t understand. She ended up doing it herself with friends, which was tough (understatement).

Clients don’t walk away from you even though you could make their business 900 times better because they are morons. They walk away because they are overwhelmed.

Clients are not all idiots

We bitch a lot about clients being idiots, but clients recognizing they need help is to be applauded, not chided.

It’s hard for clients:

  • “We are an industry of snake oil salesmen.” There are no licenses, no accreditation boards, no certifications, etc.
  • Costs range from $7 and $70,000, and cost is not an indication of quality. Expensive projects can fail and cheap ones can succeed. How can we expect clients to have good price expectations?
  • Clients come to us with ideas about what they need, we move them in another direction (and then we talk behind the scenes about how stupid they are and how low their price expectations were).
  • We sneer, but $5K is a lot of money for most people, and it’s a reasonable amount of money to buy a lot, in a lot of contexts.

We need to find a better way to communicate the value better, and to do it in a passive way that doesn’t make them feel stupid.

Amanda’s Advice

Set Good Expectations

Good expectations are matching expectations.

Engineers speak a different language than clients. “I want an event calendar” in client speak may turn into “I’m going to install a plugin” in engineer speak, but the engineer knows the plugin will need maintenance. That doesn’t mean anything to client; client assumes “I want it to work” didn’t need to be said.

Expectations about outcomes should be written into contracts — without adjectives. Instead of implementation details like “install this plugin”, write about outcomes, like “Event calendar, which we will support for X years”.

Stop Assuming

Everyone here has a font, a plugin, a theme you’re just dying to use and work in on some project. We think we know what would be great for our clients before we start talking to them. But we can’t go into projects like that.

We have dev environments at home, and our own blogs. Play with those to have fun with your toys. Leave those desires and assumptions at home.

Use a PM

Engineers cannot QA their own code, because they’ve written it. Engineers should also not do support. In terms of client relationships, few things are as important as QA.

Using “pixel perfection” as an example, it is something you can verify as done, and write tickets against, etc. You can test every single aspect to make sure they work.

But PMs should do this. Why? Because the PM insulates between the client and the engineers. A PMs’ main job is making the engineers more effective. Call it an air-gap.

Engineers generally over-explain. They can’t translate.

Tremendous respect for engineers: They are like dogs with a bone when they have a problem to solve. But they need this: A good PM will tell them which problems to solve.

The donut example

“I need one donut tomorrow.”

“Great, we can make you a donut machine that will make you all the donuts you ever need, by one week from tomorrow”.

“Great, if it’ll be ready tomorrow and can make me one donut, awesome. If not, just make me a fucking donut.”

You cannot engineer without a Plan

There was project where Amanda suggested taking text articles out of a client’s newsletter and putting it into the blog. She could see numerous benefits, but the client stubbornly said it couldn’t be done. Amanda finally realized after a couple of weeks that they were never going to enter the blog posts because of their process, which just made it too hard.

It would’ve been easy for Amanda to just build this for them, but it wouldn’t have worked for them.

You need to create a plan based on the clients’ needs, process, etc., before you build, to avoid building something that won’t work.

Build for the way people use

Don’t assume people will become WordPress experts and bend their process to WordPress’s way of doing things. If WP is different than the way they are already working and the way they want to work, they’ll have trouble with it.

Example of how we can make this better for clients: Customizing the dashboard menus to match clients’ lingo and what they want and need to do with it.

Workflow is a Cascade

Clients want to get to everything immediately, or want to jump around a lot. Refuse to move forward in the process until you have what you need to move forward, to be successful.

There is a natural waterfall/cascade: Scope > Define goals > Info architecture (sitemap) > Design > Build > Test > Deploy > Ongoing refinement

You can move backwards in this process if you need to, but don’t jump ahead to move forward too quickly, or things will go off the rails.

Friendly is not the same as friends

Politely decline FaceBook connections to clients.

Don’t hire anyone you can’t fire. This goes beyond nepotism: Don’t hire anyone — not just family — that you can’t fire.

It’s important to avoid crossing lines and to keep things above board and professional for the success of your working relationships.

There’s a spectrum of how to reply communicate: On the one end is an Immediate Response, an over explaining answer, and being chatty. On the other hand is no response, and silence.

What clients actually need is acknowledgement of receipt, and request for time to respond. Then, be as to the point, direct, and brief as possible. (Edit adjectives out.)

Test, then Test Again

“Test what you’re doing within an inch of its life.” Testing is often under-estimated in the life of building a website.

After the Job

As a summer camper, this isn’t clear, but as a camp counselor you learn to recognize that the summer camp emotional experience is formulaic: They have a marketing ploy by making everyone emotional at the end, with a slideshow showing pictures of you befriending your friends throughout the week, with nice music… they sign up 60% of their returning kids within a week of the end of camp.

The end of the project is where you ensure its success.

Remember that Clients Forget

“He looks like a 28 year old entrepreneur, but he’s actually a 78 year old woman with alzheimers, and just doesn’t realize it yet.”

Thus, put everything in your PM system.

The very few times you’re communicating outside of the PM system, automate getting the data in with ITTT or something. Immediately after a phone call, enter your notes into the PM system.

This isn’t a CYA thing, it’s a people have no memory thing.

Stop Teaching WordPress

We do a lot of teaching WP, but it’s gotten harder as it’s gotten more complicated. It’s really hard now, and a barrier.

But, we’re building really customized sites that do very specific things for our clients, so now we need to just teach them those things they need, not all of WordPress.

Amanda recommends a plugin that allows you to create a help menu you can customize and add right on the Dashboard. [I missed the plugin and will add that later.]

Encouraging Autonomy

When you have a feeling of success, you tend to move forward. Make sure you can give them that feeling of success.

For example: No one is ever going to follow through on their corporate blog. For clients who are really insistent, Amanda likes to get them on CoSchedule and start to build an editorial calendar so they can see what it’s actually going to take from them, before they commit and before you build the blog they won’t be able to maintain.

Testing shows progress

Build testing into contracts to show progress during the project. Continue to refine in tiny ways as you move forward throughout the project.

Amanda means tiny details, literally — for example, a button’s copy. “Does this button title work better, or this?” Clients love that; it feels productive.

Follow-through

The moment after you are done, a million things have to happen. Talk with clients about:

  • Here are the things you need to think about on a daily/weekly/monthly basis
  • What’s your plan for backup, for security, for maintenance if not through me?

If they fail to use the site after the project is over, then you failed.

For more information

To receive Amanda’s notes, email [email protected]. Her slides are available on Slideshare.

This post is part of the thread: 2015 WordCamp Seattle Live Notes – an ongoing story on this site. View the thread timeline for more context on this post.

WCSEA 2015: Jake Goldman — 10 Interview Questions I ask Devs

I’m at WordCamp Seattle today and will be posting notes from sessions throughout the day. These are posted right after the session, and could be a little rough.

This is a talk from Jake Goldman, owner of 10up. The WordCamp.org session description is here. Find Jake Goldman at @jakegoldman on Twitter and at 10up.com on the web.

Jake’s Credentials

Jake has vetted hundreds of candidates, made a lot of great hires, also made many valuable mistakes as he’s grown 10up to over 100 team members.

Here’s how Jake approaches an interview with software engineers:

You are not Looking for Polish

This is the biggest mistake people make: Assuming that if they’re a great communicator, and make a great sales pitch, then they must be a good engineer.

Jake’s found on the contrary that people who are the most polished are often worst for development. They may be good on the PM or the account side, but Jake would predict not the dev side.

[Clarified during Q&A:] These aren’t always mutually exclusive. Jake isn’t looking for terrible communicators. It’s important to be able to string sentences together. But in a team, you need people focused on different strengths. People who show up ready to hard sell you on them tend to not work out.

Here is What you Are Looking for

  1. The candidate “gets” the platform. Core principles of the software and what it’s for
  2. How much do they know about building on WP and its core technologies. It’s becoming increasingly important for them to understand complementary set of technologies that the platform is more dependent on, like JavaScript, Backbone, etc.
  3. Does the candidate think critically about his/her work? Are they strategic thinkers? Jake says this is the most important.

Rule Book

  1. There is not always one right answer, but there are better and worse answers.
  2. Answers can show beginner, advanced, or profoundly senior level knowledge
  3. There are some very wrong answers.
  4. Not knowing everything is ok.
  5. Pretending to know everything is not ok. This is important for teamwork. A big red flag is people who don’t know how to say “I don’t know,” and try to wing it. This suggests they will just pretend they know what they’re doing, and managers will find out there’s a problem 3 weeks into a project instead of on day 1 or day 2.

Questions, Part 1: Basics of WordPress Understanding

Honestly, now, do you “WordPress”? (sic — lowercase _p)_

Question 1: Tell me what a “hook” is, and talk about the two basic hooks in WordPress, and the difference between them.

Answers, in order from very wrong to very good:

  • “A hook is a killer feature that gets users addicted” (Jake’s favorite ever BS answer)
  • An answer: A way to extend WP. “Themes and Plugins”
  • A technique used to alter or augment the behavior or software.
  • WordPress has action and filter hooks.
  • “Actions fire ‘hooked’ functions at specific points during execution. Filters pass data through “hooked” functions just before WordPress takes an action …”

Question 2: Explain what a taxonomy is

Answers, in order from very wrong to very good:

  • A method to preserve unused (dead) code.
  • The various types of content in WP: posts, pages, media, menus, etc. (this answer is confusing meta data with content types)
  • A way to group things together. (Not a bad generic explanation.)
  • WP posts have two default taxonomies: categories and tags. You can add others through
  • Bonus: A few lesser known default taxonomies.
    • link category
    • navigation menu
    • post format

Question 3: Let’s say you see wp_list_pluck() for the first time. How do you figure out what this does?

Answers, in order from very wrong to very good:

  • Google (not a bad answer, probably an honest answer, but it doesn’t tell you much as the interviewer.)
  • Code reference — this is a better answer than it used to be.
  • Look at the source code. They’re ideally using a configured editor or an IDE to shortcut to this quickly.

Questions, Part 2: How Senior are you?

Here we want to learn just how experienced you actually are, if you’re beyond beginner.

Question 4: Explain what sanitizing and validating data means, and apply that to WordPress.

Answers, in order from very wrong to very good:

  • Checking database integrity and ensuring the database hasn’t been corrupted. (Wrong)
  • Testing data to make sure it’s what you expected. (Not a bad beginning, but layman, generic.)
  • Answer explains the concept of untrusted data: “Untrusted data comes from many sources (users, third party sites, your own database!) and all of it needs to be validated both on input and output.…”
  • WP includes helper functions… like wp_kses, etc. Describe correctly which of these exist, what they do, and when to use them.

Question 5: A client needs to selectively exclude posts from their blog home. How would you achieve that?

This is a more open-ended question than it seems, because people give different answers (that can both be correct) depending on if they’re more UX minded or more code minded.

UX Answers, in order from very wrong to very good:

  • Add a new post category called “Exclude From Home.” — Not a great answer, because not resilient. Ask what happens when user deletes that data, etc.?
  • Add a new custom meta box with an “Exclude…”
  • Someone who’s really advanced might answer something like: “Hook into post_submitbox_misc_actions to add an ‘Exclude from home’ checkbox to the “publish” box. (This shows deep understanding of how hooks are powerful, with a deep UX understanding.)

Dev answers, in order from very wrong to very good:

  • Add an ‘if’ statement inside of the loop checking my ‘hidden’ criteria before outputting the post. (“This answer makes me cry.” You don’t want to do this after getting posts back. What if all ten satisfy that criteria? You have an empty home page.)
  • “Create a new post query at the top of my home.php template, excluding posts based on my criteria.” (Not a good answer — running two queries. Plus, if anything else alters the home page query, you have a problem. You’ve probably forgotten about pagination.)
  • Use pre_get_posts to modify the main post query before it runs and modify it there. (This is the right answer.)

Question 6: What’s “use strict” all about?

Correct answer:

  • Directive indicating that JS code should be executed in strict mode’. Catches common coding mistakes and throws errors when relatively ‘unsafe’ actions are taken. (definition from w3c I think.)

Question 7: You need to retrieve data from a remote source once/day. Tell me about some of the WordPress APIs you’d use.

Correct answers we’re looking for:

  • Use wp_schedule_event() (WP Cron API).
  • Indications of performance awareness, caching, etc. e.g. using wp_remote_post().
  • Another answer along those lines: Use set_transient() (Transients API).

Questions, Part 3: So you can code. Can you think?

Good, smart people can not care, not be passionate. Good, thoughtful answers to these show me people are really into this and care.

Question 8: Tell me what you’re thinking about? What are you finding interesting? Say our company gave you 3 months of sabbatical — what would you do with it?

Examples of some good interesting answers:

  • CMS as simply a data source. APIs everywhere: the emergence of a JSON API for WP, and APIs standard in other platforms, suggests the future of the CMS will be as a data store
  • Tiny devices, huge devices. Responsive design has “figured out” mobile to desktop UX patterns. But what about very tiny watches, and very large televisions? Have we figured out how to present content in these formats?
  • HiDPI (“retina”). Technical hurdles remain (like media uploads), and at some point this is going to be a standard requirement. It feels like Responsive Design circa 2009.

Question 9: What frustrates you about WordPress?

Answers, in order from very wrong to very good:

Correct answer:

  • Taxonomy / term architecture could be improved. No term meta data, strange artifacts due to way tags and categories of the same name are linked. No mechanism in core to handle metadata for taxonomy terms, etc.
  • No standard methods to create direct relationships between two content objects (post objects).
  • Having to develop community modules to the lowest common base WP requirements (PHP 5.2) — Jake thinks smarter people often answer this way.
  • Some areas don’t handle conflicts in plugins well, for example registering two custom menu items in the same spot.

Question 10: Why do you want to work day in and out with WordPress?

Answers, in order from very wrong to very good:

  • It’s the dominent CMS on the web (a fine answer)
  • It’s the only platform where customers don’t call me back in every month asking for retraining.
  • Because I value the freedoms inherent in open source, and WP is an awesome open source platform. (deep thinking engineers frequently answer this.)
  • The community. It’s more than just a piece of software; they feel at home here, etc.

Note regarding Question & Answer

Jake gave an interesting answer to a question “do resumes matter?” that I didn’t catch. It’s worth reviewing the wordpress.tv session for this later.

This post is part of the thread: 2015 WordCamp Seattle Live Notes – an ongoing story on this site. View the thread timeline for more context on this post.

WCSEA 2015: Taylor McCaslin — Multisite Network Do’s and Don’ts — Experience from an Enterprise Solution

I’m at WordCamp Seattle today and will be post­ing notes from ses­sions through­out the day. These are posted right after the session, and could be a little rough.

This is a talk from Taylor McCaslin, Product Manager for WP Engine. Find Taylor at @taylor4844 on Twitter and find WP Engine on the web at wpengine.com (affiliate link). The WordCamp.org session description is here.

I missed the first few minutes of the talk, unfortunately, so these are less comprehensive notes than I would like.

Clarifying What is Multisite

Multisite is Dr. Jekyll & Mr. Hyde. Your best friend and your worst enemy. People generally don’t actually know what it is, or what’s different about it.

A multisite network is a collection of sub-sites that all share the same single WP installation.

What is Multisite Not?

It is not a network that can be moved to separate hosts. It’s 1 host, 1 install, many sites.

It is not a group of sites that can be easily separated into their own separate installs later. You can do this, but you don’t want to have to. (Modifying serialized data is not fun.) When people think they want to go there, talk really hard about why.

Multisite is not a set of sites with different IP addresses. They all have the same IP addresses. This can ruin a multisite: One bad actor can blacklist all sites on the network. The shared IP address is a single point of failure for every site on the ntwork.

Configuring Multisite

Different Multiste Modes: Open, or closed?

Two options. This terminology is hard, because the words mean different things in different contexts. Here’s the current consensus terminology among the core cdeveloper community:

Public Network / Untrusted

Aanyone can signup and create a site (sometimes paid). e.g. WordPress.com, Happytables.com, university student blogs (which are great for giving your faculty and students the power of .edu to easily rank highly in search results.)

Concerns: file types / uploads, scripts / embeds, copyright. Your users can harm you and each other.

Private Network / Trusted

Limited sites and user creation. WordCamp.org is an example. Company intranets for different departments, etc.

Concerns:

  • Too many cooks. “Just make me a superadmin”. Uh, no! Just, no.
  • Do you have someone to manage all of this? One WP site on its own is a lot to manage. Updating a plugin that breaks on the network breaks everywhere.
  • Code changes affect all sites!

Sub folders vs Sub domains

[I missed some notes here, but I feel this is fairly well documented elsewhere.]

Domain Mapping

Plugin for this: wordpress-mu-domain-mapping

Use CNAMES! Not wildcards. Allows you to manage the whole thing with a single DNS when you need to migrate [I think that is what he said.]

wpmudev.org has premium plugins for selling domains to users. Taylor recommends these.

Benefits of Multisite

Super Admin Role

Many WP capabilities that regular administrator role users can’t do. Includes unfiltered_html. Basically, the super admin role is super dangerous for this reason. DO NOT give people access to it. They will ask for it, but just don’t.

Shared Users

  • All blogs have entral user management. This is one of the biggest reasons to use Multisite.
  • This can have weird consequences. e.g. to New York Times’ blogs which are hosted on wordpress.com’s VIP network, you see the WP.com toolbar. This is a bit weird for NYT’s branding. This also makes privacy a bit harder.
  • Doesn’t play well with alternative login plugins for 2 factor auth (Duo2, 2FA, Google Authenticator). You’re logged in everywhere (perhaps not the intention if you’re using 2FA), but you still need to 2FA into each site individually (probably not expected if you’re using MS).
  • User profiles are the same for all sites.

Shared Themes

  • Add a theme
    • Network enable (all sites)
    • Restrict themes available to use per site (Site -> Edit Site menu
  • Remember to add Child Themes.
    • If users have file editor access, their changes to themes are network wide. (Whoa.)
  • If you network enable the theme, activate it on a site, and then network disable the theme, it is not deactivated on the site that has activated it.

Shared Plugins

  • Install plugins on the network
    1. Activate per site
    2. Network Activate
    • note that this is distinct from how themes work. This is probably a better system than how it works with themes.
  • Must use plugins
    • Are enabled and active network-wide
    • Can’t be deactivated through the admin
  • Some plugins have their own network settings
    • Not all plugins do this the same way or the recommended way.

Structural Differences

File structure:

[My markdown rendering doesn’t handle indentation for file structure diagrams very well, so please bear with me using code blocks to preserve indentation for these.]

* /
    *   wp-config.php — has extra lines
    *  .htaccess — has extra lines
    *  wp-content — has extra subfolders, including site-specific folders
        *  Rely on the host to allow you to grant your site admins access to specific site directories — and only those for their own sites.

Uploads folders:

* wp-contents/
    * uploads/
        * 2015/ — this is for your primary (first) site on the network
        * 2014/ — this is for your primary (first) site on the network
        * /sites/
            * 2/ — site ID
                * 2015/

Multisite databases have at least 17 tables, instead of the standard 11. The 6 extras are:

  • wp_blogs
  • wp_blogs_versions
  • wp_sitemeta
  • wp_site
  • wp_signups
  • wp_registration_log

Here’s the kicker: there are 9 prefixed tables per every new site!!!

  • wp_6_posts — prefixed with site id
  • wp_posts — first site (not prefixed)

Formula for number of tables in the databse: 8 + ( 9 * n ), where n is the number of sites.

Recommendations

Use a managed host. Multisite is already hard enough as it is, and doesn’t perform on shared hosting.

  • Ask for automatic backups with 1 click restore (ability to download backup)
  • built in staging sites (that magically work with the networked sites)
  • granular deploy to production controls (deploy only specific sites)
  • look for extra security features (automatic ip blacklisting, whitelisting, etc.)
    • Jetpack includes some new shiny of leveraging wp.com’s blacklist data for bad actors.

Recommended wp-config.php additions:

define( 'DISALLOW_FILE_MODS`, true ); // disable the Admin File Editor
define ( 'DO_NOT_UPGRADE_GLOBAL_TABLES', true ); // prevent upgrade functions from doing expensive database queries
// [I missed one here.]

Do not ever do this anywhere in your code base: current_user_can( 'unfiltered)html' ); You will regret this.

Don’t loop through your network sites. Unless you know what you’re doing, you’ll cripple your site performance, if not crashing your site altogether.

Note Regarding Q & A

I didn’t capture Taylor’s use cases for Multisite during Q & A, with thumbs-ups and thumbs-downs on using multisite for various reasons. This is probably worth catching the wordpress.tv talk when it is available.

This post is part of the thread: 2015 WordCamp Seattle Live Notes – an ongoing story on this site. View the thread timeline for more context on this post.

WCSEA 2015: Eric Amundsen — An Introverts Guide to Marketing Your Web Business

I’m at WordCamp Seattle today and will be post­ing notes from ses­sions through­out the day. These are posted right after the session, and could be a little rough.

This is a talk from Eric Amundson, team lead at IvyCat. Find Eric at @sewmyheadon on Twitter and at ivycat.com on the web. Here is the WordCamp.org session description.

I distinctly remember first meeting Eric at WordCamp Portland’s Developer Day three years ago. Eric was quiet, but knew what he was talking about when he spoke up. He came across to me as intensely smart and credible. It’s fun to imagine what he might’ve been thinking at that moment, given what I learned about his perspective in this talk.

What is an Introvert

Introverts generally favor solitude and alone time, live a lot in their heads, and find social gatherings draining.

Extroverts in contrast are very outgoing, don’t like being alone much, and prefer to be among people. They tend to obtain gratification from things outside of themselves. They’re energized by social gatherings.

There are many introverts within the developer community, which makes sense because it’s a solitary activity. There are many companies employing hugely talented introverts all over the world. There are many introverts among us.

Eric at WordCamp San Francisco

About four (I think) years ago Eric felt that IvyCat was at a cross roads. He was in debt, and needed more business. He needed some new employees. He thought he needed to do more than just learn more, or he was at risk of shutting down and folding.

His best idea for what to do about this was to take two days to drive from Gig Harbor, Washington down to San Francisco. During the drive he enjoyed being by himself and “making progress on his audiobooks”.

But once he arrived at the venue, he was completely overwhelmed by so many people. He kind of closed down. He wasn’t rude, but he left early, and kicked himself on the two day drive back for not taking more advantage of the opportunity.

These things are really hard for shy, introverted people. They’re scary. Extroverts should realize many people are like this. Introverts should realize they aren’t alone in this, but they can overcome it without changing themselves but by engaging more to build profitable, growing businesses through relationships — like Eric has.

Marketing

Marketing is relationship-building. It’s trying to build enough trust to get to do business with people.

Seek to build relationships with people with complementary strengths.

Marketing Tactics for Introverts

One on One

One on one in-person interactions are always more efficient. When you meet in person, you can use all of your senses to get to understand and know them, and be more focused on a meaningful interaction.

You can tell so much more about someone from this kind of interaction than from group interactions.

View conferences as rich opportunities not to interact with everyone, but to find people to have meaningful one-on-one conversations with.

Keep it simple

Eric had spread himself too thin, and been the “jack of all trades, master of none.” Growing out of this, and finding focus, was very difficult and painful. But it’s been worth it: Clients don’t want generalists, so more focused bidders tend to win contracts.

So, build one-on-one relationships with people who’ve focused on things you choose not to focus on, so that your focuses can be mutually complementary. You can share meaningful referral relationships.

Have an elevator pitch

Have a simple one-sentence answer to the question “What do you do?”

Introverts hate it when people are on the hunt with their pitch, trying to give as many business cards out as possible in a “target rich networking environment”. Not because they hate people, but because it’s a trust issue. You get one chance with this approach, especially with introverts, and you probably blow it if you’re more focused on giving out cards to the next person than focused on the person you’re talking with right now.

Instead, give people your pitch in casual, natural conversations. Build relationships over time and you can build trust and come to rely on people over time.

Have a goal (or two)

Make a game out of having a checklist to focus on, for what you’d like to accomplish at events — rather than focusing on how nervous you are.

Be Engaged

It takes time to be available to people in this way. Put in the time.

Put down your devices. Despite what you think, you really can’t focus on more than one thing at a time. People see how you interact and what you’re doing with your time, so if you’re on your phone, that says something to people — about how you’re not interested in them.

Write down peoples’ names if it helps. Take notes on their business cards, so you can remember.

Business cards are important still. They allow you to take notes to remember people later, and they also give introverts something to fiddle with if they’re feeling nervous.

Embrace the small groups you find yourself in.

Ask questions. It’s hard to find the courage, but it’s a very effective way to break the ice: Ask hard questions first to get them out of the way. And then, ask open-ended questions. They get others talking, which an keep the focus on them instead of yourself.

Volunteering to help others is easy to do and build cred.

Look Stupid: it’s the new Smart

Imposter Syndrome: Living with the fear of being found out. Both introverts and extroverts deal with this, but extroverts tend to live it out loud, which is the right way to deal with it, whereas introverts ruminate it, which can sink them.

Eric’s story of breaking the fear of looking stupid

At an event with breakout groups, Eric noticed the user and blogger group were chatting up a storm, loud as heck, while the developer group he was a part of was quiet — introverted.

So he said: “Hey, I’m not too proud to ask a stupid question”, and asked one of his developer group cohort a question. This had neat side effects:

  1. He got an answer to his question! Which is what he wanted.
  2. It got people talking — and then it kept people talking. It began a conversation that’s kept going.
  3. Other people attributed smarts to him.
  4. It made the experience fun. It was a great experience.

Keep an Open Source Attitude

Marketing isn’t about making sure everyone knows your name, etc. It’s about building relationships. Contributing. Showing up and trying to help others. If you put good energy out there, it comes back to you.

So many good things come out of it, including: Mutually profitable friendships that you can strike up just by sitting down next to someone and saying hello.

Wrapup

Watch wordpress.tv for an engaging and moving story at the end that I’m not going to try and capture here.

This talk has been a positive emotional highlight so far for me today — a feel good victory for everyone in the room. :)

This post is part of the thread: 2015 WordCamp Seattle Live Notes – an ongoing story on this site. View the thread timeline for more context on this post.

WCSEA 2015: Matt Johnson — Content Migration: Beyond WXR

I’m at WordCamp Seattle today and am post­ing notes from ses­sions through­out the day. These are posted right after the session, and could be a little rough.

This is a talk from Matt Johnson, team lead at Alley Interactive. Find Matt at @xmatt on Twitter and at alleyinteractive.com on the web. Here’s the WordCamp.org session description.

What is migration

There’s an old site, and you’re making a new one. Your old site has content; you need to move it to the new site.

Client attitudes vary. Some are obsessed with migration. These are great because they give you a clear heads-up. Others don’t think about it at all unless you do.

Clients are often surprised when things get complicated, because they imagined it would be really simple. That got laughter in the audience, but Matt pointed out it makes sense: Content migration isn’t something you notice unless it goes wrong, so most people don’t know to think about it.

Content migration can be the fun part of a project

Content migration can involved some of the more interesting problems to solve, such as reverse-engineering weird legacy systems. You may get to write code just to extract it, and then clean up old content from bad code. Then there’s the satisfaction of processing hundreds of thousands of posts with a single CLI command.

Content migration can be the least fun part of a project

Bad things can happen, such as legacy content in Windows-1252 content encoding, when WP speaks UTF-8. Sometimes meta data is completely missing.

“Oh hey, we have this microsite we forgot to tell you about until right now, a week before the launch. Can we just merge it into the main site’s migration?”

With techniques from this presentation, the answer to that can be “Yes (here’s a change order) and yes!”

The basics

Content migration is moving all of your user-generated content from one place to another, accurately. Sometimes the old data maps to the new data really easily. Other times, migration is part of a project that also overhauls the site’s information architecture — as opposed to just a “face lift”. In these cases, newly migrated data needs its structure changed to from the old to the new information architecture structure.

The scale of the project does not necessarily correlate with the difficulty of migration. A project with major information architecture changes and relatively little content can have a much more difficult content migration than a project with a little of content and very little information architecture changes.

The types of migration approaches

The easiest: WXR out, and WXR in. WRX stands for WordPress Extended RSS feed (WRX). WXR files are generated by the Export menu item in the the WordPress Tools menu, and ingested by the Import tool.

You can almost never use this method. Common reasons include that the old site isn’t WordPress; the new site handles images differently on the new site; the new site has a new information architecture, such as:

  • When switching from users-as-authors to Co-Authors Plus (a plugin that allows you to have authors on the byline who are not users in WordPress, which news organizations frequently want)
  • When loading custom metadata into Fieldmanager [?]
  • Re-mapping taxonomies
  • Re-mapping content types (custom post types)

Approaches to migration

Plan A: Make your own WXR

This is unweildy. It requires writing custom code, and it’s code that must write XML, which is hard. You’re also still limited by the format of WXR.

As long as you’re writing custom migration code, why not take total control?

Plan B: Fix up your data after WXR

Run a WXR import, and see what went wrong or is missing, then troubleshoot using a WP-CLI script to finish this up.

A detour into using WP-CLI: WP-CLI is perfect for this, especially its extensability, which allows you to write custom WordPress code to run on demand from the command line. You could write custom code from a tool page, but there are runtime limits, and you need to work harder to create (even limited) UI that you just don’t need on the command line.

Doing this is easy:

if ( defined( 'WP_CLI' ) ) {
    require_once( MY_THEME_DIR . '/inc/class-migration-cli.php' );
}


/**
 * /inc/class-migration-cli.php'
 *
 * In this example, for the sake of brevity, we're omitting
 * output for debugging, which unless you're an evil genius,
 * you need.
 */
class Migration_CLI extends WP_CLI_Command {
    public function fix_my_data( '$args, $assoc_args ) {
        $per_page = 100;
        $page = 0;
        do {
            $posts = get_posts( array(
                // .../ Your WP_Query arguments here.
                'posts_per_page' => $per_page,
                'offset' => $per_page * $page++
            ) );
            foreach ( $posts as $post ) {
                // Do your stuff here.
                wp_update_post( $post );
            }
        } while ( $per_page == count ( $posts ) );
    }
}

To run this command, just do:

$ cd /var/www/my_wp_site.com
$ wp migration fix_my_data

Plan C: Goodbye WXR, Hello ETL

The advantage here is to get away completely from the WXR limitations.

ETL is a venerable computer science term that means extract, transform, load. It’s the most common pattern for custom migration scripts.

Another custom WP-CLI migration class example:

/**
 * /inc/class-migration-cli.php'
 */
class Migration_CLI extends WP_CLI_Command {
    public function migrate_data( '$args, $assoc_args ) {
        $this->connect_to_legacy_source();
        // <code>has_legacy_data()</code> returns true if there's more to process
        while ( $this-&gt;has_legacy_data() ) {
            // Extract:
            // <code>get_legacy_data()</code> gets next, and increments counter
            // This can also do a lot of your heavy lifting in extraction
            $row = $this-&gt;get_legacy_post();
            $post = array(
                'post_type' =&gt; 'post',
                'post_title' =&gt; $row['title'],
                'post_content' =&gt; $row['content'],
                'post_date' =&gt; date( 'Y-m-d H;i:s', strtotime( $row['date'] ) )
            );
            // Transform:
            if ( $row['is_slidewshow'] ) {
                $post['post_type'] = 'slideshow';
            }
            // Load:
            $post_id = wp_insert_post( $post );
            update_post_meta( $post_id, 'legacy_id', $row['id'] );
            if ( $row['is_slideshow'] ) {
                update_post_meta( $post_id, 'slides, $this-&gt;get_legacy_slides( … );
            }
        }
    }
}

Important: update_post_meta() is “item potent” which means you can run it mutiple times and have the same result as running it once, as opposed to creating duplicate posts each time you run it. It does this by checking if the WP post id existsyet for this post, and updating it if does.

if ( $post_id = $this->new_post_exists( $row['id'] ) ) {
    $post['ID'] = $post_id;
    wp_update_post( $post );
} else {
    $post_id = wp_insert_post( $post );
}

[This is brilliant!] This means you can iteratively improve your data if you need to add to it, instead of starting from scratch each time with a clean database.

  • has_legacy_date(): return true until no legacy items left.
  • get_legacy_post(): return an array with the next legacy item
  • get_legacy_slide():returns some special structured data (like slides in a slideshow).
  • new_post_exists(): returns the post_id of the WP post with this legacy id, or false if there isn’t one.

Typical Legacy data formats to work with

  • A MySQL database (any weird schema)
  • A pile of ZXML or JSON files
  • An RSS feed
  • A REST API (yay!)

This post is part of the thread: 2015 WordCamp Seattle Live Notes – an ongoing story on this site. View the thread timeline for more context on this post.

WCSEA 2015: John Jacoby — Keynote

I’m at WordCamp Seattle today and will be posting notes from sessions through­out the day.

“Welcome to WordPress”

This is a talk from John James Jacoby on his personal story with contributing to WordPress, to help us earn from some of John’s mistakes and experiences. He’s contributed to WordPress since 2007.

WordCamp.org session description

Find John Jacob Jacoby @JJJ on Twitter and jjj.me on the web

WordPress History

Before blogs were blogs, there was software called b2/cafelog. Eventually that software was abandoned, but it was open source. Matt and Mike were two guys on the internet using it and liking it who decided they didn’t want it to die, who breathed new life into it. Thus, WordPress came out of a different way of developing software than is common today. It’s more common today for people to contribute to something that already has momentum, not something that’s abandoned.

When John first got involved, it was easy to contribute. It was before tools like unit tests and compile/build tools, which have added difficulty and learning curve for people to get started. WordPress wasn’t great yet, so it was also easy to identify areas for improvement.

WordPress.org was originally just running bbPress, which inherited its database user table schema from MyBB (sp?), its ancestor. By default you don’t see a profile when you visit the author page, but rather a series of the authors’ posts. BuddyPress makes it more about the users and less about the blog itself.

WordPress.org has grown from just being support forums, to running the project by using BuddyPress (plus moving from SourceForge to Trac, adding Multisite, etc.).

John’s personal contribution story

He taught himself VisualBasic as a teenager. He was active on forums and familiar with building forums. He was frustrated with the limitations of forum schemas: Topics were limited to one topic, one forum; you couldn’t have a topic in multiple forum.

John Googled for how to solve this problem — multiple taxonomies — and found bbPress because it was beginning to address this problem at the time. Then, he found his way WordPress MU (“MultiUser”, at the time).

These three pieces — bbPress, BuddyPress, and WordPress — weren’t good at working together, so John focused his contributions on making them play better together.

John never installed single-site WordPress. He’s always worked with Multisite and these three pieces.

Contributing to WordPress: Our motivation, and the difficulties

No one sat in a room like we’re doing at this conference to talk about WordPerfect. It’s remarkable that 200 some people are sitting in a room together talking about a piece of software. (“Let’s talk about the toolbar… and the menus… so great!”)

We do it because we’re all able to see how it works, influence the design, change things, etc.

John found it easy to find people to contribute with a bunch of other people back in the day, because working in isolation is lonely, and because there wasn’t a lot of structure like there is now.

But the process today isn’t super inviting. With make.wordpress.org we’re trying to provide some structure and guide people to get in, but it was easier when there were fewer parts. Now there are different specialized teams, and several companies involved with various focuses.

John seemed keen to validating for people in the audience finding it hard to get involved and contribute that, yes, it’s harder now.

Rather than try to influence every little thing, which used to be easy, today it’s easier to focus on something specific. Skills tend toward specialization. Eventually there will be so much to do in every specific area, there will be people who work full time on just one specific area. For example, with WordPress today there are already contributors who focus nearly all of their contributions on just improving icons.

From Volunteering to a Career

John’s volunteering story: When he was a kid growing up in rural Wisconsin, there wasn’t much to do for fun except break things. So his first experience with volunteering was actually being “voluntold”. But he loved it.

And, he realized that if you want to do something, the easiest way to get it is to just do it. Eventually you’ll become one of the best people at it.

Then, eventually you can transition into an actual career. Start practicing piano and you’ll be terrible on day one, but keep at it, and eventually people might want to pay you to play for them. It’s the same thing with code.

John started answering questions in the WordPress forum. It was easy to lurk long enough to make sure he knew the right answer, then help others. Eventually he became knowledgeable enough to contribute patches. Today he’s one of the community’s leaders.

Health

or, what I will call WordPress/Life Balance.

Contributing to WordPress becomes a cycle of reward. You do something good, and people say thank you, and that feels good, and so you do it again, and repeat. This can become an unhealthy sort of addition: some people may end up spending too much time at their computer, neglecting other responsibilities, or their health.

The nature of remote teams makes it more difficult for people to notice when you’re going crazy, or looking unhealthy. (Or not having a good work/life balance with how you spend time.) We can hide behind our computers.

On the mental health side, imposter syndrome can creep in and devalue our sense of self. This is basically a constant feeling that you are not awesome, because you’re surrounded by brilliant people, that you can’t compete with directly.

So it’s important to remember to focus on your health. It’s important to maintain perspective on how awesome your contributions really are. You are awesome, because you have practiced and gotten good at what you do. It’s also important to define success for yourself as something broader than your work in the WordPress world.

Defining Success

Define success uniquely for yourself. Identify what you want to do to feel good. If you don’t do this, you won’t be able to tell whether your hard work is good, or useful. And you may be measuring yourself against your coworkers and feeling like you fall short — even against people who have an entirely different focus from you.

Go easy on yourself with what success should look like. Allow yourself to be human — don’t expect a superhuman experience where things always go as you plan. We all have bad days, and need days off.

This post is part of the thread: 2015 WordCamp Seattle Live Notes – an ongoing story on this site. View the thread timeline for more context on this post.