Introducing the WordPress Security White Paper

We’re very proud to share the WordPress Security White Paper with the WordPress community!

The white paper is an analysis and explanation of the WordPress core software development and its related security processes, as well as an examination of the inherent security built directly into the software. Decision makers evaluating WordPress as a content management system or web application framework should use the white paper in their analysis and decision-making, and for developers to refer to it to familiarize themselves with the security components and best practices of the software.

The WordPress Security White Paper is available directly on the site. In addition, the HTML and PDF versions are available at Automattic’s Documattic Updated! Now on the WordPress GitHub repository for any updates and/or additions.

We’d really love to encourage and help share translations of the white paper to the global WordPress community. If you have a translation to contribute, please add it to the WordPress GitHub repo so others can benefit, too. Pull requests welcome!

The text in the white paper (not including the WordPress logo or trademark) is licensed under CC0 1.0 Universal (CC0 1.0) Public Domain Dedication. You can copy, modify, distribute and perform the work, even for commercial purposes, all without asking permission.

Thank you to all who contributed to the initial release and compilation of this document: Barry Abrahamson, Michael Adams, Jon Cave, Helen Hou-Sandí, Dion Hulse, Mo Jangda, and Paul Maiorana.

Below is the table of contents for the white paper, which you can find here.

Executive Summary
An Overview of WordPress
The WordPress Core Leadership Team
The WordPress Release Cycle
Version Numbering and Security Releases
Version Backwards Compatibility
WordPress and Security
The WordPress Security Team
WordPress Security Risks, Process, and History
Automatic Background Updates for Security Releases
2013 OWASP Top 10
A1 – Injection
A2 – Broken Authentication and Session Management
A3 – Cross Site Scripting (XSS)
A4 – Insecure Direct Object Reference
A5 – Security Misconfiguration
A6 – Sensitive Data Exposure
A7 – Missing Function Level Access Control
A8 – Cross Site Request Forgery (CSRF)
A9 – Using Components with Known Vulnerabilities
A10 – Unvalidated Redirects and Forwards
Further Security Risks and Concerns
XXE (XML eXternal Entity) processing attacks
SSRF (Server Side Request Forgery) Attacks
WordPress Plugin and Theme Security
The Default Theme
The Theme Review Team
The Role of the Hosting Provider in WordPress Security
A Note about and WordPress security
Core WordPress APIs
White paper content License
Additional Reading

A special note: As you can see in the table of contents, the white paper is specific to the open source core WordPress software. The core WordPress software is the foundation of and there are additional Security FAQ related to VIP here.

Join the VIP team at an Upcoming Event!

We hope you’re staying out of the snowdrifts and keeping warm wherever you are, and we wanted to make sure you knew of some upcoming events the VIP is organizing or participating in, in the near future. We hope to see you and have a chat at any of these events!

We’re meeting & greeting in Seattle! If you’re in or around the Seattle later this month, several members of the VIP team are hosting an informal meet and greet on February 24th! Please get in touch if you’ll be in the area so we can send you an invite.

The Big Media & Enterprise (BM&E) WordPress Meetups are a great way to meet other developers, product managers, and editorial teams who use large, high-traffic WordPress sites. The evening is usually centered around 3-4 flash talks followed by discussion and networking. Past BM&E events have been held in NYC, Boston, San Francisco, Toronto, and London.

Boston’s BM&E is March 10th, after two reschedules due to snow. We’re hoping the date sticks (and not the snow)! You can join the Boston group on & RSVP here.

March Big Media & Enterprise Meetup

Tuesday, Mar 10, 2015, 6:45 PM

Workbar Cambridge
45 Prospect Street Cambridge, MA

54 Members Went

The Big Media & Enterprise meetup is open to developers, product managers, and editorial teams who run large, high-traffic WordPress sites. If you plan on attending, please be sure to RSVP.Doors open at 6:45 p.m., presentations will begin at 7 p.m. We will have 4 “flash talk” presentations, each lasting 10 minutes, followed by 5 minutes of questio…

Check out this Meetup →

London’s BM&E is also March 10th. We’re headed back to London for another event! You can join the London group on & RSVP here.

March 2015 Meetup

Tuesday, Mar 10, 2015, 6:30 PM

Westminster HUB
80 Haymarket #1st floor SW1Y 4TE London, GB

35 Members Went

The Big Media & Enterprise meetup is open to developers, product managers, and editorial teams who use large, high-traffic WordPress sites. If you plan on attending, please be sure to RSVP as space is limited.Doors open at 6:30 p.m., presentations will begin at 7 p.m. We will have a number of “flash talk” presentations, each lasting 10 minutes, fo…

Check out this Meetup →

We’ll also be coming back to San Francisco on April 8th for a Big Media & Enterprise WordPress Meetup. You can join the San Francisco group on & RSVP here.

April 2015 San Francisco Big WordPress Meetup

Tuesday, Apr 14, 2015, 6:00 PM

Automattic Lounge
132 Hawthorne St San Francisco, CA

42 Members Went

The San Francisco Big WP meetup is open to developers, product managers, and editorial teams who run large, high-traffic WordPress sites. If you plan on attending, please be sure to RSVP as space is limited.Doors open at 6 p.m., presentations will begin at 6:30 p.m. We will have 4 “flash talk” presentations, each lasting 10 minutes, followed by 5 …

Check out this Meetup →

Also in April, a few VIP team members will be at the National Association of Broadcasters (NAB) Show in Las Vegas, from April 13-16th. Will you be there? Get in touch.


And our flagship event, the VIP Intensive Developer Workshop, is happening in May 4-7th and still has space available. More information on the event, and you can pre-register here.


Several of the VIP team will also be at WordCamp London from March 20-22nd. If you’re attending, please say hi!


To keep up-to-date with our events, follow @WordPressVIP on Twitter and check our VIP Events page. and Deadline Hollywood Launches: Lessons Learned – Now With Full Transcript

Gabriel Koen from PMC (, Deadline Hollywood) presented “Launches: Lessons Learned” at the recent Big Media & Enterprise Meetup in San Francisco, California, now available with full transcript. 

View the presentation slides below:

I come here from Penske Media I’m going to be talking essentially about our product launches and what’s gone wrong and how we’ve used that to essentially adapt what we do and how we do it.

For those of you who haven’t heard of Penske Media, you might have heard of some of our brands. This includes TV|Line, Deadline, Variety, BGR, entv, Hollywood Life. We run about 30 events, including some that are on, I don’t even remember what, CW I think, and a couple of others.

To give you an idea of what our launch schedules tend to look like over the last few months, everything from new major sections on our sites to actual site redesigns and brand new sites themselves.

We launched mundial section for Variety Latino, a Contenders Awards aggregation section for Variety. Back in May we did a full on site redesign launch for TVLine events, like our power of women event, International Editions on Variety, a new section for our events. And generally, every month we do at least six or so brand new products or sections for our sites. Anything from just a new page, to a new major feature, to brand new site.

So basically getting on to what we’ve done, these are in no particular order. So one of the things that’s the most common that we’ve run into in the past especially is you know, we go through all this trouble launching a new feature, a new section on the site and 3 months down the road we realize hey we’re not getting any mobile traffic to this section.

So obviously, we forget to add a link to it, to our mobile themes header or side bar or you know even forget a mobile optimized version of it.

Sometimes the solution is changing the way that you develop or think about your products in general.

It’s odd but it happens and then essentially we’ve targeted that by we’re making a push to do a responsive theme for all of our sites at this point and I think the number one driving reason for that, aside from higher mobile engagement as the years go on is just that, you have to account for different devices and different sizes when you’re dealing with responsive. You know, it gets bakes into your QA processes and your thought patterns.

So the key take away from that is just not every problem that you encounter has a solution like “oh yeah I need to remember that”, sometimes the solution is changing the way that you develop or think about your products in general. More so than “ oh, I have to remember to do this on launch day”.

Another big one, especially a big problem for sites like ours that are ad-driven for our revenue, we forget to loop in different team members or different people within the organization and then we find out they were completely unaware of the launch and you know, we didn’t think that they needed to know.

So you know something happens like ads don’t even show up on your new section, or the wrong ads show up in the wrong places on your shiny new website design. So in order to combat that we started doing cheat sheets where prior to each launch, we just put together a simple one-sheeter that explains okay, here’s all the key dates, people involved and milestones that are going to get us from the concept to actual page on site.

So the overall take away there is just every team involved knows who else is involved and what other teams are there someone in there is bound to know “hey so and so from the editorial team or from our vince coverage team is gonna need to be involved in this and it just helps circulate the communication there.

We just put together a simple one-sheeter that explains here’s all the key dates, people involved and milestones that are going to get us from the concept to actual page on site.

We have had launches where we forgot to actually turn it on whether it’s actually activating the theme or enabling a core feature for the theme or dragging the widget to the sidebar.

And the problem there is there wasn’t one person who was owning that launch or that feature, that particular thing. So from then on, we just have to make sure that every thing that’s on our checklist, everything that’s happening, has one person that owns it, since we found that everyone on the team may know what’s going on but they may think that someone else is actually going to do it.

And sort of adjunct to that is you know, it’s useful, we’ve found that, you need to have someone who’s, with a small team especially, you tend to get focused on all the little pieces needed to pull the whole thing together, but the way things like this get missed is you tend to not have somebody just keeping the eye on the overall thing or project or launch and just making sure all the piece fit together.

And we’ve had launches where the key stakeholders never actually saw the feature we were building before we built it and pushed it out. So obviously hilarity ensued once actually saw that we launched a major section of the site that they were responsible for or feature that they had to suddenly start populating content for etcetera.

So essentially to combat that, we realized in addition to just making sure that we flip the switch and loop in ad ops teams and editorial teams and what not, we need to make sure that communication was actually part of our list. You know, so at a certain point, it’s like one of the steps is make sure that you know who to communicate this to make sure that you actually get them to review it at certain points.

 From then on, we just have to make sure that every thing that’s on our checklist, everything that’s happening, has one person that owns it

So you know, treating your milestones and key communication points as actually just something else you do just like QAing the feature, just like building it, just you know, every other piece of it.

And one of the last two are kind of some of the more embarrassing ones at least from my point of view. So the times when we broke something and just kind of hoped that nobody would notice while we were scrambling to fix it.

And of course, meanwhile, the actual stakeholder sees it and you know, starts being very vocal about seeing it, which very quickly escalates the situation. So it’s kind of obvious in hindsight, but you just have to you know, own up to what you’re doing. Whether it’s good or bad, when things are going wrong, when things are running late, you just have to make sure that you’re, you know, keeping constant communication going with your key stakeholders for a project.

Key stakeholders, just a sidebar for a second, could be anyone from if you’re launching a new section, well it’s going to the the editor or writer of that section it could be the general manager of the site. Just whoever it is that is most invested in the success of that project or product.

Whether it’s good or bad, when things are going wrong, when things are running late, you just have to make sure that you’re, you know, keeping constant communication going with your key stakeholders for a project

And then I think the key thing that we also learned from it is overall, those, it stings a lot less whenever you go to someone and say “hey we just noticed we did this or something happened, we’re actively working on it and we wanted to let you know and keep you in the loop” than them suddenly looking at their site and seeing a mess, you know.

Other ones are right after our launches. Having the general manager of the site say, “hey I noticed I’m getting fewer page views can you look into it?”

What’s going on? Well many things. We found a couple times where we’ve accidentally blocked search engines from indexing things we had meta tags or robot […] files from our dev sites that made it into production and we just never looked because who would do that?

Other times, we left analytics off of pages, especially when doing ajax operations and you know, things that aren’t a strict load where you still want to track page views or other engagement based off of that.

So essentially what we’ve found there is kind of a two-fold answer because there’s multiple problems there. First, it is not making assumptions. Maybe you looked at something or scanned it at one point and said “oh yeah, that looks good” and you move on.

Or maybe you’re just like, “yeah of course we’re tracking page views on this why wouldn’t we do that?” And the kind of take away that we really got driven home in those scenarios is, product launches do extend past the launch date.

Not only from just keeping an eye on things and just making sure things are working, but just from this point of view of from if you’re a product person, measuring the success of the product or project that you’ve just pushed out.

Is it working? Are people actually using it? And being able to respond to those things that you see, whether it’s in analytics or whatever so, that’s pretty much it.

Just to quickly go over how we at PMC have overall handled dealing with these things we’ve sort of, we start with the idea of let’s just do something and let’s just do it as a small team and see what works and what doesn’t work.

As we make mistakes, we introduce process to combat those mistakes that happen frequently and we constantly strive to reevaluate whether what we’re actually doing is working or not.

So we know that as we grow in size and as our sites grow in complexity, there’s just more process that you have to do to be able to handle these various scenarios. But we also know that process can kind of get in the way and the more process you have, the less likely you are to actually follow those processes, so it’s really finding a very happy balance between the two so that you’re actually being effective with the things that you’re trying to do.

So I’ll just kind of go over these quickly you know, it starts with project planning we typically work backwards and forwards from our launch date to make sure that our timelines meet somewhere in the middle, to make sure that we’re identifying all the people who are involved in the project and getting them looped into the timeline discussions.

We put together our little one-sheeter cheat-sheet with stakeholders, dates, URLs for being able to test things and check things dates, when they can go in and look at it, that type of thing.

We have one checklist for what we need to do before we launch, things like who we need to coordinate with to get on the actual launch time, it’s usually the VIP folks and then we need kind of configurations that we have to deal with.

We have our timeline for launch day, it’s literally a minute by minute calendar with who’s responsible for something and what the status of it is. We use Google Docs for all of this because our company is on Google Apps for business, but previously we used things like Trello and whatever works.

The key to all of this is to make it easy for people to access. Since we’re on Google Apps and using Google spreadsheets, we don’t have to do anything special for someone to log in and see a sheet or someone to edit it or for someone to have access to it.

Then we have our actual launch checklist, just a general overview of what needs to be done and who owns that piece of testing or review and we go through that once right before we launch and once right after we launch.

One of the newer things that we’ve introduced that’s been really successful is our support structure. Essentially we’ve started creating a chatroom, sometimes it’s a Google hangout sometimes it’s a Skype chatroom, it depends on who the stakeholders are and what they use every day.

On launch day, we everybody gets into the chat room, and that way whenever somebody comes across a problem or something, they just type it in or say what they’re seeing and you have that instant one-on-one communication.

We also try and identify one or two key people on the team, like if you’re doing a site launch, it might be the general manager of the site and the lead editor.

They’re the conduit between the writers and the other staff on the site and us so it lessens the noise that goes on on those launch days and our ability to find out what is actually a problem.

So that is basically it. Any questions?

Q: One thing on the VIP team that we’re really bad at right now is celebrating our launches internally So when we put in weeks or even months working towards a launch, we’re not very good at patting on the back and saying nice job, good effort, all that stuff.

Do you guys do anything like that to celebrate the launch or sort of like, boost internal moral?

A: That’s actually a very good point, that should actually be part of this because it’s certainly something that all of us on the team have strived to make part of our launch process. You know, we’ll send out an email and we’ll include the CEO and other people on it just saying “hey, this went live”, if there were people who were really, you know, worked 24/7 to get it out, we’ll make sure they’re acknowledged in that.

Our CEO is actually really great about it as well, he’ll respond and say fantastic job, especially, Amit Sannad or whoever else on the dev team that has been working weeks and weeks to get the thing out.

You know, we’ll usually, it’s tough because we have a distributed team as well, so those of us, like most of the product team is based out of Los Angeles, so we’ll get together and go out and have drinks or something like that.

We just try and, we’re still working on figuring out how to better include the people who are located outside of our office area. So far, we’ve just been making up with small gifts and tokens of appreciation thanks and emails and pats on the back and so forth, but we ‘re trying to find ways to do better on that.

Q: Do you use automated testing at all to help eliminate some of those issues?

A: We don’t. Sorry, he was asking if we use any sort of automation or automated testing to help with these things, and you know the short of it is we don’t. There’s a lot of reasons why we don’t and none of them are really that good.

Most of them boil down to like we haven’t found out how to automatically test for some things. We have introduced some types of automated tests like we have pingdom alerts that look for the ad strings on our various pages so we know if ads aren’t rendering and things like that.

But we’re still not at the point where we’re using any kind of unit testing. We’re not using any kind of selenium or UI testing. It would definitely help quite a bit with some of these things.

Any other questions?

Awesome, thank you.

See the presentations from previous Big Media & Enterprise WordPress Meetups. For Big Media & Enterprise WordPress Meetup groups in other cities, see the full list on VIP Events and join your local group. 

Want more information about WordPress services for media or enterprise sites? Get in touch.

The Dream Internship: Work at Automattic (Summer 2015 and beyond)

Applications are now open for the VIP internships! We’re currently focused on applications for the summer 2015 period, but we’ve also opened up a dedicated internship application form which will allow interested students to apply for internships on a rolling basis during the year.

Our company Automattic — which runs, Akismet, VaultPress, and many other services — is looking for a few stellar student interns, specifically to work with us on the VIP team. VIP provides hosting and support for high-profile, high-traffic WordPress sites, including,,,,,, etc.

Where will you be working you may ask? Anywhere! We are a distributed company and are happy if you work from wherever you are — as long as you have a good broadband connection.

For more information and to apply for one of our paid internships, please refer to the dedicated Internships page here on the VIP site.

We look forward to seeing your applications! 

Inside GigaOm’s Search and Alerts

Casey Bisson from GigaOm presented “Search and Alerts” at the recent Big Media & Enterprise Meetup in San Francisco.

See the presentations from previous Big Media & Enterprise WordPress Meetups. For Big Media & Enterprise WordPress Meetup groups in other cities, see the full list on VIP Events and join your local group. 

Want more information about WordPress services for media or enterprise sites? Get in touch.

Using APIs to display sports data through WordPress with USA Today

Matt Harvey, Director of Product, USA Today Sports Media Group, presented how USA Today uses APIs and WordPress to display sports data in “Keeping the Score: Using APIs to display sports data through WordPress,” at the recent Big Media and Enterprise Meetup in San Francisco.

See the presentations from previous Big Media & Enterprise WordPress Meetups. For Big Media & Enterprise WordPress Meetup groups in other cities, see the full list on VIP Events and join your local group. 

Want more information about WordPress services for media or enterprise sites? Get in touch.

Code Review For Teams – Now With Full Transcript

Mo Jangda from Automattic gave a presentation and lead a discussion on Code Review at a recent WordPress Big Media Meetup in New York City now with full transcript. 

So to get a sense of what the room looks like, how many people here are developers? So the majority of people, probably 70-80 per cent. How many people are editorial? A few people, that’s good. How many people are management? You guys in the suits.

If you’re a developer, how many people have a code review process built into their teams right now? Not everyone, which is disappointing. So that’s what I’m here to talk about.

The goal should be to have at least one other person than the person who wrote the code look it over and to review it for things like quality standards, security concerns and performance and so on, things like that.

You can’t code review if you’re doing it live. So, ultimately the goal with code review is basically to improve the quality of your code.

So if you’re editorial, right, the idea is that you’re not going to push something out any sort of published articles without going through the copy editing phase, unless you care about money, in which case you don’t care.

You want to make sure the stuff you’re putting out is good quality, and that’s where code review is – that’s why it’s sort of nice to do.

The goal should be to have at least one other person than the person who wrote the code look it over and to review it for things like quality standards, security concerns and performance and so on, things like that.

So it doesn’t necessarily have to be a junior to senior. It’s a learning opportunity for both, different skill sets as well.

And the secondary goal is you sort of becomes that you’re learning from each other as developers. It doesn’t necessarily have to be a junior developer passing off their work to a senior developer and them telling them basically everything they did wrong.

It can actually go the other way where a senior developer passes off their work to a junior developer and says here’s the code I’ve written,can you look it over and see what I’m doing?

It gives the junior developer an opportunity to look at how the code is being written by the senior developer and learn from them, right?

So it doesn’t necessarily have to be a junior to senior. It’s a learning opportunity for both, different skill sets as well.

The other thing to sort of keep in mind is that code reviews shouldn’t be something else that you tack on. It’s part of the development process, right?

So it’s not something that you should consider a tedious thing that should be going on, it’s something that you should have built into your processes as part of your deployment, as part of your coding, so something you do on a regular basis.

There’s different ways you can do code review obviously. You can have a gatekeeper-type approach. Where you have one person who’s sort of like master of the code review, so every bit of code that gets written goes through that person.

So that person can be a senior person, can be a rotator role so all code goes to that person, they review it, send feedback and iterate on the code that way.

One flow, or one specific approach to code review is not going to work for everyone. So you’ve got to find something that works for you.

You can do some things like peer review, where you have teams of developers put together, so one person is buddied up with another so any time a person needs feedback, anytime a person is finished working on a patch or working on a new feature they can pass it off to their fellow developer and say, hey can you give me feedback.

You can have a committee-based approach, where you have multiple people giving feedback on patches. If you’re using something like Git or GitHub you can use pull requests. GitHub makes it really easy to comment on code, and pull requests and commenting and so on.

You can also do pair programming, which I personally dislike, but it works for a lot of people if you’re into extreme programming or agile processes and stuff like that. You can have people working on code at the same time and the cool feature of that is that you’re essentially doing code review live because you’re questioning each other as you’re writing code.

One person types up something, the other person sort of questions: Okay, why did you write that?

There’s different points in time where you can actually use code review so you can actually start doing code review before writing a single piece of code and you’re essentially talking out the concepts with each other.

You know, we planned out the specs and functionality, we’ve thought about what my classes are going to look like, what my functions are going to look like.

So it’s a good opportunity to actually talk with you, what approach you’re taking to code review, to talk with the person with whom you’re doing the code review to see you know, does this make sense?

Obviously you do things like pre-commit reviews, look at patches, so before you even commit the code send the patch over, send over and review it that way.

It’s a great way for your team to actually write better code and build a more cohesive unit.

We also do post-commits, so once the changes are done, committed, you can review the pull request or the actual committed code.

You can also do post-deploy, so if you don’t actually have time, to do a full code review before pushing it out, you can still go back and do code review on stuff that’s pushed live and make changes over time.

The most important thing obviously is you got to find a flow that sort of works for your team.

So one flow, or one specific approach to code review is not going to work for everyone. So you’ve got to find something that works for you.

Doesn’t necessarily have to be anything very specific. It can be sort of totally casual, like a conversation between two developers.

So it’s pretty important to find something that works for you. You also don’t need fancy tools, you don’t necessarily need to go out and get your own license of Phabricator, which is a code review tool that Facebook has built up.

To be honest, it can just be as simple as two developers passing around a patch to each other. Looking it over.

So it doesn’t have to be complex, but if you want it to be complex, you can.

But you can keep it simple, find something that works for you and so on. When it actually comes to doing the code review, there’s a few things to keep in mind.

Throw your ego out the door.

The most important thing, and this goes for both the person reviewing the code and the person receiving feedback is throw your ego out the door.

There’s no such thing as ego and emotion during code review. That’s the most important thing to keep in mind.

The reviewer is not smarter or dumber than the person whose code they’re reviewing. In the same sense, the person whose code is being reviewed they’re at the same level. So ego is not involved, it’s not supposed to be personal. It’s supposed to basically be about questioning the code, right?

Not questioning the person. So one thing that I usually try to keep in mind while I’m personally reviewing code is that I usually recommend to people is that when you’re phrasing your feedback never include the word “you” .

So it’s not YOUR code, it’s THE code. Right? So that takes away the personal aspect of it and it makes the reviewer feel less attacked.

Because getting your code reviewed can be a very scary thing, but it shouldn’t be.

You should get to a point, where you should actually be proud to have your code reviewed and proud of the code you’re presenting to your teammate, senior developer or boss and so on.

To show that this is the amazing thing that I’ve done, and you know what, I expect there to be flaws.

Chances are, there might not be, but you know, if there are issues with it, it’s something you know, the mistakes that you find, is something that I can learn from.

The other thing to sort of keep in mind, is that you as a reviewer want to be critical about things, right? So question the decision that the developer is making.

Why did they name that variable that way? Is that a valid variable name, right? Why is this function name so long? Can this be abstracted? Right? So design decisions like that can be a good way to root out potential problems in the code.

But obviously, you don’t want to get too caught up in the minor details, so getting caught up on spaces over tabs which we’ve had problems in the past with before, in VIP, where some developers would reject code commits for using space instead of tabs, you know that’s a minor implementation don’t get too caught up on that.

Point it out, but it’s not going to be a blocker. But it’s important that coding standards and best practices are still followed, so it’s important that your team is following those that in your reviews, you’re actually flagging those and so on.

The other thing to keep in mind is as a reviewer, don’t worry about catching everything. ‘Cause you’re not. I don’t mean to brag, but I think I’ve reviewed about 20,000 commits on VIP. Of the many commits that I’ve reviewed on VIP there’s been stuff that I’ve missed and that’s naturally going to happen.

Because manual code review is not going to be perfect. Automated code review is not going to be perfect.

There’s no such thing as ego and emotion during code review. That’s the most important thing to keep in mind.

Things will get missed, things will go live that will break your site. But that’s, an opportunity to learn from so the next time you review your code you’re going to be extra conscious about it and try to find that mistake that you made and try and prevent it from happening again.

So that’s the other thing as a reviewee, you should sort of keep in mind. When a mistake is found, and pointed out to you, you should try and avoid making that mistake again. It’s a very important thing. You should be using it as a learning opportunity, right?

If you are making the same mistake over and over again. Chances are there’s something wrong. Either with your processes or with how you’re developing. That’s something you should work to change.

Never focus on the negatives.

As a reviewer, if you find the same problems over and over again, that’s when you need to question what’s going on with this developer? Why are they not sort of picking up the problems that I’m seeing? Another thing I sort of do, and I mentioned this earlier with not making it personal, try to keep in mind try to stick to the positives, right?

Never focus on the negatives. What’s a good example? It’s important to start a phrase with: How can we do this better? Instead of this is dumb, this is stupid.

So again, avoiding the personal attacks, trying avoid getting too emotional about things and staying focused on this code could be optimized more instead of this code will break your site, things like that.

I think that just about covers it. That’s sort of one of the biggest things I wanted to go over. But also, I guess it’s ultimately important to find something that works for you.

Code review is, it’s something that’s near and dear to my heart because I’ve been doing it for the past three years as a reviewer, it’s the best way to learn best practices and learn new code.

I’ve actually learned more new WordPress functions by looking at other people’s code than I have through just following news and following WordPress codex and things like that.

So it’s a great opportunity for reviewers to sort of look at how other people code or how other people think when they’re approaching problems.

And as a reviewee, it’s a humbling experience and a great opportunity to learn. And ultimately, it’s a great way for your team to actually write better code and build a more cohesive unit to ultimately do cool stuff.

Thank you.

Q: It’s easy to think that if you don’t review everything, then you should just give up because if you’re not reviewing everything, then the problem is going to be in the spot you didn’t review.

So, I think that maybe some of the thought process behind not everyone here doing code reviews I think it’s something that I think everyone wants to do so I was wondering if you could provide tips is there any sort of lightweight code review process? Is there anything that doesn’t require every commit to be reviewed by somebody else?

A: So that’s where I would look at post-deploy commits or post-deploy reviews so reviews don’t necessarily have to block things from going out but you still take the opportunity to go back at some point.

Let’s say you have a work week, you set aside two hours in the week Friday or something where you as a team, get together and review each other’s code, and look at various commits and stuff.

So to give you an example, on, the platform, we have about a 120 or so developers. I may be fudging our numbers. We have a lot of developers pushing out code daily. We probably have anywhere from 60 to 100 to 200 commits going out every single day and we haven’t really actually found a good mix, or good flow for us what makes sense for a code review.

So we end up relying on post-deploy code reviews where the idea is certain developers will take some time on the side, a couple hours a day, a couple of hours a week to sort of look, skim through commits that people have done.

They’ll just look through the log to see a commit message or if there’s a particular feature they’re interested in or that they’ve worked on in the past to sort of give it a quick skim and see if there’s something that they can flag for the developer to work on.

So it doesn’t necessarily have to be a very time intensive or blocking process. Ideally, you want to get to a point where it does become integrated into your development flow but it doesn’t necessarily have to.

To be honest, spending even an hour a week is a perfect starting point.

Q: Is there a good size team for doing code review? Like if you have fewer people,are there better methods? Like for smaller teams, to do it so it’s not interfering, so it’s not just like back and forth constantly?

A: Again depends on your type of workflow and your team dynamic.

In that case, it’s like if you’re using like Git for example it’s a simple pull request is probably a great way to go.

If you’re working on a feature, send a pull request and have the guy sitting beside you say can you take a quick scan. Or if there are specific things that you are worried about, have them look it over and point out specific things.

Like I’m not really sure about this particular function, I’m not sure about how this class interacts with this feature, can you just take a look at it.

So it doesn’t necessarily have to be you’re reviewing the whole commit, just skimming through something and seeing if anything jumps out.

Participant: I have a small addition. So one thing that I find really helps out if you have a definition of the process so for example if you have code review documentation, like what kind of code structure you need to keep, templates defaults you need to use also speeds up a lot of reviews because you can automatically assume the person is following the structure, because they technically know about it.

The easy way to speed it up is to also just I mean ignore JavaScript and CSS, because if you have a lot you can just ignore CSS. If your quality assurance team passes it and it looks fine, also JavaScript if you really don’t have time.

A: I mean for CSS especially, as a code reviewer when I look at the VIP code, I basically ignore CSS, because from my perspective, I care more about the security and performance.

So you’re right, there are things you can sort of ignore, if you are a designer and like reviewing CSS, then go for it. But also, like you said, standards are really important, and processes are really important.

Especially, as you grow as a team, again doesn’t necessarily have to be super formal and super strict, but it helps to have some sort of definition in place so you can follow, your team knows what to do.

So they’re actually trying to have their code reviewed, instead of pushing it live.

Steph: Out of curiosity, how many people here have had Mo review their code?

Participant: He’s the best!

How many of you have had code rejected by me?

Participant: How many people want to beat Mo up after this meetup?

Participant:I’m in

Participant: Actually out code was reverted 2 min before the meetup.

What I usually tell people at like VIP workshops and stuff is that your ultimate goal should be to make me so happy that I would never want to revert that code ever.

We actually revert code once a day. The interesting thing is that if you have some sort of code review process, we actually notice when VIP’s adopt some sort of code review process, internally, so they have someone on their team review their code before it comes to us.

The quality, there’s a significant increase. The number of issues we have to flag, the number of reverts that actually end up happening to that code goes significantly down.

It’s a testament that code review can actually work and keep us happy and keep your code getting deployed much faster.

If you’re not on VIP, still a great opportunity to make sure your team is working together, make sure your team is writing good code. ‘Cause the last thing you want is to push out a security hole and all of a sudden has your homepage hacked the Syrian army or whatever.

See the presentations from previous Big Media & Enterprise WordPress Meetups. For Big Media & Enterprise WordPress Meetup groups in other cities, see the full list on VIP Events and join your local group. 

Want more information about WordPress services for media or enterprise sites? Get in touch.

USA Today’s World Cup – Now With Full Transcript

Ephraim Gregor from USA Today presented “World Cup and VIP”  at a recent Big Media & Enterprise Meetup in New York City, now with full transcript. 

Hi everyone, I’m Ephraim and I’m from USA Today Sports media group. USA Today Sports Media Group is basically a subgroup within the USA Today proper, and we formed about two, two and a half years ago with the purpose of essentially improving and consolidating USA Today’s fairly extensive sports offerings.

Now, when we first started that when we first started that, basically we looked at all our current acquisitions, as we acquired a lot of little many one off, that we thought would be a good acquisition.

It had some interesting moments and so we essentially looked to WordPress for both unified code,easy to use editorial tools a good plugin architecture.

We first of all looked at the code base which was basically pretty much everything under the sun and more and decided that we needed to consolidate, improve and move to one code base. It had some interesting moments and so we essentially looked to WordPress for both unified code, easy to use editorial tools a good plugin architecture and after developing some independent WordPress, we then moved to VIP.

VIP basically allows us to spin up very rapidly and develop across one central theme which we call Lawrence and develop many many small sort of look and feels that we develop and integrate and display modular systems within the WordPress.

We first of all looked at the code base which was basically pretty much everything under the sun and more and decided that we needed to consolidate, improve and move to one code base.

As it says, we have 3-6 styles and we’re adding more every single project with additional integrations as we go on. Sports, specifically, as a data-driven architecture is essentially, interesting because not-only do we have the sort of standard article content-driven approach, we also have to deal with fact that we are trying to deliver, ideally, real-time data about every single sporting event we’re going to report.

In general, right now, our platforms tend to be divided into specific sub categories so we have to have one platform that can deliver soccer, one platform that delivers baseball, one platform that delivers fighting stuff.

So that’s certainly a challenge. So what we’ve done is essentially built off a central theme with multiple plugins to then allow us to turn on and off various sorts of external systems that can deliver this data into the WordPress flow and then deliver that to our users.

So recently I was the lead dev on the World Cup offering we have put up for obviously a sporting event that’s happening right now. What that was, was interesting for several reasons.

First of all, we had to integrate both vendor and internal data to display that with the latest scores, articles, stuff like that. We also had to basically develop a system in place to allow us to display that to the users while maintaining editorial control over that.

A lot of the data was driven by third-party vendor based out of the UK. We also had the problem of essentially turning this into one of our first hub sites. By which I mean, we have a lot of content spread throughout our network. and we wanted to basically flow that content into our own, into World Cup, while also maintaining the fact that these are external links to their own sites and maintaining that sort of multiple umbrella we have.

So what we ended up doing is leveraging both VIP’s offerings and our own, to extend to plugins and syndication things, to build that out into an experience for users that would allow essentially the mobile WordPress flow of content generated by authors directly syndicated to the user, into content distributed across all of our sites both WordPress and non-WordPress and display to the user within the whole post flow, while allowing the user to go to that and go to an external site.

It was interesting. Other things we implemented was also basically increased sort of data migration we had because we basically had the challenge of both integrating the vendor, as mentioned as well as our own data, which we get from various vendors, editorial-driven, code, all bits and bobs.

Generally, the general architecture approach we take for data is to have it stored in external databases and have that be their own CMS that we manage internally as opposed to trying to put that within the WordPress architecture.

We also are starting to move slowly onto other divisions within USA Today, and are seeing a good thing and wanting to get a slice of that pie.

While there is some content that definitely fits, like the custom post types, taxonomies and stuff like that, generally for sports data that’s somewhat unwieldy. So we generally prefer to spin up our own either Mongo or MySQL based solutions.

So our goals going forward is to basically continue operating and migrating our solutions onto the WordPress VIP platform I don’t know the exact count of sites we have right now. I think it’s either between 15 and 20 with more spinning up every week.

We also are starting to move slowly onto other divisions within USA Today, and are seeing a good thing and wanting to get a slice of that pie.

So we are moving Life, Entertainment, that sort of thing as well. Obviously none of this affects, like if you go to As a whole, that is not WordPress, that might be something in the future. But right now it is a separate platform, but there’s a lot of little subsections that are very much looking and keen on the WordPress as a platform.

We’re also continuing to improve Lawrence as keeping that as a core modular theme, which we’re iterating off and adding new sort of API integrations for our own content and data driven by others, and we’re pretty sure that we can develop pretty much anything within this platform.

So I’m out of time but I will take questions now.

Q: Brad from Alley Interactive, what’s Lawrence named after?

A: Lawrence is named after, it was developed by a bunch of guys in the LA office originally, and apparently there was a vendor who just randomly runs into the building and offered sandwiches and his name was Lawrence. I don’t know what to make of that, as a member of the New York office, but it is what it is, any other questions?

Q: How do you interact this USA Today sports group with the other properties?

A: Reasonably siloed. We obviously have some dealings with the other offerings as well as the USA Today central group, but as I said, most of the sports stuff is a little bit outside of that field. Certainly our biggest integration is moving basically flowing content across both all WordPress sports media group offerings into the other systems and vice-versa, so that’s our biggest integration and we’re looking for like similar sort of promotional stuff like syndication, stuff like that as well.

Is there any other questions?

Q: Rohit from Forbes, so obviously you’re using WordPress on the backend, so first question is WordPress also feeding the front-end of the sports system?

A: Yes.

Q: And then you mentioned other divisions within USA Today are also looking to make the move over…The main USA Today website using php or something?

A: The main USA Today website is actually a system not too dissimilar from yours actually. I believe that we have a proprietary CMSin it, I believe an ASP, that drives a front-end based off of Django.

Q: So now as you’re looking to move some of the divisions over, is that going to be an API system to connect with them or is it going to end up being completely moved over to WordPress?

A: We are actively working on an integration system to sort of marry the two systems together. Presto is what it’s called. The main USA Today CMS is architectured with an API that we can use, and that’s something we’re definitely looking to utilize for our other divisions. It really depends.

I don’t believe there’s any call to use WordPress exclusively as the front-end facing instead of Presto, that does fairly well architectured out for us to use that site. However, we do have people looking into trying to spin up their own sort of mini sub groups with more exclusive content and that is definitely looking to pull in with Presto and WordPress-driven data to use on the front-end and that is generally hosted by WordPress.

Anyone else?

Q: Hey, James, Athletics, I was curious just if you could rattle off some of the other sites running on this?

A: Sure, let’s see, our oldest one is For The Win, which is, which originally was the one we launched originally to cast WordPress as a platform in general.

It was not VIP and it was self hosted on Amazon and that was fun. We also have the […] Entertain This, we have College, we have High School Sports, which actually just launched. We have America’s Markets, we have […] and a few others that are currently in development. I actually don’t know off the top of my head the entire list.

Q: […] The other divisions looking to use WordPress, is that really driven by your group, your developers?

A: A combination of both, we originally chose WordPress for it’s ease of editorial
and for it’s ease of editorial tools and our editorial department was so enthusiastic about that, so once that started going, we as developers preferred this as a platform as we felt it was more modular and our group drove it and the editorial folks within our division also wished to continue using WordPress as a platform choice.

Even though there was obviously some hiccups along the way, about various capabilities but you know, we continue to extend our Lawrence to basically cover anything needed. Just so I’m clear, USA Today Sports media group actually contains both editorial and engineering, we’re not engineering exclusive.

Any other questions?

Q: Matthew, Athletics, when you talk about integrating Sports, […] Mongo DB, are you ingesting that in PHP or on the front-end?

A: Generally php, we haven’t really had a need yet to have to do our own live streaming front-end, which would obviously means we couldn’t use like caching like WordPress would provide, so that is something we’ll definitely do in the future. But for now, most of the data we’re ingesting, if not like vendor-driven, widget-type thing, is just generally in the php, but with the VIP server calls.

Q: Steve, the question is are you unifying your archives?

A: Um, I don’t believe at the moment. Potentially, generally, correct me if I’m wrong, most of the stuff, we’ve done so far has been very like trendy, up to date, we’ve seen like 30-40 articles published in a single day. So what’s old generally isn’t considered that much. I mean obviously as we move more and more of the main USA Today platform and that sort of stuff on to VIP, moving content from that system that we already have onto WordPress it’s something we’d definitely consider. But right now, it’s just not a priority.

Q: Let me ask a follow up question. Even in the active system (…) when you eventually […] content, do you keep that or flush it out?

A: We don’t get rid of them, we tend to have tentpole sites, which is World Cup is a great example. We have an event, World Cup 2014, and we put it up. Obviously it’s just really useful for World Cup 2014, but we don’t get rid of that content. Generally the strategy right now is keep the actual site archived and continue to iterate. We would probably eventually have a more hub-based solution which would have that old content flowed in,
using our existing tools to pull and manipulate content across our VIP offerings.

Anything else?

Going once, going twice.

Thank you very much.


See the presentations from previous Big Media & Enterprise WordPress Meetups. For Big Media & Enterprise WordPress Meetup groups in other cities, see the full list on VIP Events and join your local group. 

Want more information about WordPress services for media or enterprise sites? Get in touch.

Pre-Registration for the VIP Workshop 2015 is now open!

The next edition of the VIP Workshop will be May 4-7, 2015! We announced the event to clients weeks ago, and pre-registration for the event is now open! 

Do you run a large-scale WordPress site with millions of pageviews per month? Are you interested in optimizing and scaling up your enterprise site, and utilizing the latest WordPress features for your content? Do you want to share best practices, code shortcuts, and lessons learned with other VIPs?

The next Intensive VIP Developer Workshop will take place in May 2015, and this three-day event will include a packed curriculum for VIP developers with expert instructors from Automattic, the makers of


The Intensive VIP Developer Workshop provides a unique opportunity to learn from the VIP team in person, as well as exchange ideas and experiences with other VIP clients and partners through networking lunches and dinners, in-depth WordPress curriculum and exercises, and focused, collaborative conversations.

You’ll hear from other big brands and enterprises through flash talk sessions where VIPs will share their own experiences with building VIP-scale websites using WordPress, their workflows, shortcuts, lessons learned, and best practices, too.

We continue to receive great feedback on the VIP Workshop from attendees, and last year’s feedback was excellent:

  • 100% of participants surveyed said they would recommend the conference to their colleagues and
  • 92.68% said they would come again!

A quick peek at the itinerary – details & agenda will be continually updated on the VIP Workshop page, and we’ll be returning to The Carneros Inn in Napa, California.

  • May 4th: Arrival in the afternoon. Welcome, networking reception & dinner.
  • May 5-6th: Full days of training with VIP instructors, followed by networking dinners.
  • May 7th: Wrap-up, farewell breakfast, and morning departures.

Register now and take advantage of early bird pricing! Early bird pricing is set at $3,250 each until January 31st. After which, the full participant price will raise to $3,600.

If you’re interested in attending in 2015, just fill out the pre-registration form here or send in a ticket to VIP Support. We’ll work with you on organizing payment and confirming your registration for the event.

21 Product Guidelines Forged While Growing Metro.Co.Uk 400%

In this post, VIP Cloud Hosting client‘s Head of Development Dave Jensen shares further insights on how their popular site achieved an incredible growth since its migration and launch on VIP. Originally posted on his blog, he’s agreed to share it here on VIP News as well. 


For the last two years I have been focused on the design, build and growth of utilising the VIP platform. Our approach consists of constant experimentation with both product and content which has returned a large set of data mixed with editorial feedback. This has been refined into a list of product guidelines to help us remain focused on growth. These are based on my experiences and our audience so yours may differ.

Good editorial content will deliver more growth than any product based approach

With a single well written/planned/timed story able to deliver millions of page views and course through the veins of social networks for weeks this should be the number one focus.

Good UX turns the dial more than any product hacks

The better the experience of product and content the more likely people are to visit your site, share your content and form habits around its consumption.

The closer to the main content area of the page the more related the content should be

Our data has shown that the closer to the article body or top of channel pages the better contextually related content perfoms. Once you are below these areas users are more open to a wider set of content to continue their journey.

Where content is placed on the page is almost as important as the content that is placed there

Our testing revealed content placement is almost as important as content selection (as long as it is relevant and recent). This is one of the reasons we have moved to an algorithmic approach for large areas of the site.

  • Nothing beats the value of an editorially selected contextual link within the article body
  • The area just after article delivers a lot of value as users have finished reading and can be easily tempted into something else
  • Sidebars aren’t shown on mobile and banner blindness often turns them off for desktop users so they are not an area we focus on

Fill dead space with content, people like to scroll it’s the natural behaviour of the web

Our newsfeed delivers over 10% of the page views of our site, this is pretty impressive considering it used to be blank space at the bottom of every article and channel page.

Don’t mess with the natural way that the web works

We tried and failed with this during our swipe phase. 5-7% of users delivered 20% of our page views but that didn’t increase their overall time on site. However it complicated everything we built hampering our ability to learn fast. It also didn’t quite fit into commercial or editorial strategies. This frustration/learning was what inspired the algorithm and scroll based newsfeed you now see.

Algorithms are great but need help from humans to perform at their best

Simple algorithms are a great way to optimise editorial workflows especially around content positioning. However these are only as good as the data behind them. Often you have to wait for this to be gathered before acting on it. Using editorial intuition is a great way to shortcut this process. Especially if you can make it run off existing priorities then process change isn’t required to participate.

Whatever Google/Facebook ask you to do, just do it

They deliver so much of your traffic don’t question, just do what they recommend.

Feed the beast

Google and Facebook are always hungry for quality content. Gaining momentum requires constant feeding. They both have overall scores for domain as well as article urls so focusing on keeping this high means a better chance to gain and then maintain momentum.

Think of every page as a funnel, you lose users as they scroll but the lower they get the more open to their next engagement they become

The higher up the page something is placed the more people will see it. However the lower down the page someone is the more open they are to being tempted by some more content, advertising or interactions (e.g. poll vote, comments)

A mobile first approach is a great way to approach product prioritisation

Most of our traffic comes from mobile rather than desktop so it is logical to prioritise. This has formed a major part of our growth strategy.

Goals need to be concise, measurable and focus on why

The more people understand the goal and are able to affect it the more powerful it is. A goal that contains a why will always beat a goal that just contains a what.

Product specific performance should be broken down to actions per daily active users for comparison

This gives a much better overview of actual performance. Allows you to take out traffic fluctuations, just make sure you have enough data.

A week seems to be the minimum amount of data required to see if a feature has worked

Due to fluctuations in traffic and browsing habits. Also good to look at monthly and quarterly trends over longer periods as quite often they exhibit patterns that aren’t found at lower levels. It was asking questions around unexpected trends/data that helped teach me most around product growth.

Distribute weekly reports to show trends and give your stakeholders an overview of how the product is performing

Have these scheduled to your team and stakeholders via email. Also very useful if you break something when fixing something else. Great safety net to minimise impact and spot any unexpected growth.

Any new feature needs to be taken in context of how it fits in the editorial work flow. The closer it is to the existing process the more likely it will be adopted.

The best way to change a habit is build off an existing trigger. New features that leverage existing habits will get much higher adoption than building new habits/process.

Consider the users current journey and their emotional state in all features

Segmenting users based on mindset is a great way to understand data. e.g. Social browsers are likely on a multi site journey in a chromed browser on a mobile device. So they are only looking for a single story from your site so optimise for that. No point in worrying about pages/visit focus on getting more return visits via a social follow.

When coming from social users are often looking to enhance their social status

Our top share buttons get clicked on 4 times more than our bottom share buttons. Social proof around number of others already shared also promotes more sharing.

When coming from search users are usually in a topic based mindset

More likely to click on related, in article links and masthead channel links. Continue to deliver great content around a niche to form habits. Particularly useful around passion centres e.g. Premier League clubs.

It’s better to have 100 amazing tag pages that look and feel like a destination than 10,000 that feel like they were made for Google

Quality trumps quantity every time, Google knows if you users are clicking through.

People click on headlines 4x more than they click images

This is why A/B testing headlines is a great idea. It is the single piece of the editorial process that can have the biggest impact on growth. We also have SEO and socially optimised headlines to ensure we cater to both needs.

These are the principles that I have applied to the product development of over the past two years. The key takeaway is that constant experimentation is a great way to unlock growth if your environment supports it. The hard part is achieving that without adding too much complexity. Complexity inhibits your ability to learn and learning is central to any successful product growth strategy. Building a set of guidelines has enabled us to move faster and helped foster our continued growth.

One for the future.

Micro interactions help drive habitual use

We don’t have a lot of data on this yet but there seems to be a correlation between micro interactions such as poll votes and habitual use. My theory is that by engaging different parts of the brain you become more memorable. These simple actions form the basis of new habits around content consumption. I think this is a major opportunity for future growth.

Thank you to Dave and the team for sharing their tips with VIP News.

Want more information about WordPress services for your enterprise site? Get in touch.

Ready to get started?

Drop us a note.

No matter where you are in the planning process, we’re happy to help, and we’re actual humans here on the other side of the form. 👋 We’re here to discuss your challenges and plans, evaluate your existing resources or a potential partner, or even make some initial recommendations. And, of course, we’re here to help any time you’re in the market for some robust WordPress awesomeness.