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.
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.
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 WordPress.com and WordPress security
Core WordPress APIs
White paper content License
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 WordPress.com and there are additional Security FAQ related to WordPress.com VIP here.
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 WordPress.com 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 WordPress.com 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.
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…
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…
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 …
Gabriel Koen from PMC (Variety.com, 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 WordPress.com 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.
Applications are now open for the WordPress.com 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 WordPress.com, Akismet, VaultPress, and many other services — is looking for a few stellar student interns, specifically to work with us on the WordPress.com VIP team. WordPress.com VIP provides hosting and support for high-profile, high-traffic WordPress sites, including Time.com, FiveThirtyEight.com, qz.com, TechCrunch.com, Recode.net, NYPost.com, 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.
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.
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.
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 WordPress.com, 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.
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: 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.
Ephraim Gregor from USA Today presented “World Cup and WordPress.com 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 USAToday.com. 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?
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.
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.
The next edition of the WordPress.com 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 WordPress.com 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 WordPress.com.
The Intensive VIP Developer Workshop provides a unique opportunity to learn from the WordPress.com VIP team in person, as well as exchange ideas and experiences with other WordPress.com 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 WordPress.com 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 WordPress.com 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.
In this post, WordPress.com VIP Cloud Hosting client Metro.co.uk‘s Head of Development Dave Jensen shares further insights on how their popular site achieved an incredible growth since its migration and launch on WordPress.com 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 Metro.co.uk utilising the WordPress.com 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 metro.co.uk 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 Metro.co.uk team for sharing their tips with VIP News.
Want more information about WordPress services for your enterprise site? Get in touch.
WordPress.com VIP Director of Platform Services, Peter Slutsky, presented to the DigitalGov University about using WordPress CMS to build government websites, along with Dan Munz, from the Consumer Finance Protection Bureau, last year, now published with full transcript.
DigitalGov is brought to you by the Office of Citizen Services and Innovative Technologies in the U.S. General Services Administration and their job is to help government agencies build a 21st century digital government.
“Can WordPress be a full-fledged CMS? Our experience is absolutely yes, it can.” — Dan Munz, Deputy Assistant Director for Consumer Engagement at Consumer Financial Protection Bureau.
In this presentation you’ll learn:
How to determine if WordPress is a good option for your agency
The important technical considerations
The biggest challenges and successes CFPB had with implementing WordPress
The resources you’ll need to implement it and keep it sustainable
How to get buy-in and make the business case to switch/choose WordPress
Good morning everyone, thanks for joining us for the second event in the Why Choose series.
Our first event featured why you might choose Drupal as your content management system or CMS and this event of course will focus on WordPress. Before we begin, I’d like to introduce our presenters.
First up we’ll have Peter Slutsky, he’s the director of platform services at Automattic, where he focuses on expanding the WordPress footprint in politics, government and nonprofit arenas. We’ll also have Dan Munz, who’s the product director for consumerfinance.gov at the Consumer Financial Protection Bureau, which is the Flagship digital property, and he’s responsible for leading the daily of product-focused web team, articulating prodict priorities, and a release roadmap and shepherding individual digital products like the Bureau’s online knowledge base at CFPB.
So with that, I’ll hand it over to Peter.
Peter: Thank you, I feel like I’m going live on the Today Show. So first of all, everyone welcome. Thank You so much for joining us this morning. My name is Peter Slutsky. I’m very excited to be with you guys. Let me quickly give you a little background on who I am and what I’m doing here, then I’m going to take you through just a couple slides and then you an overview of WordPress and some of the work that I’m doing to expand the WordPress footprint in Government.
So I started my career working in politics, and lived in DC for a long time. In those roles, I worked in new media, back when new media was actually new and in communications and some organizing on some campaigns. And in about 2007, I got connected to the folks that were launching causes on Facebook, and I was a consultant for them which kind of opened up a whole new world of technology and the intersection of technology and digita and politics, which was kind of perfect for my past experience. I went to work for a company called Ming, which was doing some really cool things early on in social networking on and went to an early stage start up which led me to Automattic and WordPress, which has been phenomenal.
I’ve been there for about a year, it’s been an eye opening experience. I love the company. I’ve been a WordPress fan and WordPress user, as I’m sure many of you are, for a long time.
So let me start off by saying that I’m not a developer, so if you want to have more technical discussions, we ca do that and I can try, but chances are, I will pump the question and get an answer for you, and can follow up later.
I’m on the business team, and my role is to kind of evangelize and run, lead our business development team in government, non-profit and political space.
So, throughout my career, I’ve worked with a lot of really cool innovators in Silicone Valley and in Washington DC and now up in New York City where I live, and i’ve been super impressed working in the government space.
I feel like we are still really early on in the evolution of technology and innovation but we’ve had just amazing strides over the last couple years in the reinvention of digital strategy, of open government and open source technology, and you know, working with people like Dan who you’ll hear from later and others across government. It’s just been a phenomenal experience.
That being said, I do still think that we’re still super early and that we’re on kind of the first wave, the first generations of the platform and the technology that you’ll see deployed into governments, and we’re obviously in a lot of ways, we’re riding a Drupal wave right now.
One of the things that I’ve heard a lot about in the last year, as I’ve begun to have more and more conversations is, that people are using WordPress as a blogging software and oftentimes behind a firewall for internal communications, and inter-agency communications.
But increasingly, now there’s a desire to use WordPress as a full CMS and to use it for top line websites and agency, projects and micro sites at all levels of government. It’s been really cool to see it, interesting conversations.
So what I want to do is take you guys through the WordPress Eco system and kind of re-introduce you to where WordPress is today in 2013, because I think we’re literally this year, in May, celebrating our 10th university.
So, it’s a really, we’re not grown up yet, but we have come a long way and there’s a lot of perception out there a that I want to work on resolving as we now get into our early adulthood.
So let me just take you through the slides. There’s three flavors of WordPress. There is the self-hosted, WordPress, open-source service which was founded about 10 years ago by Matt Mullenweg, who’s the founder of Automattic and also was the first lead developer for WordPress.
Anyone can go on to WordPress.org, download the open-source, free WordPress software. You can run it on your own servers, you can host it on any number of cloud hosts, Amazon, Rackspace, wp-engine, BlueHost, Remote, Go Daddy, all those, the web host companies that we have good relationships with.
And, WordPress.org, you really have complete control over the code, the codebase, the experience, the fees, the plugins, the accessibility, the third-parties, the technology you bring in.
So in that way it’s really a model framework for building anything from an agency blog or a small web site, a microsite all the way up to large sites like The New York Times, and CNN and I’ll show you some of those great examples after.
We always say with great power comes responsibility, working as a developer or working with a few developers, you can do great things, but it’s also easy to build a plane that you fly too fast. So a lot of times I’m talking with people about sort of picking and choosing which plugins they want and streamline themes and decluttering to make it the most efficient, fast, responsive website, as possible.
So that’s WordPress.org. WordPress.com is the largest WordPress site in the world. It’s one large ultimate site. As of today, I think we have about 45 million sites running on WordPress.com including many in government space, the political and nonprofit space.
Basically, it’s a saas model, software as a service. So we do all of the backend infrastructure, hosting, CDN, storage, backup, security pieces so what you really have to work with and deal with and think about is the front end, the design, and the content, and that’s, that’s something that I know that people working with limited budget constraints or limited resources in terms of development, that’s something that’s very good.
The third bucket in this line of buckets is WordPress.com VIP. This is my team. So the VIP team is sort of the best of both worlds, WordPress.org and WordPress.com It’s a SaaS hosting and support model, for enterprise-level websites. I can show you some examples later, but we power like a huge amount of the media sites and the large websites you probably visit every day.
On WordPress.com VIP, we allow you to run your own code base, your own plug ins, but you have direct access to our developers and they can do code reviews to make sure everything you’re doing is safe and secure, and scalable.
Those are things that I’m going to touch on in a minute but those are kind of some of the main questions that i’m getting as I’m talking to folks in the government space.
Really quickly about Automattic, Automattic is basically the commercial arm, the parent company if you will, of WordPress.com. It was founded in 2005, by Matt Mullenweg, who you can see, if you look A-U-T-O- and the M-A-T-T-I-C that M-A-T-T is for Matt. We had all different kinds of products, and for those of you who are running WordPress right now or thinking about running WordPress in your agency, I really recommend you take a look at automattic.com to see all the suite of services.
We have Akismet, VaultPress, Jet pack, VideoPress, and Gravatar, and all these products are really plug and play features to WordPress ecosystem, and some of them are also stand alone products that can really help drive all different kinds of features for your website, so check that out.
We’re about 150 employees, we work all around the globe. I’m sitting in Brooklyn, New York, but my team is in Europe, Eastern Europe, Japan, Australia and all throughout America and Canada, it’s really interesting. And to note, we also don’t have company e-mail. We don’t do internal e-mail. We communicate all by a series of internal blogs that are all linked together and so it’s a super, kind of new-age company and the work that we’re doing reaches a ton of people. We reach about half a billion people every month.
We have some great investors, which you can see here, including The New York Times. Who’s one of our big users and partners.
So our core philosophy of WordPress is simple and elegant, but also really powerful and flexible. Which is kind of the driving measure with which we measure ourselves with our software. We want anyone from a local blogger anywhere in the world to CFPB.gov or Nasa or BOJ or the State Department or the White House or anyone to be able to come on and build something that scales to their needs.
We have a lot of flexibility, you know, plugins and themes and APIs, and all these things allow you to you take the base software and make it as robust as you need to.
And in this role of diminishing budgets, diminishing resources, that is where we’ve seen a lot of the adoption of WordPress come in. It’s fast and easy, but very powerful which we’ll go over in a minute. You’re very safe, very secure, and super scalable.
One of the key points also is that it’s open. It’s open-source, this is something that’s kind of the driving force behind not only our software that we built, but the company itself. We’re an open-source company and that’s how we’re able to work in this distributed way across the world and make it work.
We are strong believers in rapid iteration, we put out three major releases every year. Upgrading WordPress is super easy, and for those of you again who are running WordPress right now or are thinking about running WordPress in the near future, I really recommend that you take a look at the upgrades and updates.
I talk to people every day in the government space that are running old software and that introduces a lot of issues. So if you have questions about that, or need recommendations or best practices, definitely reach out to me, iIll give you my e-mail and I can help you with that.
We’re the most powerful CMS on the web. We power 17.9% of the entire internet is powered by WordPress. 60+ million sites, 100,000 new sites are joining our ranks every day. We just had a major influx, there are stories you can check out about some defection when Tumblr was bought by Yahoo. And now we’re getting a lot of that traffic over to WordPress.com, which is really exciting.
We have 25,000 plgugins, 15,000 themes, and more every day. We have an amazing core group that works on the wordpress.org team that helps to get and manage all the code base for the plug ins and the themes that come in to make sure there’s no vulnerabilities, that there’s no hacking, prospecting, to make a website vulnerable. So, it’s a huge community, but we’ve done a really great job of building it. There’s a ton of resources out there.
So, let me talk quickly about WordPress as an enterprise CMS. My biggest challenge coming into this job was, you know, WordPress powers the world, by far the largest CMS around, but when you look at the .gov space, the federal government and in some cases state, definitely not local, federal and state, there’s this perception that, yeah, we’re going to run our blogs on WordPress, but it’s not, it doesn’t scale to an enterprise CMS and obviously a lot of that came from the decisions that the White House made in an earlier administration, to use Drupal, and a huge eco-system has been built up around Drupal in DC.
But let me just go through WordPress as an enterprise CMS, these are the majority of our VIP clients. These are the people that we’re building this and developing for every single day. On a CMS, you can customize your data and decide what everything looks like. We have multi-author responsibility where you can set rolls and permissions.
So, in some cases there are hundreds, or in some news rooms, thousands of people that are practicing the WordPress dashboard and that are leveraging, something that has evolved. There’s also multisite, which is the ability run multiple sites on on a single codebase within one organization. So we see this all the time in universities, at state government level, we’re working with GFA, as they’re scouting out a new project that’s super cool that involves WordPress multisite, but this could be an amazing application for your agency, you know, to kind of consolidate.
That’s one of the big things that I hear is that people are working in silos, not just across agencies, but across teams within agencies. They have different CMSs, they have no CMSs, they have a topline Drupal CMS, or a WordPress CMS but then everything else is on an old proprietary platform or no platform at all.
That’s one of the big things that I hear is that people are working in silos, not just across agencies, but across teams within agencies. They have different CMSs, they have no CMSs, they have a topline Drupal CMS, or a WordPress CMS but then everything else is on an old proprietary platform or no platform at all and WordPress multisite is definitely something that you guys should check out and that our team supports. If we saw more adoption of it, which we will over the next couple years of government, it would be an amazing thing for technology and innovation and also for cost savings obviously – it’s free.
All kinds of integrations that help power the enterprise CMS, APIs, plug-ins, all kinds of social extensibility, social plugins, plublicize, to Twitter and Facebook, and LinkedIn and Tumblr, and to push content in and out.
And then also, we have a VIP feature partner program, which we’ve basically gone out and curated the best technology companies and brought them into our fold. So all of our clients, and the people that are using WordPress.com VIP et increasingly into other products on WordPress.com, they get access to all these great tools.
And we also we have this great team of developers who’ve built this really great set of plug-ins that help with edit flow or for high octane news room, which could be amazing application for a government agency where there are different departments, different teams, different publishing, where instead of working inside Google Docs and on email, this is a way, I’ll give you an example with Edit Flow, a way to work directly within the Dashboard within the CMS to edit content and then push it to the, and then publish it to production.
WordPress is super scalable. Sometimes I’ll have calls with IT folks in government and they’ll say “well, I’m worried that it’s no scalable past a certain point. I read this here, or I saw this here.” A lot of it, if you Google and you start to get nervous or paranoid about these issues, a lot of those articles are from like 2004, 2005, 2006. We’ve come a long way.
WordPress.com, like I said, is the best example, but we have about 4 billion page views every month, we’re publishing 500,000 posts, 400,000 comments, and that’s all on one single installation of WordPress. So when I talk to government agencies that are scoping WordPress, I will bring our systems team on the phone with in-house IT folks and we’ll have a really great conversation about how to optimize that set up so that you can almost guarantee, 100% uptime, SLA, and all these things that I know the CIOs all are looking for when they’re scoping out new platforms.
From a security standpoint, that’s another thing that I hear about, I’m sure that that’s one of the biggest things, that, as web folks that you’re hearing as well “well WordPress isn’t secure”, and I hear this all the time even in conversations between WordPress and Drupal, people say “well, open source php, dynamic websites, these are not safe and secure things the government to be running and that’s totally, totally not true.
Oftentimes, the stories that you’ll see, where there’s been a hack or a vulnerability, or an issue, that comes from either the host, or from running an outdated version of WordPress, or some kind of call stripping error that a developer has introduced, but that’s why our team does expensive code reviews.
We review every line of code to make sure that all of our clients and all the people that are running WordPress at an enterprise level are really kind of inoculated from those types of issues. We’ve been vetted by all kinds of agencies and all the big players in IT security and we’ve gotten great feedback. So WordPress is a scalable, secure, platform, that can take you all the way up to where you need to go.
We’re mobile-friendly, mobile ready. The most exciting thing to me in the world is thinking about where the future is going, especially in the context of government, when it comes to mobile. The fact that, you know, we’re now putting all of this information and data, and giving it to people to develop apps and all kinds of integrations with healthcare and what Dan is doing at the CFPD, with consumer data. It’s so exciting and I think we’re super early on, but WordPress is completely mobile friendly.
You can make pretty much any theme responsive. We have great APIs, and we have themes that are mobile optimized. So you don’t have to have a separate track of mobile development and web development. It’s pretty much all one development package at this point.
Really quickly, a little bit more about VIP services just because I want to make sure that people know, if you are going to use WordPress or if you are using WordPress, there is a company, Automattic, that is behind the service and that could help support and scale and be a resource to you or to an agency partner or to a consultant.
We do this all the time where we step in and basically get a developer seat for self-hosted support and you can have unlimited access to our team of developers, who are really world-class, top WordPress and php developers and we will help you with best practices, code reviews, advice on plug ins, and all those kinds of things.
And then also, if you get to a point where you decide you want to host outside of your environment, WordPress.com can be a great option for you. And like I said, we do host a lot of government clients, and also Fortune 500 companies, and big media companies which I’ll show you in two seconds.
So really quickly, when you’re working with WordPress, your company, these are just some of the organizations using WordPress, The White House, DOJ, The House of Representatives, all throughout the Senate, DOD, State, CFDB, Library of Congress, EPA, and it’s growing every day. Everyday I have an exciting conversation with someone whose doing some kind of amazing innovation.
On the media front, we have our CNNs, CBS local, New York Times, Time, Tech Crunch, Venture Beat, all the big tech blogs, and it accounts for a lot of our traffic, but it also accounts for a lot of the energy and and the development resources that we put into our core products. If something is good for The New York Times, it’s going to be good for core software which is going to be good for you guys. It’s a really awesome eco-system and one that builds and builds and builds.
Let me close off real quick with this. We are doing a WordPress in Government half day workshop on June 13th in DC. It’s going to be really fun, a bunch of our partners, I think GSA will present, agency partners and some interesting people, from Washington and around the Washington world. The Washington Post, which I don’t know if you guys know this, but The Washington Post actually serve a lot of their traffic through WordPress.
During the of 2012 campaign, I think at one point at the end, 85% of traffic was being served through a WordPress site, which was super exciting for us. And now they’re official partners of ours and we’re working with them to help scale all these amazing products that they’re building. So if you want to come to WordPress in Government event, then let me know. Shoot me a note on e-mail, or here’s my email address and my Twitter handle. I would love to have you there.
Let me close out by saying, again that I’ve worked with some amazing people and I just applaud everyone who’s inside of government right now and innovating. It’s the place to be, and when I work and have meetings in Silicon Valley and in New York, everyone is trying to tap into the market of, you know, engaging with citizens, and I think you guys are on the front line of that, so I would love to be a partner and I would love to figure out ways for us to drive WordPress inside your agencies.
So please get in touch and I really appreciate your time.
Moderator: Thanks Peter. Before I pass it to dan, I wanted to remind everyone that we will take questions at the end and to please type your questions in the chat box. And we’ll also include, Peter, your email address in our follow up e-mail to attendees.
So if you didn’t get a chance to write it down, and have questions for Peter, we’ll send it.
So, as I mentioned our next presenter will be Dan Munz and he’s the product director for ConsumerFinance.gov.
Dan: Thanks a lot and thanks every body for spending a little bit of time this morning listening to Peter and I talk about WordPress and our experience with it.
I’m going to start off just with a little bit of background. First real quick about who I am and why on Earth you should listen to me about any of this stuff. As it was said, I’m the product director for consumerfinance.gov, at the Consumer Financial Protection Bureau, which is DC’s newest federal start-up agency. I’m responsible for leading product development of the Bureau’s site consumerfinance.gov and some of our other digital products. And it’s important for me to say that I work with an amazing team of designers, developers, data analysts, project managers and new media strategists, who make all of this stuff I’m about to talk about go.
I’m a proud alumni of BGSA Center of Excellence in Digital Government. Before that, I spent about 5 years in political campaigns, non-profits and federal government, understanding how the modern web and the civic sector fit together and understanding the emerging technologies like WordPress make that happen and make it happen quickly.
Today, I’m going to give you a little bit of an overview of the Bureau and of consumerfinance.gov, talk a little bit about how we use WordPress and how it fits into our overall kind of web architecture. Give you a few thoughts about how to use it successfully and what to be careful of kind of from point of view and talk about a few sort of big, big hairy questions that keep us up at night.
So really quickly, a little bit of background on the bureau. If you want to trace our founding to kind of one sentiment or one thought, it’s probably this article published by then law professor Elizabeth Warren in the summer of 2007 called “Unsafe at Any Rate” in which she observed that it is impossible to buy a toaster that has a one-in-five chance of bursting into flames and burning down your house. But it is possible to refinance an existing home with a mortgage that has the same one-in-five chance of turning out to be much more destructive than you thought or that you were able to realize at the time.
And her insight then, was there ought to be a federal agency regulator responsible for making consumer markets and consumer products work for consumers and for responsible lenders and prevent exploding mortgages from making their way into the economy. That, as I said, was in summer 2007. A bunch of stuff happened to the American economy after that and in July 2010, President Barack Obama signed the Dodd-Frank Wall Street Reform Act that created the Consumer Financial Protection Bureau. By July 2011, we were about 100 or 200ish people. Here’s a picture of some of them. By July 2012, we were close to our current capacity, which is 1000-1100.
So we’ve had a pretty steep growth curve, and this is where we work. It’s at 1700 G. Street NW, if anyone’s in DC, come say hi, you can see our big friendly logo on the wall. That’s a little bit about the CFPB.
So now let me shift to talk about our site, consumerfinance.gov. It was launched in February 2011, five months ahead of schedule. It’s worth noting that the bureau itself didn’t actually open for business in a meaningful way until July 20011 and so for about 5-6 months, our website was not so much the website of a federal agency as the blog of a bunch of people who were building a federal agency. And we’ve had to evolve of the time, as a bureau matures and offer things it didn’t use to to offer, like complaint intake and consumer engagement regulations enforcement.
Consumerfinance.gov is the Bureau’s only digital property, we own digital property, and we’re actually pretty proud of that. When people ask how many websites we have, the answer is one, I’m personally pretty dedicated to making sure it is only ever one. Consumers are our core audience, like I said, we do regulation, we do enforcement, we do a lot of industry and other partner-facing work, but as far as our web brand is concerned, consumers are our core audience.
And to give you a sense of size, we do about 900,000 unique page views per month. We’re no WordPress.com, but we do okay. This is what our stack looks like. Going from the bottom up, we use Google Analytics to do our web analytics, we’re hosted on Amazon web services, we use Akamal as our content distribution network. At the top of the stack, there is WordPress, we also use Django, which is a pyhton-based web application framework to build a lot of stuff, but I’ll talk more about that in a second.
There are, to be sure, a lot of other technologies floating around in there that connect you to our our site. Apache obviously is in there, but as far as the technologies that surface to a user, this is the main stack.
So you notice at the top we have WordPress and Django there and this is a microcosm of the big CMS vs Framework questions. One thing I will say by the way is that I think Peter was maybe a little modest in talking about the question about can WordPress be a full-fledged CMS. Our experience is that absolutely yes it can.
It’s just uncontroversially true. There are things you have to do to make that happen successfully and there are things you can do to make it happen unsuccessfully, which I’ll talk about in a little bit.
Our experience so far has borne out the idea that WordPress manages content and is a good system for doing that. We use WordPress and Django together. We found that WordPress is a good fit for things that are standardized content types. So when you think about our blog, or our newsroom, or regulations, or testimonies, or speeches, or reports, any of the many products we have that are sort of standardized content that we put out on a regular basis that we can manage in a sort of a bulk presentation way.
It has actually good content management user interface, UX designers sometimes referred to as the interface UX forgot and I agree they’re not always awesome and WordPress, or at least the self-hosted version which we use has a pretty solid back end. It also lets us cleanly distribute editorial workflow. There are plugins for that, but even WordPress out of the box has an ok version of this. And web application frameworks like Django, although there are CMSs for Django, tend to not do an awesome job at it.
So what we’re using Django for is really whenever we’re doing custom app development. Anything that’s highly interactive or highly database driven, or has a really complex taxonomy. Anything that depends a lot on search or complex navigation, or Ajax and things like that.
And we use it mostly for things that have relatively infrequent content updates, though there are certainly exceptions to that. I think the short way to think about this is we use wordpress when we want more people doing fewer things. We want more people around the Bureau to be able to create a blog post or create a press release, or repeatable simple things like that.
We use Django when we want fewer people to be able to do more things. So Django is the language that our designers and developers will use to build an application, and they can build a full application from bottom to scratch. It can be data viz oriented, have a lot of complex interaction. So it has a lot more flexibility and strength but you do have to be a developer to get in there and build with it.
To tackle kind of the main question that frames our time today, why choose WordPress, these are some of the reasons that I think at least we chose and why we continue to choose it. One is a basic level. You have a c (content) that needs m’ing (management). I remember a survey a while back when the federal, “hey everybody get rid of so many websites” order came about. Someone called all .gov sites and tried to count what CMSs they were all using, and I think 1,200 came back as none, which is not great.
So you know, WordPress is one of a family of software called CMS, and if you just have a bunch of content on a site that right now is just static HTML, you should get yourself a content management system period. It lets you get started really quickly and cheaply. Even the hosted version, for me to have hosting, it’s relatively simple to set up and install and get started. It’s really well documented in their documentation and online. So googling is really your help function.
Like i said, it has a pretty usable admin experience. It has a really nice syndication features. It makes it trivial to create an RSS feed content, there are plugins that let you really easily create a JSON API for the content. So WordPress has the potential to lend itself really nicely to being just one member of your web ecosystem.
Data in, data out are relatively clean. And one thing that is really important that I can’t stress enough.It was a robust well-managed community both on the kind of “I need tech support” side but also on the code side. There’s a lot of great development happening, there are a lot of plugins for core functionalities that are relatively mature and really well maintained. So it’s relatively new, but it’s certainly past the point of being experimental technology, it’s absolutely usable.
The flip side of these things is kind of thing is that if you do choose WordPress, one thing that’s important to say is that WordPress is not natively a web application framework.And this is a statement to me that seemed obvious and I Googled it and it turns out to be a relatively controversial statement. It’s clear to me that WordPress, whatever its ambitions is not yet a full-fledged framework application. It is a CMS, and you know, I’m absolutely sure that it’s possible to build really complex web applications but it’s not what it does best. There are other frameworks that do it much better, much easier out of the box.
If you’re going to choose WordPress, you should really understand that the kind of four walls of what you’d consider to be content management, are really what you’re getting, at least that’s been our experience.
You still need designers and developers. It’s really important. It’s easy to think, I’m going to get WordPress and I’ll have a great website, but then you find out that, oh, well, you actually need designers to make it brand compliant, to do layout really well, you need UX professionals, to make sure your information architecture is right, so you understand what your content types are. You need developers to get the thing running, inspect plugins, make sure they work well, things like that.
So it doesn’t really free you from kind of needing a great design and dev team on staff. Some core cabilities are still maturing, the flipside of the robust plugin community,in some things I think of as core capabilities are kind of left to plugins, which, robust as they are, are still in development.
One great example of this is called Ramp, which is a plugin written for a use case that we certainly have which is moving from content from sort of a staging server to a production server, selectively in a way that doesn’t require to you delete your production database and start over. And you know, it’s a great plugin, it’s really incredible for us that it was written. But it doesn’t do some simple things like make removing content from production really easy. Or give you a unique ID that sort of syncs between staging and production.
So, that kind of stuff, you can run into it. And it’s only really when you realize that you need that functionality that you go “oh man, we need that” and then you kind of hope that the people who maintain that include that feature. To an extent, that’s true with all open source software. But we found that, in a few cases to be true of even things you’d think of as kind of core functionality.
I think this is another frame on Peter’s “with great power comes great responsibility” quote. It’s easy to do things right with WordPress, but it can be even easier to do things wrong. It makes it really trivial to upgrade the site, to add new plugins, so change your theme files and if you’re like me, php still looks like Matrix code to you.
It does make it potentially even easier to do things wrong. Before proceeding, some things have been really helpful for us, one is understanding your information architecture, and I mean seriously understanding it. And this is something you should do with any CMS, and any website.
But it’s especially true in a scenario where you have, at least for us, a hosted version of WordPress and you have to be pretty thoughtful about what kinds of content you’ll have, how they’ll relate to each other, what kind of taxonomies you’ll be able to use site-wide to be able to manage that content.
How you want content to show up in different places and it’s really important to kind of think out for your enterprise a step or two or three beyond where you are now. For us, we were in a major growth situation, where if you look at the Bureau, kind of 2 or 3 years into existence, the range that we offer the public are just totally different, and evolved every time, ’cause we’re growing so rapidly.
And so one challenge for us has been keeping our view of our digital architecture up-to-date with the architecture of the Bureau’s public offerings. So that’s really important.
A flip side of that, or a companion to that is understanding the enterprise. Understanding how you’re going to want content to be managed, who you want to have permissions to do that, what permissions you want them to have and reverse-engineered to the question of how you can configure that in a tech capability way.
One other thing I’d say is to think about search. This one area where I think WordPress, at least when we started using it, is not super strong and it’s, you know, for obvious reasons not up to the task of search across, example, WordPress and all of the stuff we keep in our Django-based apps.
So you’ll want to think about what your search solution is, we use USA search, which is a great one. There are things like Solr, which is a search library for Django, which is really great or for python.
The other tip I give is understand how your security shop thinks about open-source software. What Peter said earlier is absolutely right. Anyone who said that open-source software is inherently less secure or more secure than proprietary software is to my mind just flat wrong.
At the same time, using WordPress, does mean that, one way or another, if you,re doing it right, you’re going to have to take code that someone else wrote and run it our your servers. And that’s going to require you to at least understand and maybe have a few heart to heart conversations with your security shop to understand what’s the process for reviewing a plugin that we want to use, and the process for reviewing an upgrade.
It may turn out to be painless, or painful. If you dive into this without understanding how they’re thinking about that challenge, it’s almost certain to be painful.
So the next horizon issues for us, from a web strategy standpoint broadly, one is structuring content and taxonomies more consistently. This is kind of an issue I flagged earlier. Understanding how all the content we have relates to one another, and how kind of the information architecture that’s emerging can be reflected efficiently in the way we divide content on the back end. Something we’re always striving to do better but, it’s something that I think keeps us up at night.
Being smart about pushing reusable code blocks into modules or plugins. I think we’re learning all the time, about what kind of single purpose things we build, turn out to be enduringly useful and how we can push those into blocks of code or blocks of functionality that we an reuse.
And to me the biggest one is abstracting this question of templating to be platform agnostic. More and more I think you see kind of really mature web organizations thinking about the engine that templates and serves sites to the public, being potentially really different from the engine used to manage and store content, kind of the database.
I think our kind of hypothesis, is that if we’re able to separate those functionalities and create a layer that pulls content from WordPress or from Django, or somewhere else and can serve it with the same consistent template, we’ll be in a really good position.
This is a particularly important issue for government, not only because you’re sometimes integrating multiple content management database structures, but also because occasionally, if you’re like us, you’re called on to integrate kind of a third party piece of software that has a public facing component into the site. And regardless of what kind of CMS you mostly use, it can be a real challenge to do that in a way that’s kind of brand consistent and well-integrated.
So we’re really actively thinking about investing in the capability to take the question of templating and sucking content out of somewhere and serving it onto the web in a really uniform way and really separating that from the core database stuff, where content is kept.
So that’s pretty much all I have to say, I hope that’s given you kind of overview of how we think about and use WordPress and how we think about managing web content and having better web properties generally. Like I said I really appreciate everyone on the call taking the time and I’m eager to take some questions.
Moderator: Okay, thanks Dan. We do have a couple of questions.
Both you and Peter mentioned security, would it be preferable to install WordPress on an intranet server, as opposed to using it as a third-party method?
Now I don’t know if Peter you want to address that or Dan or both of you?
Peter: It’s hard to say, depending on the use case is. The person with the question should definitely reach out to me and I get some more solid recommendations.
Dan: I mean the only thing I’d say is I’d go back to my point earlier that there’s not really and this is partly because I think Federal security shops are, while not new, not necessarily having standard out of the box procedures for reviewing open-source software, it’s hard to say there’s a preferable way to do it.The really preferable way to do it is have a conversation with your security team before you pick a direction to proceed in.
Moderator: Okay. You mentioned, Dan, that you obviously need developer and technical support to use WordPress. Can you elaborate relative to other CMSs, is it more, less, the same?
Dan: My guess is a little bit less than Drupal, although, I have to say I don’t have a ton of experience with Drupal, my understanding is that you know, partly because it was kind of born as a CMS, there’s a little bit more configuration complexity there to it. But if you think about the spectrum of things, if you think about something like WordPress.com, or any kind of hosted service, that’s where you really need the least developer support.
You still need design unless you’re building a website with no front-end, maybe you want your visitors to consume pure JSON, but if that’s not the case, you’ll need design. But in terms of dev and tech resources, anything hosted externally is the easiest solution. Anything hosted internally, if you want to do it professionally, there’s just going to be some level of having folks who can think about the architecture of the site, having it think about scalability, caching and serving and things like that. You’d be surprised at like the really dumb things that can happen if you don’t have folks like that around. Then, as I said, the top of the spectrum is frameworks ike — like pure web applications like Django and ruby on rails and things like that that are really purely application development frameworks and really, you know, anyone can get started but that’s kind of where a developer or designer just has to play really, a really dominant
Peter: And also, just to weigh in on that a little. One of the things I’ve been working on is really helping to identify resources, especially in and around the DC area. So talking with a lot of companies that do web development and bringing them up to speed on WordPress as an enterprise product, so, if, and there are some really great resources out there, so if you know you want to do something that is a little more complicated than the out of the box piece, let me know and I’m happy to connect you.
Also, as I said, part of what we do is supporting folks that are self-hosting, to be that developer resource. If you have someone that knows WordPress or php but doesn’t feel like they can extend it to the point where you need to get it, we can be kind of that bridge to help you in that way. I think to answer the fundamental question, all these things, when you’re talking about doing something that’s bigger than out of the box requires some level of expertise and that includes developers and designers. But for the most part, when I talk to people bout, deciding between WordPress and Drupal, and let’s just say Junla, it’s never a question of, this one needs nothing and this one needs something. It’s always a question of, where are the resources, and also what’s the long-term strategy. Like for example with Drupal, they do a once a year or once every ten month release period, or updates, and that oftentimes will lead to you needing to tear down the house and rebuild it more often, whereas WordPress is more iterative. And you can update as you go and theres a lot more backwards compatibility. And that’s the kind of thing we see a lot in conversations.
Moderator: Great, thanks. Could one of you actually show specifically what the back end looks like?I don’t know Peter or Dan, who would be the best person. Peter, I can pass control back to you just so we can get a better understanding of how it works and how we can better use it.
Peter: Whoever had that question, there’s all kinds of resources, screenshots, screenshares online, so if this doesn’t answer all your questions, that will.
Moderator: Maybe Dan you could answer this question. With all the API work being done in Drupal, will it scale or work with WordPress?
Dan: I mean it’s a little bit tough to tell. It depends on the individual project, but in general, I think it’s really important to understand that one of the kind of main goals of API work generally is to make data transport really agnostic to these kind of platform questions. Depending on how, I mean it sounds like the question might be about content migration between Drupal and WordPress and operating them together. If the person who asked that question wants to drop a little clarifying note, that’d be great.
Part of the reason I think it’s good for everyone, both Drupal and WordPress, they focused pretty hard on making it easy to create APIs and build webpages on top of webpage stores, is that it doesn’t lock you in to any of those. Your data’s really portable, it’s reusable in web applications. So if I wanted to build a web application that pulled in my content from Drupal and my content from WordPress, inefficiencies aside, I could probably do that.
So, when you think APIs, you should think inter-operability, more or less no matter what. Like I said, I’m sure their fields look different, they’re stored differently, but in the abstract, that’s the answer.
Moderator: Great, thanks. So Peter, are you-all set?
Peter: I hope you guys can see it. Here’s the basic dashboard, if you see people walking around the world with WordPress, wp admin shirts on, all the nerds like me, this is kind of our core, the core tenant ofWordPress that has remained constant throughout the 10 years that we’ve had it.
Dan: Peter, can I just say that i love that you have two categories of blog posts, music and other.
Peter: Oh yeah, I’ve really extended this one greatly. Yes, so this just my own personal blog, so it doesn’t have any complexity to it, and I’ve seen The Washington Post’s dashboard and The New York Times’ Dashboard and it’s absolutely insane.
They build all these custom things for editing and edit flow, and permissions and all these types of things.
But very basic. Basically, here’s our, this is how you add a new post and a post is content-type, that you can even assign as, assign to different parts of your web site.
It can be media, it can be text, it can be anything. We have obviously taxonomy around tagging and so you can have robust search. This is the uploaders where you can add images and links and then have you, in your library, you have all of your uploaded content, and it can kind of practice a storage area for you and then you can click in and embed content, so that’s great for photos if you’re one to put beautiful HD photos, those kinds of things look great.
On the user front, this is something that may interest you guys. Say you have 30 people in your office who are assuming different roles and you want them to have different permissions, you can invite new users and you can change roles to be an administrator, editor, author, contributor, will then trigger access to different parts of the site, different controls of the site, which is a great feature, in an organization where there’s a lot of folks.
What I really recommend you do, because it’s free and it takes 10 seconds and it’s easy, is go to WordPress.com, sign up for free account, and just start to poke around, build your own little site and from there you can really start to play around. And as I said, it’s really that easy, to at least get started.
The stuff that Dan’s talking about, it’s all super interesting, the layers of framework that he’s put on top of it. Or to just get a basic site up and running that has pretty much all the full functionality that you would need to publish, it only takes a couple of minutes and then from there, the sky is really the limit. We also have great stats which I love checking. I’ll show you what a loser I am right now, but you can really see kind of all your stats here in one place. Not as good as google analytics, but it’s getting these. It’s pretty fun to watch.
One of the things that I definitely recommend you do too, if you’re running your own WordPress site is go to jetpack.me and install that plugin. It’s a way to bring a lot of the development of WordPress.com onto your self hosted site and in doing that, you get the chat functionality and other cool things to see and to try.
Moderator: Peter, can you limit specific roles to specific pages?
Peter: You can. There’s some stuff that you can do, definitely, and that’s something that we get a lot of questions about. So there’s definitely, there’s great documentation if you go to Google and type in WordPress Goals, there’s a link that I send around to people a lot that clarifies all the different pieces of the roles on WordPress.
Moderator: Is there any type of site that you wouldn’t recommend using WordPress, for example a transactional site or a data heavy site?
Peter: I don’t think I can recommend that you don’t. What we’re seeing how WordPress works at every level. Some of the stuff that Dan was talking about with heavy data table asks those kind of things,there might be integration that would make sense to explore.
But, we’ve done surveys of our user base and there’s a huge number of people that are running e-commerce and running full CMS and kind of doing full-fixture blogging sites and increasingly now using WordPress as a framework. I don’t think this is going to happen in government tomorrow, but it could be something down the road. And certainly, like the Washington Post is using it, using either the publishing piece of WordPress in the backend and a front-end solution, or vice versa and they’re using the front end of the solution and importing through a different type of back end. It just takes a lot of creativity and some developer lifting.
Dan: Just to add to that. I would frame the question just a little bit differently and say that for almost any type of site you want to build, the great thing about the web is that someone’s already built something like it already, and so there’s probably a tool that’s really great at it.
And so it’s hard for me, I mean at the end of the day it’s all code. It’s hard for me to think of a kind of site that you just absolutely couldn’t build with WordPress, especially it you extend it with the right technologies.
You should really kind of understand the kind of offering you want to build whether you’re building something very editorial, or something that’s focused on serving data and APIs in like a really high-volume scalable way. You know, there are technologies that are greater and better meant for it and that’s where I’d start.
It’s also worth understanding that the technology is really just one element. It’s really important to understand how the technology plus what kind of resources you have. If you have, you know, WordPress plus a bunch of amazing php developers, that might be a great choice to build a really kind of data-heavy, interaction-rich site. If you have WordPress, but you know, no developer help and you want to build something complex like that then it’s not a good choice.
A lot of platform choice hinges in parallel with the question of what kind of team you have to work on it.
Moderator: Okay, thank you, that’s actually all the questions we have and we’re just about at noon, so thank you both to Peter and Dan for taking the time, and thanks to everyone for listening. As a reminder, we’ll be sending a survey evaluation along with several resources and Peter’s contact information.
So thanks again everyone and have a great afternoon.
In November we’ll be hosting VIP Training Days, our intensive, one-day, in-person training courses led by a team of WordPress.com VIP instructors, in both San Francisco and New York City.
In each location, we’ll be offering our existing Developer Fundamentals I and Superuser courses, and our newest developer course, Site Security & Debugging. VIP Training Days courses are limited to no more than 20 people with each team of VIP instructors which ensures lots of hands-on learning and interaction.
Developer Fundamentals I — for beginner PHP developers & advanced PHP developers new to WordPress. A great review of WordPress fundamentals and best practices and the codebase, with a focus on themes and plugins.
Superuser — for site administrators, editors, and trainers for large or multi-author sites. A deep dive into the entire publishing process as well as managing users, comments, social integrations, mobile, and more.
Developer Fundamentals: Site Security & Debugging — for experienced WordPress developers. Attendees will learn how to think like an attacker and exploit the vulnerabilities before fixing them with security best practices and various debugging techniques.
These courses are suitable for both self-hosted and WordPress.com VIP sites/superusers/developers – the large majority of the material will focus on core WordPress functionality/features. You can read on below for more information about the other courses, or go directly to the event registration pages where each course is also explained in detail.
For current VIP clients & partners, there is a client discount available if you register before October 10th – please get in touch for the discount code. If you’re planning on sending two or more participants to VIP Training Days, please get in touch as well as we’d like to offer you a special group discount.
More information about the VIP Training Days courses:
VIP Training Days: Developer Fundamentals I Training
WordPress Fundamentals I is a day-long, intensive course meant to introduce PHP developers to programming for WordPress. Attendees should be familiar with WordPress as a tool, and have a working understanding of its general terminology. Proficiency with PHP is also a must, but no knowledge of the WordPress code itself is expected. This is a great course for developers looking to build sites which will scale to VIP levels, and write secure and scalable code.
Proficiency with basic PHP development.
Awareness of WordPress as a platform, including common terminology such as a post, a page, widgets, and sidebars.
A local development environment running WordPress Trunk. We will provide a virtual machine ahead of time for participants who don’t have their own development environments, but they will be responsible for setting it up ahead of time.
Course Materials & Requirements
Each student will provide their own computer (laptop) for the course, with working wifi functionality. A lunch break and light lunch will be provided by WordPress.com VIP. Students should have a local working copy of WordPress trunk installed and tested prior to the training. To download trunk: http://wordpress.org/download/svn/
Intro to WordPress core, SVN, and Trac, history and culture
Developer environment and debugging tools
WordPress Development Best Practices
Introduction to Plugins
Actions and filters
Introduction to Themes
The Loop & WP_Query
More on themes
VIP Training Days: Developer Fundamentals Training: Site Security & Debugging
WordPress Fundamentals: Site Security & Debugging is a day-long, intensive course meant to improve WordPress developers’ understanding of advanced concepts. Attendees should be familiar with developing WordPress plugins and themes or should have attended our Developer Fundamentals I course.
We’ll cover the basics of writing secure code. Instead of just listing vulnerabilities, attendees will learn how to think like an attacker and exploit the vulnerabilities before fixing them. In the course of learning more about security, we will introduce various debugging techniques to help attendees find problems in the code faster.
Proficiency with PHP development.
Awareness of WordPress as a platform, including common terminology such as a post, a page, widgets, and sidebars.
Proficiency with basic WordPress plugin and theme development – actions, filters, loading assets, main core APIs.
Security: exploiting and fixing XSS problems in HTML, JS, and CSS
Security: exploiting and fixing CSRF vulnerabilities
Security: exploiting and fixing SQL injection problems
Security: exploiting and fixing remote file inclusion attacks
Security: exploiting and fixing clickjacking attacks
VIP Training Days: Superuser Training
In this course, you’ll learn how to manage and use the WordPress interface from a site owner’s point of view; as someone who will be managing multiple users, their permissions, and ultimately sharing knowledge with them about how to use WordPress to publish a great site with an active community and/or audience. We like to think of this course as our teachers teaching your teachers – those who will serve as the WordPress expert in an organization.
We’ll also do a deep dive into the publishing process so our superusers can teach their editors, authors, and contributors how to best use the WordPress interface. From creating and publishing posts to managing tags and categories, from mastering multimedia and images in articles, and bulk management of posts and pages, we’ll cover the entire publishing process from draft to done.
Users should have a working (beyond basic) knowledge of the WordPress administration panel / backend. They should be managers, administrators, or editors of an existing or future WordPress site with multiple users.
Course Materials & Requirements
Each student will provide their own laptop computer (no tablets) for the course, with working wifi functionality. A lunch break and light lunch will be provided by WordPress.com VIP to all students. For the purposes of the course, students will be given access to a WordPress.com site. Users will be requested to create a WordPress.com username if they don’t have one, and this username will be submitted to the course instructor. To create a WordPress.com username: http://en.wordpress.com/signup/
User Management: roles, permissions, and invitations
User Profiles: settings, preferences, and Gravatars
Comments: moderation, spam, and notifications
Creating & Publishing posts
Managing tags and categories
Mastering Media: images, galleries, and slideshows
This weekend members of the WordPress.com VIP and extended Automattic family will be present at two events: the Online News Association (ONA) 2014 Conference in Chicago, and WordCamp Europe in Sofia, Bulgaria!
At the Online News Association conference, members of the WordPress.com VIP team will be there along with a few of our colleagues from Automattic. We’ll be sponsoring a refreshment booth featuring coffee from Chicago’s Bow Truss Coffee Roasters, a sister company of our Featured Partner agency, Doejo. Be sure to stop by! Find out more about ONA.
At WordCamp Europe, members of the WordPress.com VIP team will be there, as well as colleagues from Automattic. We’ll be at the WordPress.com VIP & Automattic sponsor booth as well as I am going to be presenting “7 Habits of Highly Effective Enterprise WordPress Sites” on Sunday. Several other Automatticians will be presenting that weekend as well —see the whole WordCamp Europe schedule.
If you’ll be at either event, drop us a note in the comments! We’d love to say hello.
For WordCamp Europe, we ended up having two extra event tickets we’d like to donate back to the community. To get one, just leave a comment below and we’ll forward your information on to the WCEU organizing committee. Airfare, transportation, and all other expenses are not being provided and are at the expense of the commenter.
Okay, so I’m Simon Wheatley, my partner Simon Dickson is just over there and we’re from a company called Code For The People.
We’re one of the VIP partners and I want to talk to you today about a client who came to us, similar I guess to the Oomph guys,the Interactive One guys, just been talking about one thing, but dealing with many websites initially 30.
This is for a magazine publisher in the UK, so they wanted to move 30 of their titles initially on to this platform but they wanted one standardized theme, one standardized set of functionalities that they could use.
So our solution for them is based in a couple things that I’m going to talk about tonight one is the WordPress theme customizer and one is the way we’re handling layouts using widgets and widget areas so these solutions are things you can apply in other organization. You can have your WordPress themed cake made by my partner’s wife and you can eat it at the same time.
So you get in this way, using this customization but based on the standardized theme, you get to reduce maintenance and at the same time keep the editorial teams happy.
So I’m going to talk through three of the areas where we allow editorial control so obviously there’s colours, I’m going to talk about typography and I’m going to talk about layout.
So the first element, colour, we started off with the idea that we would have the user pick half a dozen colours and we would then do colour calculations based around on let’s find some complimentary colours let’s find some lights and dark equivalents and then we’ll be able to work out how of those six colours, we can deal with the header and the footer and the body post but that actually gradually became unwieldy.
So you get in this way, using this customization but based on the standardized theme, you get to reduce maintenance and at the same time keep the editorial teams happy.
We found ourselves adding more and more colour options to avoid a clash of dark colours appearing on dark colours or red appearing on green, that kind of thing and the solution that we arrived at eventually was that we split it into two colour palettes, so there are two colour palettes which we call palette A and palette B and then we split the page into three areas. We’ve got the header area which can have one palette assigned the body of the page which can have another palette separately applied to it and then obviously the footer which can have a completely different palette.
So there are three palettes there, with about 12 different areas and we’re just using the standard WordPress theme customizer to allow you to pick the colour for that we’re still doing a little bit of colour calculation, lightening and darkening and so on but essentially it’s the two palettes applied to different areas of the page. We don’t take the standard approach that some themes take of just injecting a whole bunch of CSS into the head. Instead, we’re using LESS with CSS Preprocessor.
Probably now looking at the fact that core have adopted SASS, we could be using SASS but at the end of the day it’s all CSS Preprocessing. It all really does the same thing, it’s taking variables from the customizer and injecting them into CSS and using that to build the final styles for the website.
It’s simpler and cleaner than shoving a load of overrides in your head. So that’s colours, let’s talk about typography. Obviously there’s a number of font services out there and we’re going to want to give 30 editorial teams a good choice of fonts for their websites.
So we’re using the Google Fonts API, there’s a wide wide variety of fonts there and we’ve built a custom control for the customizer so can pick say the open sans fonts and because we’re dealing with the API. We know that there are these variants and weights associated with that and then we can be applying a text transform so that you’ve got fully uppercased for the navigation, but you’re just capitalizing for the headers or whatever.
That’s the one customizer control, which has got three sub-controls within it we looked around and found a couple of those on the internet in the .org repository but they all seemed to be making a bit of a meal of it and we ended up making something that turned out simpler but works quite nicely.
It’s simpler and cleaner than shoving a load of overrides in your head.
What you’ll see we haven’t got there is a font size for each individual element. We’re not setting a font size for the heading and then font-size for the subheading. Instead, we’re setting a base font size and then we’re using multipliers up from that. So maybe 16 pixels or something and then the heading is 1.5x that and the meta is 1x that or whatever.
So let’s talk about layout. We started out with layout with some very grandiose ideas that you might recognize from other themes and options that you’ve got out there. We were going to allow the user to draw areas on the screen and we we’re going to then use those as widget areas and drop stuff into those and then we we’re going to magically work out how we calculated the break points so that you could you know have tablet portrait, tablet landscape.
Eventually we took a step back from that and realized we could accomplish pretty much the same thing but in a much much simpler way.
Eventually we took a step back from that and realized we could accomplish pretty much the same thing but in a much much simpler way. So if we look at the primary content area on the left there, we’ve got a grid of widget areas so we’ve got a widget area at the top spanning then we’ve got the two-column side by side and then we repeat the same again. But of course with the widget area in WordPress you don’t need to put widgets in it.
So if you wanted to have just a single column of news in the primary content area then you just put widgets in the double span that comes second in there. Or, if you want a two-column layout, then you can just use the top two. Every so often in the year, when you’ve got a promotional item, you can be putting that in your double span above those to columns, so it gives it a lot of flexibility.
Because it’s a known quantity, it means that we can scale down to the various breakpoints and we know exactly what we’re doing and we’ve got a really nice responsive website and that comes out really really well when you start actually putting content in it this website, the fields, they started building that yesterday at 11 o’clock in the morning and by 3 o’clock in the afternoon, they had a site, fully migrated, fully customized with all the old content in it from the old custom content management system and up and running, so it comes up through the breakpoints.
Nice shotgun advert there for the shooting season coming up.
And then the desktop, full desktop width…so let’s, just taking a look at this page, we’ve got one widget that’s controlling a lot of this stuff. So if you look at the news sequence of posts and the food and drink sequence of posts, they’re using the same widget, and that’s something that we call the post query widget which is essentially a wp query builder for those you who know what I mean by that.
It’s putting together a series of parameters by which you’re going to reach into the database, grab the post that you want and get to display them on the page so you can choose the post type that you want to display in the particular widget that you’re editing at the moment. You can filter it down by the taxonomies and then you can go to actually start displaying that.
We do that by breaking the sequence of posts up into sections, so section one here has just got one post in it, it’s a list with a large image. Section two, you’ve got two posts, smaller images, and we’ll show the author and we’ll show the date there. Then section three is just a text bulleted list without any additional detail in there.
What that comes up as is something like that so it gives you really quite a flexible display of how you’re going to pull the posts in and then how you’re going to actually show them on the screen and you could have all large images or all bullet points, pretty much anything you want
We don’t limit the number of sections there so another thing I wanted to mention was category archives so again, we’ve got a customizer control in there so select your category and then choose similar again to the way that we’re dealing with the query widget so similar, we look at the style that you want that in, maybe this category you’ve got some really nice images, maybe the review images you’ve got are great and you want to highlight that
So you’ve got the ability to customize the display on the category there, so I’ve whistle stopped through this we talked a little bit about colours, so we’re using the colour API a little bit of calculation, we’re using LESS in CSS Preprocessing there talked about typography, so we’ve used the Google Fonts API to allow you to choose a font we know from the Google Fonts API, what the variants are, so we can pick that and we can give you a transform, we’ve got the base font size we talked about layout, we talked about the post query widget and about the custom layouts for categories so has anybody got any questions?
Q: Are you guys supporting live previewing in addition to the standard customizer stuff?
A: Yeah, absolutely, so all of this stuff, I mean if you’re not familiar with the customizer, one of the great things about it is nothing is live until you click the save and publish so all of this customization is happening just for you personally so even with the LESS Preprocessing, that’s being piped off into a separate stylesheet which is only being served to the editor that’s actually doing the customization at the moment
Q: ( […] )
A: Yeah, we’re working with posts, obviously the built in post type which they’re using for articles, we’ve got a custom post type for events and for reviews as well so the post query widget that I showed you, you can say I want to see just reviews here or just events here and it will allow you to display those
A: Some of the titles that we’re dealing with are relatively low staffed So I don’t think that kind of title would be necessarily looking at clicks we have got an evolution of the post query widget which looks at Google Analytics and uses the Google Analytics API to evaluate what’s popular in a particular category so you can use that as the sort mechanism, but that’s not something that’s live on the site at the moment
A: Yeah, so the widget areas that are there for the, where are we, let’s skip back through yeah the widget areas that are here are exactly the same widget areas, they’re just, they cascade through with the different break points and we move them around so this is the full desktop width but if you can quickly scan you can see that the same widget areas are just linearizing basically as you move down through the sizes so it’s exactly the same stuff ([…]) absolutely yeah responsive break points any more for any more
A: At the moment, pre-3.9 the disadvantage is anything you do to a widget is live on the site immediately, post 3.9 widgets move into the customizer so we’re able then to choose the widget layout and mess around in the same way exactly the same was as I said for the rest of the customizer, you can change your colours, change your fonts it’s not live until you click save and publish so 3.9 is going to herald a grand new dawn in terms of that being able to get right before it’s live
A: The brief for the widgets was that it wasn’t so much of a manual curation process, so if we needed to manually curate this particular post into position in this particular area of the homepage
I guess you could get around that by hacking with tags, but it wasn’t a core part of the brief that we were able to do that, so using something like zoninator where you can precisely choose which post to go and in which order they appear in wasn’t a requirement we could develop a different widget that did something like that I think we would probably still stick with widgets we’re also looking at doing some work to customize
so you can take the homepage layout and then for a particular purpose maybe for a sponsorship section have all of the sidebars completely custom for that but hidden from normal view so It’s only when you’re editing that page that you go in and those side bars are only live when you’re editing that page, that set of sidebars so you don’t end up with this situation wherein the WordPress admin area, the widget section you’re looking at all the sidebars and there’s like 300 sidebars which one am I adding the widgets in and which one am I not we’re able to actually filter which sidebars are being shown for a particular purpose
A: Yeah exactly that principle yeah.
A: Yeah, so like I say, some of these are fairly low staffed publications so the key for them is probably that they’ll set something up and then they won’t touch it for a little while we’re using a plugin which is available on the .org repository called the customizer settings revisions which allows you to save what you’ve created so you might go like “okay, this is the Christmas layout” with all the pretty snowflakes and the lovely snowy red design and then you can pop back to that when Christmas comes around again or when Easter comes around or whatever you want to do thematically so we’re using that plugin for that purpose
A: So the ads are outside of the widget areas, they’re placed at various points in the page that we know how to deal with for again, for the responsive break points are we concerned about the responsive kind of nature of it and so on, yeah so we have, we haven’t got the ability to do the thing that really you only do to show your boss that the site’s responsive which is you know, move the site edges in and out and change the width of the page, the adverts won’t change at that point because they only change on page load, it will look at the width and then ascertain what ads you need and then load them at that point does that answer the question?
Josh Kadis is the web applications technologist at Quartz. At our August Big Media Meetup, he gave a short “flash talk” on building qz.com on WordPress, which we’ve shared here and republished now with the full transcript below. Quartz just celebrated its one-year anniversary, and you can learn more about it by reading our case study here.
My name is Josh Kadis, I work for Quartz, which is a business and economics site from Atlantic Media, which is the publisher of The Atlantic. We launched in September last year, and our most recent numbers for July were about 5 million uniques (views). My role at Quartz is I do the bulk of the WordPress work and then I’ve also been heavily involved in building the Backbone application that runs the front-end of the site.
If you haven’t seen Quartz, it looks like this. It’s a responsive web app, WordPress backend, publishes on JSON API, that gets picked up by the backbone front-end and the bar across the top under the word Quartz – that expands and that’s how you navigate between different sections and within a section you can navigate by scrolling up and down in the column on the left which we call the queue, or in the “item well”, which is the main content area on the right.
WordPress publishes the JSON API, and we get all the backend post authoring and media and we have some custom backend stuff, like a post type that allows us to publish the newsletter through the MailChimp API from within WordPress.
We have a self-hosted system for reader accounts, which is what you would use for the commenting feature that we recently rolled out which is more for annotating individual paragraphs within a post, and then managing your subscription to the newsletter The Daily Brief and that kind of stuff, so that’s also WordPress.
We’ve actually found that the comments that come back are less awful because people get to the specifics of what they want to say about this specific paragraph instead of a general “you suck”. That’s kind of nice.
We have this division of labour between WordPress and backbone where WordPress handles what you would expect: generating the basic HTML markup which kind of gives the page the basic structure and is useful for search engines. WordPress publishes the JSON API, and we get all the backend post authoring and media and we have some custom backend stuff, like a post type that allows us to publish the newsletter through the MailChimp API from within WordPress.
The order of the posts you see on the homepage is not initially chronological, it’s manually ordered by the editorial staff, that’s the ‘Top’ post. So there’s a plugin that allows them to do that with a drag and drop interface from among the recent posts. Backbone also handles what you’d expect on the client side: fetching data from the API, deciding where and when to render it on the page, reflowing based on the device and on the screen size. We’re doing some offline reading with local storage and all of the annotation’s functionality is contained within the Backbone app and the entire thing can be turned on and off without even touching WordPress.
The URL and getting Backbone and WordPress to interpret the URL in the same way is really where the two things come together. The whole site relies on that or else the front-end and back-end are out of sync.
So we have these two things and where do they really intersect? It’s here: The URL and getting Backbone and WordPress to interpret the URL in the same way is really where the two things come together. The whole site relies on that or else the front-end and back-end are out of sync. So just to kind of quickly walk through it, if you haven’t written a Backbone app before, the router is the foundation of it, it essentially determines how the URL is parsed and then triggers a series of events that come one after another and ultimately result in stuff showing up on the page.
Good URL design is really a key to what we’re doing.
To work, the router reads the permalinks, and Backbone has some kind of build in syntax for how you read a permalink and decide what’s a variable within that and what’s a key. The permalinks come back to WordPress to run off the rewrite rules, and the rewrite rules run Quartz.
Good URL design is really a key to what we’re doing. So something like this: http://qz.com/107970 is the URL of the most viewed post of the history of Atlantic Media, it’s about bees. This is something that doesn’t have to run through a URL shortener, doesn’t get redirected, both Backbone and WordPress will understand this URL and parse out that single ID in the exact same way. Here is a little bit of code from the router, grossly over simplified.
Basically the router initializes, you give it this regex, it looks for these core sections: ‘Top’ – which is, I explained, is the manually ordered, “here’s what’s important right now” segment of posts. ‘Most recent’ is the latest one, ‘Popular’ we kind of calculated near real time using Chartbeat, ‘About’ is some static pages.
When the router recognizes one of these keywords from the regex and the URL, it triggers the core function which passes the particular one to this event which then gets triggered and a whole bunch of other stuff happens that results in a bunch of posts as you scroll through.
When you look at the WordPress theme, if you see rewrite rules, you would kind of recognize the regular expression: Top, Latest, Popular, About, and for both the front-end query, which is this first set of rewrite rules and then the API they both resolve to pass these two parameters, these two query variables to WordPress. API = true or false and then request = one of these things in this array.
For handling those two variables, we add_rewrite_tag request, we hook into query_vars and add API and then WordPress knows to look for those two things so that when the parse_request action comes around, we are able to, and in my oversimplification, I left out an if statement here, then we can fire up this qz API class and kind of pre-empt the main WordPress loops and that’s how we get JSON back without really needing to run through anything else that WordPress would do.
So this kind of enables us to go from a regular URL with a parameter like JSON tacked onto the end which is how in a lot of situations if you were building a JSON API on top of WordPress, you might do something like this and get back basically the same data structure that’s in the WordPress post object.
For us, we haven’t done that for a couple of reasons. We’ve gone with a custom API for clarity’s sake, being able to put all our endpoints inside API and then on the server side, we want to do all our processing of the meta data before we return it through JSON or else all that work needs to be done and that slows things down.
So for example, we’re able to return the URL to multiple sizes of the same image which we’ll ultimately be able to serve differently using this new SRC set attribute for different screen resolutions, stuff like that that is not necessarily apparent if you’re just reading the meta data straight out of the database.
So the Backbone side touches WordPress in a couple of other places. One is we need a way to keep track of version numbers, because they really are so separate. When we load the current Backbone version, it’s a different actual number than the WordPress version, so WordPress needs to know what’s what and keep one step ahead of the VIP team, really, because we put in a deploy to them, and we’re not sure when it’s going to come back so we want to know that as soon as it does, we’re ready and we’ll load the correct version of the application.
We’re also sort of separate from WordPress but still in Automattic, we’re using an Akismet API for kind of like profanity and spam filtering when annotations come in.
And then finally, there’s something that we’re working on that David in the third row in the red shirt is going to be working on soon, which is kind of figuring out how to keep the WordPress post templates and the underscore templates that Backbone uses, keep those in sync. It’s kind of hard right now, and ultimately doing a better job of that will allow us to load more of the application initially from WordPress, instead of having to process it within the browser in the Backbone app and then put it on the page.
But if we have stuff that’s sort of related to some changes in the WordPress theme and some stuff in the Backbone app, we put the Backbone app up first change the constant in the WordPress theme to sort of point to that new version of the Backbone application and as long as we’re sort of incrementing the number, the plug in will kick the higher number as soon as the new code with the constant is live on VIP.
This is just a quick look at annotations. You should all check it out, it’s really really nice. The responsive aspects of it are really cool and it’s just an interesting way of diving into the content. We’ve actually found that the comments that come back are less awful because people get to the specifics of what they want to say about this specific paragraph instead of a general “you suck”. That’s kind of nice.
Nico: Today, we’re going to talk about non-blocking WordPress. By non-blocking, we’re meaning asynchronous tasks. First of all, who is a developer in the audience here? Okay, so more than half, awesome. So we’re going to start by talking about non-technical stuff and then we’re going to go a little deeper, under the hood.
Basically the team right now is me and David Lake, as a software engineer and a project manager. Alex here was former development lead for more than a year. I want to give props also to 10up which is here tonight and John Bloch and Eric Mann who were really helpful in the redesign we did in the past year.
So the whole point of this presentation is to talk about having a fast website. Basically when you have a fast website, the user engagement is much better. I’ve heard that under 3 second websites, 40 percent of the people drop and only 40 percent of them will come back on your site.
The more they stay, the more pages they see, which is good for ad revenue and on a business point. Also, like Google and other search engines, like Google or Hummingbird penalizes when the website takes longer to load.
Also it’s good for the bounce rate and I know we’re hosting on WordPress VIP but it’s better for your hardware, when you have a really performant website.
I’m going to let Alex talk about our old TechCrunch to our new TechCrunch.
Alex: Yes, so our old site was really slow, it was about 17.4 seconds for a single page load. We’re part of the AOL network and from all the sites from AOL, we were the second slowest, pretty embarrassing against the peers.
Also, like Google and other search engines, like Google or Hummingbird penalizes when the website takes longer to load.
If you guys recall the old site, for the new site, after we finished the redesign, this is hearsay, but what we were told is that we were one of the fastest sites on VIP. I think Matt Mullenweg was kind of excited about that too which makes us excited.
Blocking is: a process that is blocked is waiting for some event such as a resource becoming available or the completion of an operation.
This little graph at the bottom, you can see, first page load of DOM complete, when you can start interacting with the page is about 2.9 seconds and after the first load, and second load about 1.9 seconds and fully loaded it’s 4.2 on the first load and about 2.3 seconds on the repeat, on the second load.
Basically when everything gets cached and such, definitely very exciting, pretty fast. So it’s good that there’s all these non-technical presentations so we can balance it out with a little more technical presentation.
We’re going to talk about blocking, basically, this is kind of a general definition of what blocking is: a process that is blocked is waiting for some event such as a resource becoming available or the completion of an operation.
The general idea is that you have a page request and it has to do a bunch of things before it can render the HTML and send it back to the user’s browser. So by architecting the page – one of the big things was to make our site extremely performant for all the reasons that Nico had listed off a moment ago. One of the big things that we did was try to identify anything that was blocking and push it off to an asynchronous task.
Some of the ways that you generally do it with other non-WordPress stacks are message queues, using something like Rabbit MQ or Amazon SQS to kind of send a list of tasks and then using workers, or in past I’ve used Gearman as a worker for processing things in a queue. Sidekick and Resque are big popular ones with rails apps.
Unfortunately these options are unavailable on WordPress but with a lot of help from 10up, we built out something that is referred to as a wp-Async-Task. What this is is an abstract class that we extend for different tasks that we wanted to make asynchronous.
So the nice thing is essentially it’s kind of starting a whole new thread to kind of do this work that you need done asynchronously.
So basically, it performs. When you make a request for something, if we kick off a second request back to the same site, which is a non-blocking HP request and it basically sends some information to the server and says do this task.
So the nice thing is essentially it’s kind of starting a whole new thread to kind of do this work that you need done asynchronously. A couple of examples of what we did on our site that you can see are CrunchBase.
We have, on most of our articles we have CrunchBase cards and you can kind of see – here Facebook and Snapchat as an example.This information all comes from the CrunchBase API. So imagine that one circumstance you’re loading the page, you have to get this information from CrunchBase.
Imagine that we have to go to CrunchBase, wait like a second or even half a second to get that information, for each of those different companies and then pull the information back and basically have it available then to render the page. It would be painful for the end user.
So what we do actually is we kick off an, if the information is not available, we kick off an async task, it goes and gets the information, caches it in our site, we basically store it in a taxonomy – a custom taxonomy for CrunchBase.
One of the big things that we did was try to identify anything that was blocking and push it off to an asynchronous task.
Then the next time that particular CrunchBase information is requested, it will be available to the page.So we then load nothing for the first request if it’s not available, then the next time the request comes through, it’ll be available for that page.
Another example is for recirculation. On the left rail of our site, we have some for example, we have tags and categories basically for that particular post and we pull in articles that are related just for recirculation purposes. Pretty much the same exact thing as a CrunchBase.
Basically, as far as images, we were just putting a 1×1 image on a CEN in the SRC attribute and then once the DOM was done loading, we were just using another attribute that we call data-srce and we were replacing the image source so that was super fast, seamless.
Again, it waits ’til the page is completely done loading, before it makes that call back, just for the best user experience. That’s it for my part, I’m going to pass it back to Nico to talk about some other things.
Nico: Alright, I’m going to talk about something we call the Lazy Loader. Basically on our front page and many of our different pages. We’re loading more than 100 assets, and it was a big part of us having a 17 second loading time.
We have different blocking API’s and the social buttons. Let’s say for a blog when you’re displaying 30 articles, you have to load a like button, a linkedIn button, a Twitter Button 30 times and these API’s are really slow and sometimes it’s a real hassle to finish the DOM to load with that.
Basically, as far as images, we were just putting a 1×1 image on a CEN in the SRC attribute and then once the DOM was done loading, we were just using another attribute that we call data-srce and we were replacing the image source so that was super fast, seamless.
And then like Alex was talking about, the tag accordion – basically all the accordion was closed so we were just loading the content as the page was finishing loading.
So once again, no one could see it and it was much better in terms of page load.
Also, our social buttons, they’re just like little images and as soon as you hover it, that would just trigger the loading, so these are examples that really really cut down our page load down from like more than 10 or 15 seconds.
Another example is caching, so here, basically what we’re doing, we’re having a refresh key that’s usually like 10 minutes and then when the refresh key is still okay and the data is still good we just returning the data and serving it. If it’s not the case, we only have one person that can trigger the refresh and then that will set the transient.
Another example, it’s a plugin actually, so you guys can check it out if you’re interested. It’s from another 10up person that used to work with us.It’s called the Live Cache.
So where you see the two arrows, it’s a little module on the homepage, when the stream is on and we wanted to be able to change the information there so the person wouldn’t have to refresh the page.
We tricked a little bit with a URL and a timestamp, so basically the browser will trigger a call to our backend every ten seconds based on a different timestamp and we will just get the information back if someone in the backend had refreshed it before.
I will let Alex here conclude on this.
Alex: So yeah basically, the point of our presentation was just to – it’s something you kind of have to do from the beginning and especially if you’re doing a redesign.
Just general idea, is you want to architect your site to asynchronously handle any heavy task to maximize your task performance.
One other note we’re told to tell you if we’re hiring, so we are hiring and if you are looking or know somebody that is looking in the Bay area, would love if you guys could email them now at dev@techcrunch as I’m no longer there.
Thank you guys so much and thank you so much to Automattic for having us present here.
Q: How do you factor speed with features, it’s a balance, so how do you deal with those decisions? Is it just the feature set wins and you just figure out how to do it?
A: Pretty much. So a lot of our features are driven by editorial, and editorial typically is very opinionated and had a lot of pull. I’m sure everyone has dealt with that for any media site.
So I think most of the time, if it’s not them coming to us, it’s them going to the higher ups and talking them into basically adding a certain feature and then us kind of figuring out how to architect it.
It gives some interesting challenges, but it’s been great, it’s been fun. I mean, I think Live Cache was a good example with that.
Like one of the big things was working against batcache, because we’re on VIP and having batcache, we have to kind of come up with a way that we can make page requests back and get up to date information.
But without taxing VIP too heavily and getting passcode review on VIP.
Q: Just a follow up, it seems like you’ve built tools to help you quickly integrate speed into everything you build, rather than having to tackle it individually for each piece, is that correct?
A: For sure, just kind of abstracting as much as we can, to make it reusable and I will give props to 10up again for a lot of that.
Nico and I, like I started about a year and a half ago, Nico’s been almost 2 years now and we both came from non-WordPress backgrounds.
We started probably a few months into our tenure at TechCrunch doing the redesign, so it was a lot of stuff we had to learn. It’s kind of a different world doing WordPress development.
Participant:Can you go back on a slide? Two slides, one more.
Alex: The one on Live Cache?
Participant: Yeah, thanks
Q: Yeah, just curious what your best practices are around caching, and content like that, what’s your TTLs and whether you’ve found any optimizations around caching that you’d like to share?
A: That’s a good question. So that’s a good question because we had issues with that plugin. It didn’t work for like two live events because first of all.
We were logged in and VIP has a different behaviour as far as refresh and cache for logged in users. When you’re just someone who’s chilling on the website, we we’re getting the headers from that cache.
Sometimes, so I don’t remember if it’s like too much or not enough, but sometimes we were having the right data from the back end, and then ten seconds later, the old data because of issues with cache timestamps.
Alex: Do you mind if I?
Nico: You want to chime in?
Alex: Yeah I’ll chime in for this one.
Alex: We were having an issue with Live Cache, you might be speaking of other assets…
Q: Yeah, I’d just like to hear general, just caching in general, what best practices you have for that like new content versus page speed.
A: Yeah, everything is basically, we said no headers from our side. Everything is kind of managed from VIP, all of our information, all of our content is through their CDN and through their hosting.
They kind of take care of that for all our static assets and such as far as the issue that Nico was just talking about.
One of the big issues with Live Cache is that basically you have to make the request back to the server with the right timestamp to make sure you’re getting the right text.
So for example basically we have these presentations that disrupt and they’re like 10 minutes long, which we’ve gone over a little bit but we’ll be quick.
When they switch presentations, somebody goes into the backend, in the widget and switches out the text. But, you have to synchronize the clock with the end user to make sure that they’re using the right, the same clock as you.
So our solution was to make that first request live_cache_check/1/. Fortunately the header on the batcache, the response is coming from batcache. It does have the proper timestamp so we use that to synchronize the clock and then accordingly all subsequent requests, which are every ten seconds will be based on that, based on the synchronization.
Q: So assuming no one messes with the clock between the first request and after that?
A: I guess, it’s valid, I mean just to speculate, I guess it’s OS specific. So it’s kind of relying on the timer within the browser and within the OS to kind of, as to the interval that’s been set.
Participant: makes sense, cool.
Q: Is the wp Async plugin, is that available right now?
A: Unfortunately not, we have it, we were looking, we were talking about like open sourcing that and I guess we just have to get it cleared by a few different people but I think it would be useful. We think it would be something useful to open source.
Participant: Sounds like it.
Alex: Yeah yeah, for sure. Cool, thank you guys so much.
My name is Andrew Nacin, I’m a lead developer at WordPress. I live in Washington DC. I’m talking about, really quickly, how WordPress evolves without breaking absolutely everything. I’m going to give two case studies.
First, some general considerations and what I’m talking about for this is three in particular:
One, we don’t really rush to fix what isn’t broken. There are a lot of other platforms out there that might rewrite a lot of their API’s pretty much every version, every three years. Just to name a few, like Drupal. We’re not trying to do that; we are trying to evolve at maybe a slower pace. Our slower pace might still be over 3 years; it’s just over six or seven releases.
We’re also trying to really make it worth it. If we are going to rewrite something, we’re going to go all out. And that’s actually one of the case studies here.
And then the third one is backwards compatibility. As you probably know, we’re presently backwards compatible, or 99% backwards compatible from version to version. Great for users, great for the ecosystem, it’s actually not that great for us, but that’s okay, we accept that.No “breaking changes” means that users don’t really need to worry about this when they update it. At the same time, we have to absorb extra technical debt. So if you look at the new WordPress, you’ll find some things that you’re like “wow, that’s still there”? Yes because the plugin that worked five years ago that was perfect then, should still work now. We don’t try and just deliberately break your code.
We’re also trying to really make it worth it. If we are going to rewrite something, we’re going to go all out.
First case study: WordPress 3.4 – Themes API
So the first case that I’m going to talk about is WP theme, which came in WordPress 3.4 so this is actually a bit of a comparison from 3.3 to 3.4. There were some really big problems with the existing software wp_get_themes(). It was actually terrible. It’s a function that was not an API, it was that bad. It had a huge memory footprint; we’re talking 10s of megabytes, every time you called it. Very slow, weak error handling, pretty much nothing was good about it. It couldn’t fit into a single cache bucket, that’s how big the data was. So if you tried saving it in the cache, and WordPress.com tried doing this, they had to chunk it into individual keys, and put it together when it was done. It really didn’t make any sense. You’re probably doing it wrong if you ever have to do this with your data. Getting page templates for one theme required loading everything.
WordPress.com, which had at the time, 170-something default themes and on top of that something like 600 VIP themes, which by the way aren’t used on almost all sites, they were loading 700 pieces of data looking up every single page template for whatever Duster’s page templates are. This really didn’t make any sense at all, was really slow, and that’s why they had to cache it into multiple cache buckets. It was also really painful, because it’s one giant multi-dimensional associative array. If you try adding a feature to this, all you’re doing is making it worse.
We also needed this for an absolute ton of things, some of these on here I didn’t even know existed. You can dig into this a little bit, like multiple theme roots, cross-root parent themes, things like that. You can actually nest themes inside directories, which is what WordPress.com does for some stuff. Really weird – we had to support all these things. And you can’t break anything. You have to be 100% backwards compatible.
So how do we do it? First is that we scrap the entire array, this giant mess of crap and try to do one object with WP_Theme. So you have a method like get: $theme ->get(‘Name’) or get (‘Description’), or get (‘Author’). And also getting a header for display, so we have a display method, which automatically translates it, which is a new feature in case you’re doing that kind of stuff and also dealing with HTML markup – that could each go into some of these pieces. And then a number of helpers that can mimic a lot of the regular functions that you’re already seeing so you’re very used to all the different pieces here. Dealing with page templates: “hey look now we can only fetch one theme’s page templates”.
So we were looking through this and the pages’ page, the list table, was 5-6 times slower to load than a post table just because we were loading the list of page templates for one theme, for quick edit, that you don’t even open unless you really need to. Really stupid, but that’s kind of sad right? And things like template files, which we were only really loading for the theme editor, which on WordPress.com is disabled, but they still had to on WordPress.com load this for every single theme. That’s 40% of all of its memory.
It’s not easy to build code that just works from version to version, and many of you might not even need to deal with this. At WordPress, we do. It makes your lives easier, so you can buy me a beer later.
Let’s use WordPress.com as an example, even though I don’t work there, because they’re obviously working on a pretty incredible scale, especially the number of themes they have.
So the next step that we did, step two, is a lot of magic. We have this problem where we have $theme passed into functions, passed into hooks. How are all of the old, all the existing plugins working with this going to be able to accept this data? So in PHP there’s a class called ArrayObject, that implements a few interfaces, one of them is called ArrayAccess. What it enabled us to do is things like this, where $theme[‘Name’] we’re able to treat that like a function call and then we can wrap it in this case, with the get map: #theme->get(‘Name’). Sometimes, this array, for whatever reason, one of the functions, WordPress decided to convert to an object, so we had to handle that as well. Well, there are some magic methods in php including __get() and __isset().
So now, we’re able to take this giant, stupid array and convert it to actually, a really smart object. We’re doing this in WordPress as well with some other things, we’re also doing dumb objects like a standard class and converting those more specifically to proper objects like wp_post if you’ve been looking around. A lot of this is just for sanity reasons, not even for future reasons. So, function __get($property), we’re able to map exactly where we need to go. Caching is non-persistent by default, but it does exist, which is pretty cool. So, the problem is that if you had caching on persistent and you would maybe doing a deploy, if you’re not actually clearing that cache, well there’s a problem. You need to be able to do that. APC is buggy enough as it is when it comes to upcode caching, you don’t need to mess with it here as well. So it does support persistent caching if you know what you’re doing. So WordPress.com for example has this enabled. They wanted to be able to store in cache bucket, so they do. So if for some reason, you ever wanted to enable it, there is a filter:
Overall, the class itself is somewhere around 2,000 lines long. The patch that landed, that had the bulk of this was somewhere around 14,000 lines long and we wrote it in about six days and it worked.
And you can turn it on and it will work. So if you’re dealing with a lot of themes, maybe not just one on a giant multi-site installed, this might be something for you. So you have this new API that deals with array( ‘allowed’ => true ) and array( ‘errors’ => true ) and all these these different pieces. array( ‘allowed’ => true ) being for multi-site which is again, something else that we were able to speed up quite a bit.
And then we also had to make sure it worked. So, on top of a lot of functional testing, this is a few years ago this stat (29 tests, 684 assertions), there are even more tests now. Existing tests had to demonstrate of course backwards compatibility, so those existing tests did not break when we did all of this. New tests ensured the WP_Theme returned what we expected and then we practiced TDD (test-driven development) specifically when we were dealing with any bugs that came in.
Overall, the class itself is somewhere around 2,000 lines long. The patch that landed, that had the bulk of this was somewhere around 14,000 lines long and we wrote it in about six days and it worked. Also doing profiling, you’re going to find bottlenecks in some cases where you had no idea you had them. So maybe we saw some pages that were slow and we didn’t really understand why, sometimes a post request is actually slow, you might not notice this because you might think “oh yeah, Chrome is just resolving the DNS, that always takes forever”.
Profiling is really important for these things. So, for example, this is a KCachegrind right here, we were able to take 28% in theme.php to 0.76% of the page load. Total time cost was reduced by a factor of almost 6 and then we’re also able to look at weird things like this.
For sanitize_titles_with_dashes, one particular thing, we were searching for a theme on the backend and for some reason it was taking 42% of the page load. We we’re like “what the heck is going on here?”. Turns out it was being run 3529 times and here’s the best thing: the function call shouldn’t have even been there. So we removed it and the entire page sped up like you wouldn’t believe. It actually went from 44% to basically nothing. So we were able to speed things up – we would never have found this because it’s just like “oh Chrome is being stupid, it’s not loading”. No, it was actually a really slow request.
Second case study: Taxonomy Meta and Post Relationships
You might have heard of these, you might be using them, you might be using post-to-post taxonomy meta plugins. Working on this, this is a roadmap that was posted to make.wordpress.org/core a few weeks ago, during WordCamp San Francisco actually, explaining all the different things that we’re working on to make this happen. Now, the problem if you’ve worked in depth with terms is that shared terms was just a bad idea, we shouldn’t have done it. It came in actually, and this is a really funny history, originally in 2.2, was removed and went into 2.3 with a new schema, based in part on Drupal’s schema at the time. So the one time we did copy them, we realized we made a bad mistake.
Term_id as you might be familiar with – let’s say the term_id is ‘apple’ and then that ‘apple’ term might be in multiple taxonomies. So you might have the ‘apple’ in the tag taxonomy, and ‘apple’, in the company taxonomy. The problem is when you, let’s say, rename the ‘apple’ to ‘applecomputer’, suddenly things begin to go wrong very quickly. Unfortunately shared terms have very limited practical benefit. It would be much better if they were separate. So we have these two tables: wp_term_taxonomy and wp_terms and these fields in them, and you can kind of see how these come together with term_tax_id being the primary key for one, and term_id being the primary key in the other table, things get related and we have a third table of relationships. The joins are a mess, slow things down, and are not really fun.
So we’re going to add a new table, like this and if you see, it’s the exact same fields as the term_tax_id table, except we’re going to add all the fields that were in the term_id table. So we’re going to drop one of these tables and move all of the fields into the other table. We’re going to reduce everything to one table. Now if you’ve ever written a direct query for this stuff, if you’ve ever dealt with this, “Oh crap, things are going to break” right? “I’m sorry, it was Nacin’s fault, blame him”, or whatever you want to do. We can actually fix this. In fact, we didn’t come up with just one way to fix this we came up with two.
The first one is that we’re just going to redefine what a table means in WordPress. So if you try and reference $wpdb->terms, it will simply think, “oh, you must mean the $wpdb->term_taxonomy table”. So we’re actually self-joining. So if you’re doing interjoined terms on “terms_t” on term taxonomy and you’re do all these different fields, it’s just going to join itself. And because these fields are a superset, it will work. You also can do something like this with a view. You can create a view in MySQL as of MySQL 5, which is the current version for WordPress. You’re able to do something as simple as this: we’re able to re-create our old table in place. So after we do all these crazy upgrades and everything else, we can make this kind of work. We tested this with WordPress, we dropped the table, we merged all of them, took a 20-line patch, without changing anything, all the direct queries and everything worked. So plugins that are trying to do anything special with terms, we can do this to the point where we’re really not going to break anything. Pretty cool.
We’re also doing this over the course quite a number of releases. So, we’re able to combine these term tables, let us have on ID, finally we have one real ID that represents what a term actually is that we can pass around. Term meta is finally within reach, maybe post-relationships isn’t far behind, because that might depend on term relationships and that becomes a whole other story. So we have this long-term road map, unfortunately this actually requires we integrate a half dozen different changes, each of which is dependant on the previous one, over at least 3, 4 or maybe 5 releases.
So, we’re not rushing this, we can’t rush this. We need to do it step by step, to make sure that we don’t break absolutely everything. Maybe we slow it down, speed it up depending on how things go. Ultimately backwards compatibility prevents a lot of challenges. It’s not easy to build code that just works from version to version, and many of you might not even need to deal with this. At WordPress, we do. Iit makes your lives easier, so you can buy me a beer later. And we continue to evolve at rapid speed, WordPress 3.7, if you don’t know about the plans, is being released in October, 3.8 which will be a little bit of a different release in December. And if you’d like to join us helping out, I would go to make.wordpress.org/core and check those things out. (For the latest WordPress version, go to www.wordpress.org)
Q: For the major version changes, now that we’re speeding up the timeframe for releases, typically in the past it’s been every 6 months for a major release and it’s been documented that you go back and support the last major release version. How is that going to change now that we’re speeding up the major versions?
A: Don’t know yet. In this case we’ve always aimed for 4 months, and normally end up at 5 and it slips to 6 or 7 on occasion. Sometimes we’ve actually been really on target with those. So what we’re trying to do now is 3.7 is acting as a bit of a reset, I can talk a little about 3.7.
3.7 is a platform-focused release, we’re doing it in 2 months. It’s focused on a few different things, Scott was talking earlier about some of our developer tools stuff. We’re trying to improve a lot of our own processes, so whether it’s trying to make it easier to contribute, trying to make it so tickets don’t rot for a long period of time, or people aren’t getting feedback or whatever it is – that’s important. And then a lot of our developer tools as well.
So this is really cool: you might have seen this new develop repository on WordPress.org which replaces the old core.svn repository. This is pretty interesting because it pulls in all of our tests, all of our tools, our bill process now, everything is in one place and finally we’re trying to modernize here. We’ve been around for 10 years, we can start to do it at this point. And then we’re rebuilding a lot of our developer documentation. So if you go to developer.wordpress.org right now, you’ll get a “Coming Soon” message, but we’re working right now on fully automated code reference that is very smart and deals with documenting every hook, every function, all from inline documentation to what else it can need from code. (This feature is now live, check it out)
The actual focus of the release in part is security, stability, updates and fixing a lot of bugs. We’ve already closed around 300 tickets in the last 2-3 weeks and I expect that number to continue to drop successfully with each week. This won’t affect most of you, because you will be doing manual deployments anyway, but in 3.7, security minor release updates will happen automatically. They shouldn’t be nearly as painful as they are and we want to try and ship this to you – like 5 people just went “oh God, what are you doing?” – don’t worry, relax, you can turn it off and in most cases, this won’t affect you. If you have things like automatic updates turned off on your dashboard, then this obviously will not occur. Which you should, and if you don’t, and you’re trying to do deployment anyway, how one of your editors isn’t screwing it up by pushing a button, I’m really interested.
Any further questions on 3.7? We don’t know how yet we’ll work on that, but that said, because we’re going to start doing automatic updates for security releases, we’ll probably support security backup a few more versions as well. If only because we can be much more confidant shipping those and because our security vulnerabilities we’re dealing with now are really esoteric.
We’re talking about like safe HTTP requests and XML injection and things along those lines, we’re not really dealing with the run of the mill like XSS that we might have been dealing with 5-6 years ago. So, supporting further back, yes, that said, I don’t think we’ll always be doing too much with these cycles, I would like to settle between 3 and 4, but we really don’t know yet. 2,3,4, not sure. 3 releases a year would be great, 4 maybe, I don’t know.
Kevin Newman from Harvard Business Publishing, presented “Adapting WordPress’ role within a larger content strategy” at the recent Big Media & Enterprise Meetup in Boston. We’ve shared his presentation previously, and we’re publishing it again now with full transcript below.
View the presentation slides here:
I can tell a story about where, what blogging means to HBR and what role WordPress plays. A little bit of history first. HBR is a storied print publication. It’s been around for 90+ years, one of the cornerstone publications in management science and practice.
It’s a great product and I love it but right around 2007, 2006, there was a desire to push the boundaries a little bit and get out of the ivory tower, see where our new audiences could be.
This is slightly before my time, I came on board around 2008, so as I started to experiment with different content forms, namely blogging. I ended up going with Moveable Type. Moveable Type, at the time, had a feature that easily allowed for multiple authors, static publishing of an asset which was attractive.
WordPress and Moveable Type way back when, were kind of neck and neck and it was really a coin toss whether or not we were going to go either way. We ended up going with Moveable Type and that’s where myself and a couple of other people were hired to help grow the business a little bit, to help it along.
Moveable Type was not literally, but just about on somebody’s desktop computer under their desk being posted in kind of a hacky way and they wanted to make it a more sustainable business.
We’re also seeing that readers are coming to the site and some readers are getting just as much value out of a blog post or what’s now a blog post, as they are in the print article.
The point of the digital business at the time was to develop the markets in advertising and subscription and e-commerce. At the time, they were seeing some success in e-commerce.
So at the time, Harvard Business Publishing was a catalogue site, but they felt like, the board felt and a number of people felt like we can serve readers as well. So we’re looking to create that new audience, meet that new audience without sacrificing the quality and carry it forward, or so the intention was.
We went to Moveable Type, everything was going great but then we started to hit up against a couple of constraints. Long story short, editorial really wanted to go with WordPress and it ended up working out really well in the technical sense as well.
The editors love it, the ad sales folks love it, it does a great job making sure that the tags that the editors are putting in make it all the way out there.
So we ended up transitioning to WordPress last year off of Moveable Type, working with Automattic VIP to get all of this, all of our, what would it be, 4-5 years of blogging, all the meta data, all the operatives, all the work that went into getting onto WordPress.
It went very very well all the expectations, actually exceeded all the expectations. The good news is that everybody absolutely loves it, absolutely loves it. The editors love it, the ad sales folks love it, it does a great job making sure that the tags that the editors are putting in make it all the way out there. There’s nothing in between.We want to make sure everything is accurate.
The other good news is that there’s a deep community there. There’s a lot of people that use it if we go to some sort of conference, either technical or editorial, odds are if we talk to someone about the process, they’re also using WordPress.
More good news is that there’s tons of developers, tons of plugins, if you don’t know how to get it done, or you’re just lazy, you can probably do a quick search and you’ll find a plugin that will get you a good way there. So it’s been a great decision across the board, now we’re heading in a new direction.
HBR.org is in the midst of a pretty big redesign. A lot of it’s visual, there’s some underlying plumbing that’s getting changed as well and we wanted to keep WordPress.
So one of the key strategic changes that I wanted to mention is that we’re moving towards, we’re coming from a model that works very well, where there’s pretty hard lines between print content and online content, stuff that is not in the magazine.
What we’re going to do is even that balance out a little bit, where an article, is really an article. Certainly there’s a difference between a print article and an online article but we’re also seeing that readers are coming to the site and some readers are getting just as much value out of a blog post or what’s now a blog post, as they are in the print article.
With this redesign, we’re going to kind of even the playing field a little bit and everything’s going to be presented to the user as helping them solve their problem.
Less of a division between what’s in the issue versus what can you find online exclusively. So it’s just going to be content: “how can we help you solve your management problems?” “How can we make you a better manager?”.
It doesn’t matter if it’s a blog, doesn’t matter, well it matters if it’s in the print magazine of course, subscription, it matters. But readers don’t see the difference that we do, we need to make sure that we’re solving their problems.
So we look across the site…Barack Obama organizing for America 2.0. That could be almost anything, it’s not necessarily related to an issue. WordPress is a big part of that.
As we move forward, we’re taking all the entire archive of HBR and the entire archive now of all the blog posts and we’re putting them all in WordPress. We’re going to have every single piece of readable content and actually multimedia as well, in WordPress and part of that is because of technical flexibility.
It’s under the theory of let’s let the best tool do their job, in other words, we feel like we’ve found a great tool and everybody’s happy.
My job, my team’s job is to make sure we’re never painted in a corner. We can do whatever we want next year if we want to change directions. WordPress is a fantastic tool for that.
The other reason we’re doing this is because editors love it. They absolutely love going to this tool, they use it all the time. I don’t have to deal with it. I don’t have to, we built so many tools for them, and you know some of them were great, some of them weren’t, we don’t have to worry about that now. It’s under the theory of let’s let the best tool do their job, in other words, we feel like we’ve found a great tool and everybody’s happy.
So next, is a quick snapshot of our architecture. This is our current architecture, so very quickly you can see HBR.org there and that site, the core of the site is an application, a Java-based application, Jvos specific application server, and it integrates below the line.
Those are deep integrations, those are behind the scenes. In our core integrations we have databases, e-commerce, search, user services and platform Web services that we share with other units in our business.
We can do whatever we want next year if we want to change directions. WordPress is a fantastic tool for that.
The big change with the redesign is that it’s gonna move WordPress into our fold. What we’re going to do is because we have the entire archive posted on the WordPress instances. We’re going to integrate with it on the application level, rather than have WordPress serve up these pages.
So now within the same mix of the database is the search, the user services, all the other integration services that we use like e-commerce etc. The whole point is that the application is matching the content with the user, we’ve been able to chip away at this for years and now I feel like we’ve got it.
So WordPress is the content and all these other services are the user. Like what is the user doing? What is the user buying? What apps are they seeing? What can we do to better serve them?
And that’s the way we’re going, so that’s it in a nutshell, how’d I do? (You have 2 minutes left) I have two minutes left? I was suppose to be here with Matt Wagner, he’s sick.
He’s the one that really owns these two slides, so I probably didn’t do the amount of work justice, but it’s incredibly important, especially on the tech side.
We’ve been able accommodate the business with this kind of strategy over the last few years, making sure that we would serve the editorial side and serve the user side and so far so good. WordPress is a big part of that.
Taylor Buley of Parade.com presented at the Big Media WordPress Meetup in New York City on how his team uses the theme customizer to make editorial changes on the fly. We’ve shared previously, and we’re publishing it again now with full transcript below.
[wpvideo 8Uap5hMd w=640]
Parade.com/customizer, It’s a Google app, nothing special. What I’m going to try to do is, I’ve done a webinar on this before, so I can talk your ear off on a customize API.
So what I’m going to do is try to be demo focused so I’m going to tell you what I’m going to talk about and show you what exactly is Parade and get into the developer side of it.
By the end, I hope that I’ve convinced the developers to be on the side of the editorial people and that side is the same one we heard earlier, which is I think the quote was “what I would really like from WordPress is an interface for editing the page while I’m looking at it”. And so that’s what I’m going to talk about today, there is such an interface, it was released in WordPress 3.4 and it’s really awesome.
What I’m going to do is first talk about what the WordPress customizer is, that’s the API I’m talking about and then we’ll show you how it works. It does exactly what we described earlier, which is you look at the page and you actually edit.
So who are we at Parade, we are a website, I like to think first, but we are a print publication, we’ve been doing the model that Newscred has been doing since 1941. We have a network of 700 newspaper partners, they carry this thing, it falls out of the newspaper for some people. Some people look through all the advertisements specifically to find it.
We have two such magazines, one was called Dash and the other was Parade. We’ve been around forever but this year we did a redesign and a rebranding and we went from all caps to uppercased. We also redid the entire website and CMS architecture along with it so if you don’t want to read this, I’m sure you don’t, just go ahead and pass it around. I just want some people to be familiar if you haven’t ever seen the print publication. I did not grow up with it, my Grandma did. I did not.
This is us, this is our website. It’s designed by Athletics, an amazing design firm. James Ellis is here today from Athletics, if you’re looking for an amazing designer, pitch his work all day. We have this thing it’s called Promo block, we have this thing called a grid screen, we are a lot like every other media website on the planet, right?
We have an article template, we have channels, we have a homepage, we have special types of articles that people who write these special types of articles would love to think that they’re different than everything else, but in WordPress this is all just a post.
So we are very uninteresting in how Parade.com uses WordPress in general. I’ll tell you, we use all of it. Except for search, we use Google custom search, we never queried MySQL live, ever, it’s a terrible idea, if anyone has thought about it.
Besides from that, we use everything, so what we’re looking for is when we have such a system that had a windows-like interface, an old CMS called open-CMS and it was a great idea to bring on, it’s open-source, well supported and all that.
Except, the developers who previous to our team let it rot and when you let a CMS rot, you get a piece of shit, right? And so what we had to come into is, this year we came into January and we had to start over. We didn’t figured out how to nicely wrap WordPress as a content engine underneath the MySQL and Mongo database that pushes stuff out via Real Time’s indication API.
Instead, we just threw everything away and the way we threw everything away was first we developed a mobile website, a proof of concept, make sure it works, advertisers liked it, we developed the rest of the website around it, had the mobile website up in January, my first month at the company, and had the rest of the website up in April.
The reason why we were able to do this was discussed by the NY Times developer, WordPress is nimble, WordPress does all of this stuff and if you’re trying to figure out a way to reinvent a UI that looks at the page while you’re editing it you just look deeper into core, it’s there and so I would encourage you all to.
It’s great it’s fun as a developer to develop elegant systems that run on multiple different types of instances and communicate across rest API’s and XML RTC and this and that, that’s all great, but WordPress is great too. What I’m going to show you today is something I think is really really cool inside of WordPress that people haven’t talked about and it’s the Customizer API.
So this is TwentyThirteen, you’ve seen it before. Has anyone not seen this interface specifically? So what I’m talking about it is not the theme, you’ve seen the theme before, it’s TwentyThirteen, this, has anyone not seen this before, has anyone not explored the theme, so you guys have seen this?
You know what it is – interface, website, this is basically an iFrame the way that this works is this is WordPress admin, basically we’ve got wp-admin, Customize.php up here.
What it does is takes the get parameter url = and then injects that guy into the iFrame and you’ve got post message communication across these guys and what you’re able to do is get live previewing and that’s what I’m going to demo today is a way to live preview so a little bit more on what it is in general.
So this is WordPress.com, you may have seen this too, it’s also the customizer API, it’s fancier, it looks better than what I’m going to show you today and all they did was just style this in CSS. You can take the core principles that I’m presenting here today, the very cool things that I hope you like that we’re doing and you can make it look as fancy as you want.
It seems like a very simple statement, matter-of-fact, everyone will agree here. Things on the web are best produced while you’re looking at them, right?
You can make it flat and take away the shadings and all that, but it’s still WordPress. So that’s kind of the message I’m trying to say today is “why is this so good?”
So this is our interface and what we’ve got is anything you can see on our website is editable. Why is that? That’s because I’m a journalist, I worked at Forbes as a reporter, I’ve worked at the Wall Street Journal, worked at various places then I got into development and worked out of the Silicon Valley bureau we had POS CMS at Forbes.
Through mutiny internally, WordPress became the CMS, it was awesome. But then we became the team in charge of the WordPress CMS site, eventually we got some of our pages stripped away from us. We went from having article pages, general pages, all that to just providing the editorial engine to someone like […] and now they’re selling this thing on the marketplace and you can actually license it which is awesome for them.
But we come from this legacy of being journalists, we’re editorial people, my boss Steve McNally is an editorial person, he’s a private person. What he doesn’t want is somebody in the backend, editing the front end of the page.
It seems like a very simple statement, matter-of-fact, everyone will agree here. Things on the web are best produced while you’re looking at them, right?
That seems very matter-of-fact, I don’t think anyone would disagree with this and yet every CMS we see on the planet is designed to run a back-end and a front-end and there’s a back-end and there may be a preview button but that takes you to the front-end. Or you could try to do a preview in an iFrame and that’s special because that one’s on the back-end. But it’s still just the front-end loading the back-end.
All of these are just fancy ways of doing the same thing Customizer API does it elegant and simply back-end wrapped in an iFrame with a front-end in it and what we get with this is you are looking at the actual page.
So you can do the fancy responsive thing where you show your boss like “oh cool I can scale by 30% which means when I go in and go out and it shrinks and all that, you can see exactly what you’re getting and it works on mobile and on everything else – why?
These are all the different things that the Customizer tool offers so it’s got check boxes, it’s got input fields, it’s got an HTML 5 drag and drop image picker tool, it’s got color pickers, it’s got radio buttons and you know drop downs.
It’s essentially any form you’ve ever created is already supported, any field you would like to invent, is extendible via the API, we’ve done it once but not very frequently because we don’t need to – the input button, the radio button, it does everything we need.
I’ll show you what that looks like – I’m going to pull up our development environment. I’m going to hope it works, it’s a private development environment. Make sure your wifi’s sniffing, I’m sure this is a public access point, it’s not protected, so go ahead, I’ll reset my password by the end of this.
We’ve got a stamp protector plugin so when it detects a bad id it tries to slow down the spammer, so it looks like it’s flagged me also.
I don’t know what I just clicked into, but it looks like it’s going to be a channel, so what you’re looking at is the exact same tools we ask our editors to use. What we do is we say “editors, you have this thing called a promo block, this thing called a page view, a tag bar”.We’ve got share buttons just like everyone else.
You know there’s really nothing too special here about the design itself. What is special is that it works across tablet, phone, wide desktop and desktop. So if you look at this on your mobile device, and I encourage you right now to do that so we can get some extra visits to the website.
You’ll see that it’s a lot of the same design interfaces it’s just what we did is tablet is a two grid across, a phone is a one grid across. It very much makes sense, I appreciate the design thought put into this, but when I was given it, it was static flat files in CSS so I did not have to do front end development of CSS, I did not have to do front end development of the mark-up. But we were tasked to take this site and bring it to life.
So what you might do is create a theme options plugin or something like that you know we have some of those or you could do what we did and take our thing. Okay, so what did I just do there? Nothing special. This is just a type, this is post meta, this is going to be stories posted. We’ll be looking at different options, so site options, we’ll be looking at posts and sorting posts meta. Your member tools, it’s going to be sorted as user meta.
There is zero custom tables in our WordPress install. That is on purpose, zero custom tables alright, so all of this is default WordPress and there’s nothing special going on here. So what we’re doing is live previewing – if I had a sponsor label, that would override this.
So all this is is the same stuff you’ve done on the server side, the templating, your wp theme thing, we’re now doing on the client side as well. Where we’ve gotten away with this a little bit better is we’re using front-end. We’re using handlebars for our templating system so we’re able to use php, the same templating system that we use on the front-end, which is a little bit of a cheat.
Another big benefit of this is we can prepare advertising campaigns for free, live them up, screenshot them they’re done without ever actually pushing any code, making any changes.
The one of the big challenges with this is that you have to account for all the different states, so if I remove the sponsor text. Either it’s going to show a bug or goes to live preview cause you have to think about all the different possible UI states you’re in and implementing them in multiple places.
This doesn’t come for free, but you’re able to do some other cool things, so I guess I’ll show a couple more. Davis did you save some images to this machine for me?
– Yeah, on the desktop.
Excellent – I’m going to use this very cool image picker tool, alright and now what I’m going to do is update the promo block. What I’m going to do is just I picked a file, using the file picker, it’s chugging along and probably uploading it right now, and I’m able to see what it looks like now, right?
So this is called a promo block image and what that means is it comes with aspect ratio. So this is inspiration from the “Don’t kill the kitten” if you’re a developer you’ll get that joke.
I’m able to see what the image looks like so we’ve got a photo editor who tries stuff out. She figures we’ve got these boxes that are blocking some of the action so we don’t want to get heads cropped off or things done and they’re able to just go in and test it.
Another big benefit of this is we can prepare advertising campaigns for free, live them up, screenshot them they’re done without ever actually pushing any code, making any changes.
A couple of really cool things going on: we do, this is more than what you’ll find in TwentyTwelve, right? So what you’ll find in TwentyTwelve is a wallpaper tool, and that’s how we found this, we were like “okay, this is really cool”, advertising wanted a wallpaper.
I was like “dude, WordPress has got this covered no problem” pulled out all the customize tools, we had one tool in here it was the wallpaper. Designers come back and say it has to be responsive. That means we can’t use one image we have to use three. So we had to look into how do we customize this thing.
Turned out it was a breeze, we were able to do this in a weekend. It’s just that the site becomes a lot more alive and as you’re promoting, as you’re curating, as you’re calling stuff out, you’re able to actually see what it is.
So now I have the journalists and the editorial people paying attention because they don’t use tools like these at most places, right?
You end up in preview hell where you’ve got the preview button to go back tweak, the headline didn’t fit, didn’t break right, go back, tweak the headline, didn’t fit, you publish it, you find out you go in the most popular box, it doesn’t fit in the most popular box, you have to edit your headline again to make sure that it fits in individual places.
It’s just that the site becomes a lot more alive and as you’re promoting, as you’re curating, as you’re calling stuff out, you’re able to actually see what it is.
What we use is these tools to allow us to customize the headline for any given spot, so when I save this promo block headline, it becomes post meta, and only on that promo block.
I can do it down to the channel, we can have these support in post meta food promo block title, entertainment promo block title, anything you can think of can be customized on this thing and it’s mostly happening through these tools.
Pull open another tool really, I’m trying to get through this as soon as possible. I know that I’m the one in front of you guys to drink and that’s not cool, trying to get through.
Allowing these are article tools and so this is going to be the heart of what this article level data is the […] to journalists and allowing…oh awesome, allowing, thank you, what did I put there?
If you’re going to create tools start, oh great, so we have a sheet right here.
It’s an ad, it’s taking over the iFrame, it’s trying to inject it into the parent, terrible coder has ruined this for us. Not going to be able, whatever, I can go through this, it’s making me do it, and again did I say, visit parade.com?
Anyway, so I’m just going to show you the tools since we, and our advertisers […]If you can see this, what we’ve got, It’s just so much cooler to see live previewing but what we’ve got is this thing over here communicating the iFrame post mentions over here and then it’s just terrible.
Everytime you talk of one of these options something happens on this side so…trust me, it works. We have things like drop caps, which is like cool for designers but make no sense if you write a lead with just one sentence in it, it makes no sense.
So the designer, no offense, wanted us to put these things on everything and i’m like no, because it just doesn’t work so we always create an escape and our tools are our escape.
There’s nothing that doesn’t flow through WordPress in our system. But you want to be able to give humans the ability to interweave human touch inside of that algorithm content.
So we apply our default behaviour to everything and that allows the tools to override. So featured image is always shown by default but you can disable it because it doesn’t make sense sometimes to have an image followed by and image followed by an image drop cap. Mark, it’s this little print thingy at the back of the article and sidebar will make it look all fancy on the side.
You can pick which channels this indicates to. I don’t like to have content management in the tools themselves but we do this because our editors are pressing us to have one spot where they can edit everything.
What you can do is set the primary channel and that carries that colour that you saw around the thing, you can choose which promo blocks to send it out to.So I’m at the article level, I want this to appear in the home page on the first slide. I go ahead and save and publish it, it will appear there. Go through the rest of the tools – pins and spikes that’s a really cool concept
I’d love you guys to adopt pins and spikes are just “I would love this to be at the top of the stream”. What we want to do as developers is provide algorithm content. Every piece of our streams flows through wp […].
There’s nothing that doesn’t flow through WordPress in our system. But you want to be able to give humans the ability to interweave human touch inside of that algorithm content.
The way we do that, the way that we chose to do that is something called pins and spikes, where pins will force something to the top of the stream, spikes will prevent it from displaying the stream.
Add units, we have apps and they need to manage things I don’t want to give them editor rights because then they can delete content so what we do is give them edit ability to look at the page.
Edit the add units on the page and make those changes in here and then we don’t have to give them full on wp admin access, we just do a little bit of fancy stuff capability and we give it to certain users.
There’s that drop cap I was so angry about which you can imagine (it looks lovely) it looks lovely says the designer of the drop cap. You know, it’s a website, there’s nothing special…
Parade is very special, we are an amazing company, we are a unique butterfly, but we are just like every other, we’ve got categories and tags there’s really nothing too special.
And you guys, I would encourage you to slay the beast, you know. I don’t mean to pick on the Washington Post who by the way is one of our best partners and carries our stuff on Sunday thank you very much. Like just kill the old CMS, it hurts, it hurts really bad, but it hurts a lot less than having to maintain two systems, having to get these guys to talk together.
And if you need something like tools, don’t let WordPress get in the way. WordPress has a tool available for you, so I’m just going to call it there. Basically there’s a whole bunch of port function that you guys can hook into your devs.
If you try to invent a new interface that will supersede it, surpass it, be better, you’re wrong, you’re wrong.
Like I have this example code, this GitHub repo you can clone like copy these ideas, that little disk is that demo so if you guys want I could experiment with some of these content, the only key is that there’s this parameter called URL loophole and you have to figure out how to translate your URL back into your WordPress post.
So if you guys were here for the last WordPress meetup, I would espouse the Quartz model of URL. I don’t know if you guys remember that talk, but they had the unique identifier in the URL, it’s awesome, we also have the author slug, the user name in the URL itself. ‘Cause then you can do translation back to the author itself with that data, it’s good for analytics, it’s good for all this.
The only trick is that you have this get parameter and you have to decide what tools you want to display based on the get parameter. So if you have really crazy URLs you’re not going to be able to easily translate that back into “oh these are tags, this is a tag page, you need to show me a my tag page, this is a member page so I need to show my member page tool”, you’ll see in the code that’s there’s like full on examples for everything.
You basically register sections, sections are like these drop down things, you register settings and like attach a control to it and then WordPress takes care of the rest and then you just have to field the data as it’s coming in and figure out where to store it. Not complex stuff, we were able to get the core promotional tools running in a weekend, no joke using this code base and I would encourage you it thoroughly.
So if there are any questions, i’d be happy to take it. I have these fancy USB sticks for people who ask questions because I’m sure you guys are burgeoning with them.
There’s a PDF with a link to our website. I’m not sure who created that marketing campaign, you should go ahead and go to our website directly.
Questions, can I answer any questions.
Q: Are you previewing those things, or were they live?
You get the key and the value, so what we did is we ended up doing a lot of like hacky-ish stuff, one of our really cool tools just like no demo of whatsoever, so you can drag and drop stuff and update stuff, that’s really cool.
The way that we’re able to do that is we smuggle data into the keys. It’s really bad practice in general, but it’s awesome with this I’ll tell you. So you can make those keys as long as you want, you know, we put the pin order, where it came from, all that data is in the key. I just read the key and it tells me what to do, I have a function that basically parses the key and figures out what to do from there. Very very simple stuff.
But it’s live previewing, so only when you hit this save and publish button do the changes that are here which are being updated in this form field but they are being reflected over here, this is the actual website.
I’ve done nothing to edit any code here until I can update and then I’m just updating post meta values, site options and user meta that ends up being displayed on the site. The huge caveat there, the huge caveat there is that as soon as your editors get on the crack that is editorial tools, we call these surf and edit tools because you surf and you edit. At the same time, they will want everything to update immediately which as a large website, is like no way, we have 12 caches, and no.
So what you end up having to do is create some sort of API that listens to update meta events and figures out where to cache, where to purge the caches. We’ve got literally thousands of places to be cached, for data to be cached. We have one call to action called purge post, give it a post id and it purges all of the locations for that.
So as a developer it’s not for free, especially if you’re on a large-traffic website, but we’re able to, I mean we run all of Parade on WordPress, it does all of our templating, it does everything.
We use maybe three web apps, we’ve got a master/slave database and then cache insets and that’s it. Very vanilla install, we’re talking like $800 a month to run as far as infrastructure costs go. Not human costs, we have our op, we have our dev, we have me and a couple of contractors and all that. But it is, like you’ll save tons and tons of dough if you’re to be doing this because you’ll live and preview it at the same time.
Q: So you can have another radio button that says disable?
Questions, can’t throw it to you, fancy USB key, I know you want it, right anyone else? Questions?
Q: What about the front end for the actual composition, where they have to do some fancy […]?
A: So this is huge and important and I want to impress this upon all of you. All of what you see here is promotional stuff so I talked about how I’m uncomfortable with the fact that there are category check boxes in there. I’m uncomfortable because WordPress admin is the single best CMS admin tool on the planet.
If you try to invent a new interface that will supersede it, surpass it, be better, you’re wrong, you’re wrong.
What we do is we don’t touch wp-admin, we provide all of these tools also on the wp-admin site because there are power users who love to be in HTML mode, in wp-admin, have their custom fields shown.
Some people will manipulate some of this data, it’s all in custom fields mostly at the post level, they’ll do it by hand but we don’t want that to be the training on day 1.
We want to be like “here’s you article, if you want to change the headline, do this” but that’s all that the headline is, it appears on the food channel, or the promo block channel or whatever.
If they’re actually editing the headline itself, they’re doing it in the WordPress backend, because I very firmly believe that the WordPress backend is the single best place to edit.
Q: Do you end up duplicating the […]?
A: yeah so that’s other huge issue and that’s why we moved to client side templating. Because what you’re going to end up doing is it’s not just duplicating code, it’s like duplicating code and doing backflips while doing it.
Because when you try to handle this scenario, where you got stuff on our member tools, like you can edit your social stuff like website title and all this, like okay, if you have a website title but you don’t have a website URL, you can display it.
So it’s not like you can just take the code that you have that already constructed this thing together and just display it again, this is one of the other problems that’s really slow.
What it’s doing is WordPress loads, it loads the page inside of it, this is a page it’s our deepest and slowest page that’s why I chose to load it. It’s got 100 items on it, even if one of these items passes through our promotions API…that was like 5 seconds.
No it’s longer than that, rendering time each one of these goes through and goes “I’m on a member page do I have any special headlines here ” and all this. So there’s also that overhead of tons more queries.
You’re talking about a lot of very small queries, unless you’re loading all the data up front and passing it around all your objects.
I wanted to show some of the crazy stuff, which is like I have a website title and that makes no sense if I don’t have a URL but now it shows up and then it’s got the website title but then I remove the website title and it figured out to use […].
So like you have to handle all these cases, it’s not as simple as being a client site template gallery where it’s just slap the data object into the template, it’s got the handlebar things it looks good you have to think about all the corner cases and like before this demo I was like if you looked at our GitHub if you guys want to laugh.
All the bugs I had to like I wanted this demo to go better than it did with the ad there and I was making sure that all the corner cases worked that if you like have show email disable, okay here’s a great one…
So you have show email disabled, but then you click show email, well your templated code doesn’t have an email, cause when the page loads, it was told not to show the page, so nowhere we have this best practice where we wouldn’t move a dom element if it isn’t needed.
We don’t leave it empty because it can have averse design effects so we don’t remove it entirely, which means if I want to show email first I have to provide this preview with the email beforehand or that featured image that I told you about that was like right here.
If that’s disabled on page load, well in this customized view, I actually have to load it anyway and then I hide it, and then when they want it, I show it.
So we’re talking about not just duplicating code, we’re talking about backflips while doing it so it is not for the, you’ve got to really know what you want when you do this thing, and what I would suggest is you come up with exactly the form fields and mock it out in photoshop, figure how you want it and figure out the behaviours associated with those and then code.
‘Cause otherwise you’re going to find yourself in all these weird corner cases that you won’t know how to deal with.
Adding to the previous resources and presentations we’ve released to Documattic, our GitHub repository, we’re happy to release what we think will be a valuable resource for the WordPress community at-large: the WordPress.com VIP Superuser Training course!
The Superuser Training course is aimed at site administrators, site owners, editors, and trainers for large or multi-author sites:
In this course, the participant will learn how to manage and use the WordPress interface from a site owner’s point of view; as someone who will be managing multiple users, their permissions, and ultimately sharing knowledge with them about how to use WordPress to publish a great site with an active community and/or audience. We like to think of this course as teaching your teachers – those who will serve as the WordPress experts in an organization.
The course also does a deep dive into the publishing process so superusers can teach their editors, authors, and contributors how to best use the WordPress interface. From creating and publishing posts to managing tags and categories, from mastering multimedia and images in articles, and bulk management of posts and pages, it’ll cover the entire publishing process from draft to done.
Previously, the Superuser Training course was only presented to VIP clients and partners who took the in-person course taught by VIP instructors during our VIP Training Days, which we’ve done in San Francisco, New York, Toronto, and London, and will continue to do. We’re open sourcing the Superuser Training slides to the community in the hope that any enterprise, WordPress agency, or in-house trainer can take advantage of them as a resource.
The more than 300 slides, including some exercises for students to do directly during the course, are available on GitHub and are released with reveal.js. This means that the HTML version can be presented from any browser, regardless of operating system, and the presentation can be updated by anyone knowing HTML. A brief note about usage to the instructor accompanies an index of the major topics covered in the full-day training course, with accompanying slide numbers so they can be quickly accessed.
An important note: these training materials are not meant to be self-paced or solo training materials. They are meant to be presented by an instructor and additional value-add will be given to the participants through thoughtful explanations and demos as needed.
We’d like the content to continue to improve and grow. If you have additional sections to add, updated screenshots to swap in, or other improvements, feel free to make alterations via pull-request. Like all content on Documattic, the content is licensed under the Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license. Check out the Superuser Training course at Documattic on GitHub.
Which WordPress resources or materials should we make available next on GitHub?
Below is his slide deck and the video from his presentation which we’ve shared previously, and we’re publishing it again now with full transcript below.
Welcome, I’m Dave Jensen, I’m the head of development for Metro UK. We’ve been a WordPress VIP client since about December 2012. I think we’re one of the larger enterprise, largest publishers in the UK that use WordPress VIP.
So we’ve been playing around with all sorts of different crazy ways of interacting with our content for the last while, when we first released, we had this whole swipe based interaction that we’d been using which was fun to build, a little bit too complicated. Over the last while, we’ve been playing around with how we could automate some of the placement of stuff on the page so, our algorithms.
We’re a pretty lean operation. Maybe some of you won’t see this as lean but for big publishers there’s 6 developers, 20 people writing content all the time. We have a 24/7 mindset though, so we have champagne aspirations on a beer budget. We’re always doing constant experimentations of how a development process works.
We’ve kind of gone through a process of building something around some kind of trending content and we’ve kind of stretched that out into a kind of newsfeed and this is what we’ll go through today.
How can we do something clever and combine those into something that we might be able to move up the page and take over?
So basically we started collecting a whole bunch of data sources just to begin with, it started as one of our guys needed a dissertation project. So we grabbed a lot of data from Facebook, shares likes, comments, grabbed some information from Twitter, from Omniture, which is our analytics and from WordPress, so we can kind of build everything together.
We took all this data and stuck it in MySQL, then we started doing some pretty basic calculations on that. I wanted to keep everything really simple, so the feedback loops that we could have from everyone involved, they could all feel part of this process and having them engaged with us, is gonna give us a lot of benefit.
Because you know, with running some crazy big data thing, and nobody understands what we’re doing, they can’t tell me when I’m doing something wrong – which is really often. So basically we took the views, we took the social interactions and we times it by a multiplier, we get a score.
We ran this every half an hour and every half an hour, we took this one from the previous one and it kind of gave us a rate of change, a number that is going on. When we released the new site, we were lucky enough to convince the editorial team to stick this at the top, second thing down on the homepage, underneath their thing.
It might sound funny, but editorial people are usually pretty protective around what they put on their homepage, this was a reasonably large step for them at the time.
We also kind of snuck in our sidebar program, so we were pretty interested to see the top bit here. It’s how the trending stuff does the bottom bit is kind of how the clicks on the top stuff work.
We were pretty interested to see that even without all the images, having it text based underneath that there was a real pretty similar level of interaction between the two modules. So we thought we’d probably stumbled across something which was interesting and seemed to jive with our users.
They also changed 24/7 without anybody from our team kind of having to touch it, which was quite nice, so on a Sunday morning, before anyone was in the office, that was still reasonably fresh.
It also, from a commercialization point of view, gave us a way of promoting native content and some kind of native display units to hopefully play around making some more money. ‘Cause it’s always nice to do that.
So from that, when we removed swipe from the site, it was far too complicated, we went down kind of a hole, we started playing with a stream of news. At the bottom of the homepage we just grabbed the latest posts and we put them in a kind of you know page, infinite scroll-type approach.
This got quite a high level, we were really surprised even that the bottom of the homepage, kind of screw it away, at the number of interactions that were getting within this.
There were a lot of people kind of scrolling, playing, clicking around, from that we thought well we kind of have this trending stuff at the top, which is doing quite interesting and we have all these people clicking on these kind of lists down here at the bottom.
How can we do something clever and combine those into something that we might be able to move up the page and take over?
So the timeline is pretty straightforward, it’s just kind of sets the thing. The interesting thing was that we took the information that we calculated and put that back into WordPress to be post meta data and then we used that information to style the front end.
So the big image over there was something that was within the trending, the second one down was just normal one and the one at the bottom was something that had been promoted by an editor.
The neat thing was there was a high-level of consistency across all the platforms. We have a responsive site and it worked quite well.
We were kind of like, even just within a normal time-based feed, we were using the data that we had to change the appearance to give the stuff that was popular a larger percentage of screen time, even in something which was time-based.
Then we started playing around with some advertising and things that looked less like advertising and more fit into the style of the site. The neat thing was there was a high-level of consistency across all the platforms, we have a responsive site, it worked quite well. We were playing around with that and we spent lots of time optimizing it and all the graphs went like that which was pretty neat, so I was enjoying myself on that.
The next kind of phase of this was you know, when we were playing around with the trending stuff, it was great but recency was a real problem that we had. Cause you know, you had to get all the data to the point and then it was what was the biggest one between them.
So we had to come up with a simple calculation to you know call that up and so we just introduced a coefficient to that, to kind of give it a shape and boost things up, which were very early on, to allow to give them a bit of airtime and get them closer to the top of the streams.
So add a coefficient to the end and just by taking that, and giving it a score with the coefficient, we built something which seems to get a, seems to be performing pretty well.
We’ve been optimizing that in quite a high-level gain and you have some graphs going up, so the scrolls and clicks. First of all we track a lot of information, so you can see down at the bottom, from going to timelines when we started to newsfeed version to infinite. Each one of those had a gradual increase.
Our statistics, some of the biggest learnings that we’ve had is because we have such variable traffic numbers.
In order to figure out actually what’ going on, we had to break everything down per daily active user which was a kind of,it was a bit one of those moments, like “why didn’t I do this before”?
Because it’s just a kind of number, we can say “hey, you like news or sports”, give them another 5,000 views and the things you read are much more likely to be closer to the top.
When we moved from a time-based feed to a news-based feed, clicks increased by 9 percent across the board, which we’re quite happy with. This has allowed us to kind of take over the homepage and it’s kind of the third thing down.
We’ve been A/B testing and content density, is one of the things we’re moving towards kind of increasing the content density, even more things on the page…more opportunities to click, more people click.
Infinite scroll had a pretty big impact as well because if you stop content then people leave and they don’t have the opportunity to click. Then we would get some good clicks on our native display and the content drivers to native content.
Some of the lessons learned…Content volume is a big problem and kind of a bit of a beast that you keep on feeding and if you don’t feed it or you give it too much of the same type of content, I get complaints, because then it kind of looks clustered within that.
Because we’re running on a scale, we’ve had some pretty fun times with MySQL and Cloudfront. Making sure we cut all of the caches at the highest level, so kind of cutting it at a category level and not playing around with it too much beneath that has allowed us to keep that going, keeping everything fast. The faster things load, the less people notice that and they click.
The common understanding has definitely helped us get feedback throughout that. so some of the things we learned from a WordPress point of view.
So we’ve been using this VIP caching thing to be able to grab the first page of information and make it kind of available and part of the page rather than having to go into it grab via ajax.
That’s the third thing that, down on the homepage. If something falls over, making it always there is good otherwise I get shouted at.
We have also with the API, we built, we actually mimicked the public API’s format,so we can kind of interchangeably use our API versus the kind of latest public API stuff, which is probably one of the quite nice hacks that we did. We were playing around with storing lots of stuff in large options for a while but that didn’t scale very well and we were using post-meta to store information.
We’ve also been playing around with CHEEZETEST to kind of give us the kind of A/B testing results but it can add quite a lot of complication if you’re trying to test too much with it.
So we took a kind of microservice architecture approach to this. We kind of have a service for data mining, a service for the newsfeed, a service for the commercial feed, which keeps all the services quite nicely separated.
We’ve been using Backbone for the templates and Cloudfront for our caching. We’ve also plugged it into an Android app, that we’ve built which has been quite fun which is just a top 10 stories on the site any one time. We are been able to pass in the channels people read and give them a boost up.
Because it’s just a kind of number, we can say hey, you like news or sports, give them another 5,000 views and the things you read are much more likely to be closer to the top.
Of the thing which would be fun, a few installs to that marketing still, the biggest fun challenge we’re having with that… and right on the money, thank you for listening.
To see the presentations from previous Big Media & Enterprise WordPress Meetups, click here. For Big Media & Enterprise WordPress Meetup groups in other cities, see the full list on VIP Events and join your local group.
Austin Smith is a managing partner at Alley Interactive, a VIP Featured Partner Agency. At our August Big Media Meetup, he gave a short “flash talk” on Elastic Search on WordPress.com in Action, which we’ve shared previously, and we’re publishing it again now with full transcript below. You can read more about the VIP Search Add-On here, and see it in action at KFF.org.
My name is Austin Smith, I’m a partner at a consulting firm called Alley Interactive, and my main project there is for the Kaiser Family Foundation (KFF), for whom I’m a developer. We went live on VIP in May – feels like so long ago. So what Elastic Search does for KFF is it replaces WordPress core search wholesale and it replaces the technology they were using before which was Google custom search clients.
Using a JSN on their new site would have been really tricky because of the nested nature of the data that we migrated for them and it also just wouldn’t surface as much information as they wanted to surface. They do facets, kind of, but it’s hard. Working with the team of VIP, we built it on Elastic Search, which has tremendous ability to filter, facet and limit.
So the search bar being bold and prominent, if you’re going to have a search bar that big, you should probably have the search engine that’s that good.
So this is the default site service screen. Another cool thing we were able to do was to quickly build other kinds of pages, things you would normally use a WordPress loop for, maybe, we were able to swap in Elastic Search so now you have a loop with facets, which is really a cool way to browse a website. Sites like Amazon.com have been doing it for years; using facets on the left panel to filter down.
We were able to swap in Elastic Search so now you have a loop with facets, which is really a cool way to browse a website.
With Elastic Search, you can run a search that has no keyword and maybe doesn’t even look like a search and we took that to an even further level by making it power the “Also of interest” spots on article pages and it took some tweaking, but we have it working pretty effectively and I’ll show you in the code that generates that, it’s actually really slick. So I’m going to break into my browser here.
So the search bar being bold and prominent, if you’re going to have a search bar that big, you should probably have the search engine that’s that good. They (KFF) write up about healthcare topics, so I’m going to search for “affordable care” and I get a ton of results and it comes back pretty quickly. So we’re doing a lot here: Date filtering – you can specify one or the other or both, Topics – that’s their word for category, they banished the word category from the entire site.
Filtering it is pretty fast. Tags – same things and there are a lot of tags, so we built an expander widget and it ranks them and then Content type, which became kind of an interesting topic for us. Whereas, generally when we had previously architectured a WordPress site, we would have decided what content types to deploy based on shared functionality and we would have used categories and tags to differentiate between them in the site hierarchy.
But in this case, we knew we could get a free facet out of this so we made different content types do the same thing, so that they could have their own facets. They think of their documents, like even if it’s a report, this kind of report is an issue brief, that kind of report is a poll finding and this kind of report is a factsheet. And then they’re all supposed to be called a report.
We could have had one content type, but instead we have four. But I think it’s easier for them to use on the backend, because they know what kind each thing is and it’s much easier on the front end, for them anyway, I don’t know how many other people know the difference between an issue brief and a factsheet, they do.
We also built one other thing for them, right into the search engine. It’s here; I didn’t even have to search for anything else. This is sort of like Google AdWords where they can sponsor their own search results and drive you down a path they think might be more useful. So, if you search for “teens”, well they don’t use the word teens, they use the word adolescents and it will suggest you search for adolescent. So that’s the site’s main search.
This is just like one giant search engine query right here, it’s all Elastic Search.
But there are a number of sections in the site and a lot of them have their own search engine. “State Health Facts” – I’ll show you what this would have looked like on the main site section. We broke out the result into everything and then “Health Facts”, which are collections of data about healthcare in the United States and around the world which resulted in graphs and maps, giant tables of data and there are about a 1,000 of them and they match just a ton of common keywords, ’cause they’re about common health topics, so they all wanted that in there. They also don’t look as nice because they don’t have the teaser. And then slides, there are like tens of thousands of slides and they just don’t want those to be in the same thing.
Again, because of the control we have here, we’re able to separate out the interface based on each tab and I don’t know if VIP knows we’re doing this, maybe I shouldn’t tell you. Every time you load a search page, it does three Elastic Search queries, the second two by AJAX, because the tabs have counts, so the global results, the global steady data that has to go back to Elastic Search and say “well, if I were to search for this, how many would I get” and it’s pretty fast, I don’t notice them coming in, it’s almost instant. So then if I were to search “health reform”, this specific search engine, it takes me back to the main site search but with a particular facet turned on, the further example of that is in this slide search engine here, this is just like one giant search engine query right here, it’s all Elastic Search.
Working with the team of VIP, we built it on Elastic Search, which has tremendous ability to filter, facet and limit.
I think this is particularly funny. The one thing on their site that looks kind of like a blog is the “Perspectives”, it’s a column which their CEO writes and it’s also powered by Elastic Search, so I think we’re maybe using the loop in a couple places but I couldn’t tell you where. If you click into a Perspective here, you’d see the “also of interest” is again dynamically generated by Elastic Search, not in real time, because nothing changes that fast, it’s all cached. The way that we do “also of interest”, which I think is the coolest bit of code you can do with Elastic Search that you can’t really do with a conventional database is we take taxonomies in priority order and then we take tags in priority order. You’ll notice this is not the standard WordPress taxonomy widget, these are re-orderable drop downs.
The tags are here, it’s an autocomplete field, but you can’t add a new tag, they don’t want you to be able to add a new tag, they actually have a taxonomy committee that approves changes. I’m not kidding. Taxonomy committees are great, they’re very very helpful. We’re basically using the term order column, which is already in the WordPress schema, to store the order of every individual taxonomy term, which allows us to send it to Elastic Search in that order and the code to do it is actually very small very elegant. It’s this here: Takes the terms with the post, it does some sort of building an array before this that I won’t show you because you’ve all seen the add something to an array operator.
But the actual query here is this “should” thing, I’m going to give you a list of things that would be cool if they matched and match as many of them and return result in the order of as many of them match, I’m sending you category with an id and tag with an id, and another tag with an id. It’s going to return a match for all 3 first and then a match for the category and the first tag second and the category in the second, third. That’s a big reason why they control their taxonomy so tightly because if they had people adding terms left and right, this would stop being useful because you’d end up with posts with a tag, and it’s the only post with that tag.
The actual search configuration, also pretty simple, this we had to do a lot of background on. VIP wrote a wrapper for the Elastic Search API, we wrote a wrapper for VIP’s wrapper and the result of it is this: which we can use to create a search engine of a given URL by saying “set default, we’re telling our plug in, we want to use this configuration for the core site search. So if you search using a WordPress search mechanism, it’s going to use this. Not in the admin area yet but we’d like to do that too, because it would be very helpful for their administrators.
And then for taxonomies it’s this easy, so we can do some really fast facet configuration, but to add another search engine, it’s that simple, so this creates a search engine that uses search, each search engine is affiliated with a post, because they could have like a teaser, like use this search engine to find XYZ, and then a set up of the facets like news posts get daily news tags and that much code is as much as it takes to create this entire search engine and we had to make it that abstract because I only had 13 minutes.
Jake Goldman and Vasken Hauri from 10up presented “Increasing Big Media Engagement with PushUp” about using push notifications with WordPress at the recent Big Media & Enterprise Meetup in San Francisco, California.
View the presentation slides below:
The San Francisco Big Media & Enterprise Meetup was held on June 17, 2014. Check out the other presentations from the event.
Want more information about WordPress services for media or enterprise sites? 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.