America’s Test Kitchen is best known for their television series on PBS and magazine Cook’s Illustrated. America’s Test Kitchen is a real 2,500 square foot test kitchen located just outside of Boston with more than three dozen full-time cooks and product testers. Their recipes, equipment reviews, ingredient taste test results, and kitchen tips are made available across multiple different mediums like their TV shows, magazines, cookbooks, and websites.
To strengthen the many different brands they house, they wanted one cohesive, accessible site where they could connect with their fans, upload video tips, and publish original content. This resulted in The Feed. Social Media Manager, Jill Fisher, and Managing Editor, Christine Liu, walk us through how The Feed fostered a strong community of relationships with fans and bloggers that eventually lead to its own DIY book.
You can browse their slides below:
For Big Media & Enterprise WordPress Meetup groups in other cities, see the full list on VIP Events and join your local group.
Want more information about WordPress services for media or enterprise sites? Get in touch.
Shortcodes can be a useful way of defining complex HTML elements within the WordPress editing window. But as Matthew Haines-Young, senior engineer at WordPress.com VIP Featured Partner agency Human Made, told the London Big Media & Enterprise Meetup, ‘everybody hates them.’
His solution is Shortcake, a plugin developed as part of Human Made’s work with the US media company Fusion. It gives developers the ability to add user-friendly modules to the Add Media window, making the shortcodes themselves (almost) invisible.
You can browse Matthew’s slides below:
Shortcake lives on Github for the moment, but it has proposed as a candidate for future inclusion in the WordPress core software.
For Big Media & Enterprise WordPress Meetup groups in other cities, see the full list on VIP Events and join your local group.
Want more information about WordPress services for media or enterprise sites? Get in touch.
It’s one of the largest WordPress multi-site installs we know of in the UK, but few have ever heard of it. Scotland’s Glow was the world’s first national intranet for education, and features WordPress as one of several components offered to pupils and teachers. It supports more than 140,000 websites, blogs and e-portfolios, with hundreds more being added each week.
Glow product owner John Johnston joined us at March 2015’s London Big Media & Enterprise Meetup to explain how WordPress was supporting the Scottish curriculum’s aim to produce successful learners, confident individuals, responsible citizens and effective contributors. You may need to channel your inner Scotsman to make sense of his title, ‘WordPress For Weans’!
Helpful Technology is a relatively small London consultancy specialising in digital engagement. One area of focus for Steph Gray’s team is corporate intranet development; and they have had great success deploying a WordPress-based intranet solution inside several UK central government departments.
Steph and his colleague Luke Oatham joined us at March 2015’s London Big Media & Enterprise Meetup to talk about the features which had made the project a success. And if you like what you see, their code is available as open source for anyone to use and improve.
Duncan Stuart is Head of Products at dxw, a London agency specialising in projects for the public sector. He has a particular interest in security; and at our London Big Media & Enterprise Meetup in March 2015, in a presentation entitled ‘Snakes In A Plugin’, he demonstrated the most common vulnerability they find when conducting security reviews of WordPress plugins.
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.
Mo Jangda from Automattic gave a presentation and lead a discussion on Code Review at a recent WordPress Big Media Meetup in New York City now with full transcript.
So to get a sense of what the room looks like, how many people here are developers? So the majority of people, probably 70-80 per cent. How many people are editorial? A few people, that’s good. How many people are management? You guys in the suits.
If you’re a developer, how many people have a code review process built into their teams right now? Not everyone, which is disappointing. So that’s what I’m here to talk about.
The goal should be to have at least one other person than the person who wrote the code look it over and to review it for things like quality standards, security concerns and performance and so on, things like that.
You can’t code review if you’re doing it live. So, ultimately the goal with code review is basically to improve the quality of your code.
So if you’re editorial, right, the idea is that you’re not going to push something out any sort of published articles without going through the copy editing phase, unless you care about money, in which case you don’t care.
You want to make sure the stuff you’re putting out is good quality, and that’s where code review is – that’s why it’s sort of nice to do.
The goal should be to have at least one other person than the person who wrote the code look it over and to review it for things like quality standards, security concerns and performance and so on, things like that.
So it doesn’t necessarily have to be a junior to senior. It’s a learning opportunity for both, different skill sets as well.
And the secondary goal is you sort of becomes that you’re learning from each other as developers. It doesn’t necessarily have to be a junior developer passing off their work to a senior developer and them telling them basically everything they did wrong.
It can actually go the other way where a senior developer passes off their work to a junior developer and says here’s the code I’ve written,can you look it over and see what I’m doing?
It gives the junior developer an opportunity to look at how the code is being written by the senior developer and learn from them, right?
So it doesn’t necessarily have to be a junior to senior. It’s a learning opportunity for both, different skill sets as well.
The other thing to sort of keep in mind is that code reviews shouldn’t be something else that you tack on. It’s part of the development process, right?
So it’s not something that you should consider a tedious thing that should be going on, it’s something that you should have built into your processes as part of your deployment, as part of your coding, so something you do on a regular basis.
There’s different ways you can do code review obviously. You can have a gatekeeper-type approach. Where you have one person who’s sort of like master of the code review, so every bit of code that gets written goes through that person.
So that person can be a senior person, can be a rotator role so all code goes to that person, they review it, send feedback and iterate on the code that way.
One flow, or one specific approach to code review is not going to work for everyone. So you’ve got to find something that works for you.
You can do some things like peer review, where you have teams of developers put together, so one person is buddied up with another so any time a person needs feedback, anytime a person is finished working on a patch or working on a new feature they can pass it off to their fellow developer and say, hey can you give me feedback.
You can have a committee-based approach, where you have multiple people giving feedback on patches. If you’re using something like Git or GitHub you can use pull requests. GitHub makes it really easy to comment on code, and pull requests and commenting and so on.
You can also do pair programming, which I personally dislike, but it works for a lot of people if you’re into extreme programming or agile processes and stuff like that. You can have people working on code at the same time and the cool feature of that is that you’re essentially doing code review live because you’re questioning each other as you’re writing code.
One person types up something, the other person sort of questions: Okay, why did you write that?
There’s different points in time where you can actually use code review so you can actually start doing code review before writing a single piece of code and you’re essentially talking out the concepts with each other.
You know, we planned out the specs and functionality, we’ve thought about what my classes are going to look like, what my functions are going to look like.
So it’s a good opportunity to actually talk with you, what approach you’re taking to code review, to talk with the person with whom you’re doing the code review to see you know, does this make sense?
Obviously you do things like pre-commit reviews, look at patches, so before you even commit the code send the patch over, send over and review it that way.
It’s a great way for your team to actually write better code and build a more cohesive unit.
We also do post-commits, so once the changes are done, committed, you can review the pull request or the actual committed code.
You can also do post-deploy, so if you don’t actually have time, to do a full code review before pushing it out, you can still go back and do code review on stuff that’s pushed live and make changes over time.
The most important thing obviously is you got to find a flow that sort of works for your team.
So one flow, or one specific approach to code review is not going to work for everyone. So you’ve got to find something that works for you.
Doesn’t necessarily have to be anything very specific. It can be sort of totally casual, like a conversation between two developers.
So it’s pretty important to find something that works for you. You also don’t need fancy tools, you don’t necessarily need to go out and get your own license of Phabricator, which is a code review tool that Facebook has built up.
To be honest, it can just be as simple as two developers passing around a patch to each other. Looking it over.
So it doesn’t have to be complex, but if you want it to be complex, you can.
But you can keep it simple, find something that works for you and so on. When it actually comes to doing the code review, there’s a few things to keep in mind.
Throw your ego out the door.
The most important thing, and this goes for both the person reviewing the code and the person receiving feedback is throw your ego out the door.
There’s no such thing as ego and emotion during code review. That’s the most important thing to keep in mind.
The reviewer is not smarter or dumber than the person whose code they’re reviewing. In the same sense, the person whose code is being reviewed they’re at the same level. So ego is not involved, it’s not supposed to be personal. It’s supposed to basically be about questioning the code, right?
Not questioning the person. So one thing that I usually try to keep in mind while I’m personally reviewing code is that I usually recommend to people is that when you’re phrasing your feedback never include the word “you” .
So it’s not YOUR code, it’s THE code. Right? So that takes away the personal aspect of it and it makes the reviewer feel less attacked.
Because getting your code reviewed can be a very scary thing, but it shouldn’t be.
You should get to a point, where you should actually be proud to have your code reviewed and proud of the code you’re presenting to your teammate, senior developer or boss and so on.
To show that this is the amazing thing that I’ve done, and you know what, I expect there to be flaws.
Chances are, there might not be, but you know, if there are issues with it, it’s something you know, the mistakes that you find, is something that I can learn from.
The other thing to sort of keep in mind, is that you as a reviewer want to be critical about things, right? So question the decision that the developer is making.
Why did they name that variable that way? Is that a valid variable name, right? Why is this function name so long? Can this be abstracted? Right? So design decisions like that can be a good way to root out potential problems in the code.
But obviously, you don’t want to get too caught up in the minor details, so getting caught up on spaces over tabs which we’ve had problems in the past with before, in VIP, where some developers would reject code commits for using space instead of tabs, you know that’s a minor implementation don’t get too caught up on that.
Point it out, but it’s not going to be a blocker. But it’s important that coding standards and best practices are still followed, so it’s important that your team is following those that in your reviews, you’re actually flagging those and so on.
The other thing to keep in mind is as a reviewer, don’t worry about catching everything. ‘Cause you’re not. I don’t mean to brag, but I think I’ve reviewed about 20,000 commits on VIP. Of the many commits that I’ve reviewed on VIP there’s been stuff that I’ve missed and that’s naturally going to happen.
Because manual code review is not going to be perfect. Automated code review is not going to be perfect.
There’s no such thing as ego and emotion during code review. That’s the most important thing to keep in mind.
Things will get missed, things will go live that will break your site. But that’s, an opportunity to learn from so the next time you review your code you’re going to be extra conscious about it and try to find that mistake that you made and try and prevent it from happening again.
So that’s the other thing as a reviewee, you should sort of keep in mind. When a mistake is found, and pointed out to you, you should try and avoid making that mistake again. It’s a very important thing. You should be using it as a learning opportunity, right?
If you are making the same mistake over and over again. Chances are there’s something wrong. Either with your processes or with how you’re developing. That’s something you should work to change.
Never focus on the negatives.
As a reviewer, if you find the same problems over and over again, that’s when you need to question what’s going on with this developer? Why are they not sort of picking up the problems that I’m seeing? Another thing I sort of do, and I mentioned this earlier with not making it personal, try to keep in mind try to stick to the positives, right?
Never focus on the negatives. What’s a good example? It’s important to start a phrase with: How can we do this better? Instead of this is dumb, this is stupid.
So again, avoiding the personal attacks, trying avoid getting too emotional about things and staying focused on this code could be optimized more instead of this code will break your site, things like that.
I think that just about covers it. That’s sort of one of the biggest things I wanted to go over. But also, I guess it’s ultimately important to find something that works for you.
Code review is, it’s something that’s near and dear to my heart because I’ve been doing it for the past three years as a reviewer, it’s the best way to learn best practices and learn new code.
I’ve actually learned more new WordPress functions by looking at other people’s code than I have through just following news and following WordPress codex and things like that.
So it’s a great opportunity for reviewers to sort of look at how other people code or how other people think when they’re approaching problems.
And as a reviewee, it’s a humbling experience and a great opportunity to learn. And ultimately, it’s a great way for your team to actually write better code and build a more cohesive unit to ultimately do cool stuff.
Thank you.
Q: It’s easy to think that if you don’t review everything, then you should just give up because if you’re not reviewing everything, then the problem is going to be in the spot you didn’t review.
So, I think that maybe some of the thought process behind not everyone here doing code reviews I think it’s something that I think everyone wants to do so I was wondering if you could provide tips is there any sort of lightweight code review process? Is there anything that doesn’t require every commit to be reviewed by somebody else?
A: So that’s where I would look at post-deploy commits or post-deploy reviews so reviews don’t necessarily have to block things from going out but you still take the opportunity to go back at some point.
Let’s say you have a work week, you set aside two hours in the week Friday or something where you as a team, get together and review each other’s code, and look at various commits and stuff.
So to give you an example, on 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.
The easy way to speed it up is to also just I mean ignore JavaScript and CSS, because if you have a lot you can just ignore CSS. If your quality assurance team passes it and it looks fine, also JavaScript if you really don’t have time.
A: I mean for CSS especially, as a code reviewer when I look at the VIP code, I basically ignore CSS, because from my perspective, I care more about the security and performance.
So you’re right, there are things you can sort of ignore, if you are a designer and like reviewing CSS, then go for it. But also, like you said, standards are really important, and processes are really important.
Especially, as you grow as a team, again doesn’t necessarily have to be super formal and super strict, but it helps to have some sort of definition in place so you can follow, your team knows what to do.
So they’re actually trying to have their code reviewed, instead of pushing it live.
Steph: Out of curiosity, how many people here have had Mo review their code?
Participant: He’s the best!
How many of you have had code rejected by me?
Participant: How many people want to beat Mo up after this meetup?
Participant:I’m in
Participant: Actually out code was reverted 2 min before the meetup.
What I usually tell people at like VIP workshops and stuff is that your ultimate goal should be to make me so happy that I would never want to revert that code ever.
We actually revert code once a day. The interesting thing is that if you have some sort of code review process, we actually notice when VIP’s adopt some sort of code review process, internally, so they have someone on their team review their code before it comes to us.
The quality, there’s a significant increase. The number of issues we have to flag, the number of reverts that actually end up happening to that code goes significantly down.
It’s a testament that code review can actually work and keep us happy and keep your code getting deployed much faster.
If you’re not on VIP, still a great opportunity to make sure your team is working together, make sure your team is writing good code. ‘Cause the last thing you want is to push out a security hole and all of a sudden has your homepage hacked the Syrian army or whatever.
Code For The People is a six-person WordPress development agency based in the UK, known for their great service and the enterprise tools they’ve created. Automattic has acquired them and will be winding down the consulting part of their business as they join our WordPress.com VIP team to continue building the best tools and services for enterprises using WordPress.
We’ve worked very closely with Simon Dickson, Simon Wheatley, and the rest of the Code For The People team in recent years as partners collaborating on projects for our mutual customers, and before that through their many contributions to the WordPress open-source project and community.
They bring a deep understanding of WordPress, unique experience providing solutions for government agencies, and a particular specialty developing multilingual tools, like Babble, for enterprises. We also really appreciate their commitment to contributing back to WordPress, and are excited to have John Blackbourn continue leading the development of WordPress 4.1 as part of Automattic.
And while Automattic has always been a distributed company, and WordPress.com VIP a global team, we’re excited to expand coverage for our European customers as well.
Congrats to the team, and welcome to the Automattic family!
Why Choose WordPress: A Government Perspective – Now With Full Transcript
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.
Often times, I’m working with cities and states that have great design teams, they know CSS and Javascript, but they don’t have a good background php or in the code base. So using WordPress.com has been a real asset to them.
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 plugins, 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 plugins, 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 plugins 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, plugins, 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 plugins 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 plugins, 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—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.
Andrew Nacin is one of the lead developers of WordPress. At the August 2013 Big Media & Enterprise Meetup, he gave a talk on how WordPress evolves while maintaining backwards compatibility — which we shared previously and we’re publishing it again now with the full transcript below.
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:
add_filter(
‘wp_cache_themes_persistently’,
‘_return_true’ );
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&A
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.
WordPress VIP Lobby 
You must be logged in to post a comment.