10up https://10up.com finely crafted websites and tools Mon, 29 May 2017 00:58:32 +0000 en-US hourly 1 https://wordpress.org/?v=4.7.5 10up at SyntaxCon https://10up.com/blog/2017/syntaxcon/ https://10up.com/blog/2017/syntaxcon/#respond Fri, 12 May 2017 12:49:15 +0000 https://10up.com/?p=18589 I’m excited to be presenting “An Introduction to Test-Driven JavaScript Development” at Syntax Code and Craft Conference on May 18. SyntaxCon, held in Charleston, SC, is a multi-day, full stack code conference for developers and engineers. My talk introduces the concept of test-driven development (TDD) when working with JavaScript, highlights its benefits, clarifies some common misconceptions, and provides examples of how to implement TDD into your everyday workflow.

https://10up.com/blog/2017/syntaxcon/feed/ 0
Introducing WP Docker https://10up.com/blog/2017/wp-docker/ https://10up.com/blog/2017/wp-docker/#comments Thu, 27 Apr 2017 17:11:59 +0000 https://10up.com/?p=18568 Back in 2013, 10up introduced Varying Vagrant Vagrants (VVV), a project led by then 10upper Jeremy Felt. One of the first popular WordPress development environments based on Vagrant, VVV has since been moved out of 10up’s GitHub and into its own, where it continues to thrive as a community-led project.

Now, Docker and container-based server architectures have emerged as powerful tools for creating and managing development environments. Last year, we partnered with Joyent to release a scalable, production-ready Docker environment for WordPress. Today, we’re proud to release WP Docker: an open source Docker configuration optimized for local WordPress development.

Why WP Docker?

While still viable, VVV, Vagrant, and Virtual Box/Hyper-V take up extreme disk space and are slow to provision, start up, and SSH into. Because of this, engineers tend to use one “mega” VVV install for all of their development websites. This workflow poses a number of problems: system service version and configuration “normalization” across all projects (i.e. PHP 7 on everything when some projects run PHP 5.6 in production), and legacy clutter (i.e. old websites and system packages undeleted).

WP Docker addresses these shortcomings and provides greater flexibility in environment creation and distribution. Since Docker starts up extremely quickly, the environment is conducive to a “one site per environment” rule. Docker Compose makes it easy to swap system package versions and configurations. An engineer can easily use PHP 5.6 for one environment and PHP 7 for another. Docker Compose also simplifies adding new dependencies (e.g. MongoDB). As an added bonus, WP Docker includes Elasticsearch, so ElasticPress works out-of-the-box.

Our lightweight WP Docker project includes:

  • PHP7
  • MariaDB
  • Elasticsearch
  • Gearman
  • Memcached

That said, we don’t believe in “one size fits all” engineering solutions, and that applies to development environments. 10up still uses VVV for quite a few projects. We think that WP Docker offers another powerful option for developing WordPress applications locally, and we are excited to share it with the open source community.

https://10up.com/blog/2017/wp-docker/feed/ 7
How to become a WordPress Core contributor with one line of code https://10up.com/blog/2017/how-to-wordpress-contributor/ https://10up.com/blog/2017/how-to-wordpress-contributor/#comments Thu, 27 Apr 2017 12:47:00 +0000 https://10up.com/?p=18559

[To better illustrate our core value of community service, we are sharing an internal post from Senior Front End Engineer Derrick Koo, who recently made his first code contribution to the WordPress project. We hope his story encourages more people who are “on the fence” about contributing to take the plunge and start giving back to the WordPress community. —Jake Goldman, President & Founder]

Contributing code to WordPress Core can be intimidating for a first-timer. With thousands of tickets out there, it can be hard to know where to begin. With development out in the open, it takes a lot of courage to submit a first WordPress patch.

For the benefit of new and aspiring contributors, I’m sharing my experience making my first code contribution to WordPress. Starting with little knowledge of the Core contribution process, I embarked on a journey that resulted in one line of CSS, and my first Core props.

Find a ticket

One day, WordPress lead developer (and fellow 10upper) Helen Hou-Sandí asked me to investigate a relatively straightforward browser bug in the Twenty Seventeen theme.

Tickets are just bug reports (or potential enhancements) in the WordPress Trac system. The Core team actively marks some tickets “Good First Bugs;” these are good places to start as a first-time contributor.

Vagrant up

Once I had my bug, it was time to fix it. Contributors submit code in the form of patches (a.k.a. diffs) to the development repository that are then tested by other WordPress contributors, and ultimately accepted or rejected.

To test patches locally, you need a development environment and a local copy of the development repository. At 10up, we often use Varying Vagrant Vagrants (VVV), which includes a local environment linked to WordPress’s development repositories. VVV is a very useful tool for developing WordPress sites, and not just for contributing to Core. You’ll need to install several pieces of free software and then run a vagrant up command from your Terminal or command line. The official WordPress Core Contributor Handbook has a handy guide on this topic.

Dive into the Handbook…but don’t get lost

While you’re spinning up your local dev environment, explore the Handbook. It offers guides for every aspect of Core contributing, from setting up your environment to working with patches and Trac to coding best practices.

You’ll likely notice that some Handbook pages are more complete than others. This is because like WordPress itself, the Handbook is built and maintained by community members. You can contribute to the community by helping to improve the Handbook, too.

Before trying to reproduce the bug I was investigating, I spent a lot of time reading through the Handbook. All of it is useful, but these are the pages I found most helpful as a first-time contributor:

  • How to Become a WordPress Developer – While not actually in the Handbook, this is a high-level checklist of where to sign up for a Trac account, what you need to contribute code, and how to both test and create patches.
  • Communication – Contains links to all official channels of communication used by the Core team and community. Definitely join the Slack channel if you want to get more involved in the community.
  • Contribute with Code – A slightly deeper look into the cycle of creating a patch, as well as definitions and links to the tools contributors use.
  • Installing VVV – This is a good guide to setting up VVV for any developer.
  • Installing a Version Control System – A short guide on getting SVN setup on your machine. This covers both Mac/Linux and Windows environments. Note: Contributors can create, test, and submit patches using either SVN or Git, but because SVN is the “canonical” Core repository, VVV is already connected to SVN, and most official documentation assumes you’re using SVN, I chose to learn how to work with patches in this way. Your experience may vary slightly if you choose to use Git.
  • Opening a Ticket – This page is about creating new tickets, but much of it also applies to participating in existing tickets.
  • Best Practices – The biggest rabbit hole in the Handbook, this section is one of its most important and comprehensive parts. Rather than reviewing every page of Best Practices—which can quickly become overwhelming—start with the coding standards pages for whatever languages you need for your particular ticket. The ticket I was investigating was a CSS browser bug, so I started with the CSS Coding Standards page. Before you submit a patch, make sure the code conforms to the standards for the language(s) you’re using or the patch will likely be rejected.

Find the bug

As with any bugfix, the first step is reproducing it. Once VVV is up and running, visiting http://src.wordpress-develop.dev/ in a browser will bring up a clean local installation of the development version of WordPress running the default theme. You can use this installation to create and test whatever content you need for your ticket. At the time of this article, the default WP admin username and password are admin and password, respectively.

By default, the source files are located in the VVV directory, inside /www/wordpress-develop. Conveniently, this directory is already hooked up to the WordPress Core development SVN repository. First, make sure your repository is up-to-date by navigating to the directory in Terminal and running this command:

svn revert . -R && svn up

This discards any local changes you might have and updates all files to their latest remote versions. (Note: if you have made any changes to local files, you will lose them at this point, so make sure you’re not discarding anything you want to keep.) You can repeat this command anytime you need to update your local environment to match the latest version in the remote repository.

Next, install local dev dependencies. While not essential, this is extremely helpful if you intend to continue contributing in the future. The development repository includes several helpful Grunt tasks, so make sure you have node.js and NPM installed on your machine. From inside the same /www/wordpress-develop VVV directory, run npm install to install everything.

The ticket I was investigating was a CSS bug affecting responsive grid elements in Internet Explorer 11. The ticket author included screenshots of the behavior and detailed steps to reproduce it. When creating or responding to any ticket, including as much information as possible (including screenshots) is crucial to getting a positive response. Even if you don’t yet have a solution in the form of a patch, any relevant information or updates are always appreciated and help the Core team act more quickly when a patch does arrive.

Once I had a local dev site up and running in a BrowserStack instance of IE11, I created a new post in my local environment and added a gallery as described in the ticket, and was able to see the bug in action.

Squash the bug

Now comes the fun part: figuring out what’s causing the bug. There’s no guide to follow here, as every ticket differs. In my case, the bug was caused by a known IE11 behavior in which max-width does not work for children of inline-block elements that have no explicit width. This cause was even suggested by the ticket author in his initial bug description, which turned out to be correct.

The simplest fix, as I described in the ticket, was to add a width: 100%; declaration to the images themselves so that they never exceeded the width of the space they had in the grid. I traced the relevant CSS to my local dev environment’s /www/wordpress-develop/src/wp-content/themes/twentyseventeen/style.css file and made the change there.

Test the fix

Before submitting a fix as a patch, testing it thoroughly is crucial to ensure it:

  • doesn’t cause any unintended behavior, and
  • fixes the bug in as many different scenarios as you can test.

My solution worked in IE11. I also visited the post in as many other browsers as I could, both in BrowserStack and those installed on my own computer, including iOS and Android simulators. It worked in all browsers I tested, and didn’t cause any unintended changes in browsers which hadn’t exhibited the bug, either.

Create a patch

With a working solution created, it was time to make a patch for it. A patch is a text file containing an SVN diff used to apply code changes to the WordPress repository. Patches should be named for the tickets they address. To create a patch, navigate to the root directory of your development repository, then run

svn diff > [ticket-number].diff

SVN will create a patch file with that name. Open it in a text editor to verify that it contains the correct code changes. You should also compare it against the coding standards for the particular languages before submitting.

Submit the patch

Remember the helpful Grunt tasks I mentioned before? VVV includes a module for automatically submitting patches to a Trac ticket. If you’ve already run npm install in your root repository directory, you can now run

grunt upload_patch:[ticket-number]

Grunt will automatically find the Trac ticket and upload any patch files found in your local directory.

Beware of gotchas

Only after I had uploaded my patch did I realize that I had failed to fully test my solution. I had tested it using a responsive grid with three columns, like the ticket author’s screenshots had shown. But I didn’t take into account that the Twenty Seventeen theme supports galleries with 1-9 columns. My fix worked at three columns—when the columns were narrow enough that images were at least as wide as the column itself—but what if an image were smaller than the column? Applying width: 100% to the image itself would mean that it would always stretch to fit the full width of the column.

Ideally, my solution would allow the images to display at their natural width when smaller than the column. I eventually determined that applying the width: 100%; to the parent a elements, as opposed to the img elements themselves, resulted in the behavior I wanted. With the parent a set to width: 100% and the images set to max-width: 100%, images smaller than the column would display at their natural width while larger images would not exceed the column width. I tested this new fix in all browsers, with the gallery set at multiple column sizes, to make sure that I covered all use cases for the feature.

Await responses

I created and uploaded my second patch as 38872.2.diff, so that the filename wouldn’t conflict with my first patch, and uploaded screenshots illustrating both the solution and the use case I hadn’t thought to test at first. I then set the ticket status to has-patch, as described in the Handbook. This lets other community members know that the ticket contains a patch that anyone can test. I didn’t have to wait long for another contributor to pop in and respond that they had downloaded my patch, tested it, and found it did fix the problem described in the ticket.

Receive props

Only members of the WordPress Core Team (or fully vetted contributing developers) can apply patches to the Core repositories. Every patch that makes it to the WordPress source code must be reviewed and committed by one of these community members. In my case, Helen reviewed the solution and approved it, resolving the ticket and applying my patch to the Core development repository. She gave props to both the original ticket author and me, a satisfying conclusion to my first (but hopefully not last) contribution to WordPress Core.

My ticket ultimately had a straightforward solution, so the resolution was quick. But many tickets are much more complex, and require back-and-forth over a much longer period. Some tickets remain open for years before a solution is approved. Don’t feel discouraged if a patch you submit isn’t immediately approved. Core contributors all learn from each other, and the dialogue that comes out of code reviews is one of the best ways to improve as a developer.

The first and hardest step for many Core contributors is working up the courage to participate. I hope my story makes it a little easier for other aspiring contributors to begin.

https://10up.com/blog/2017/how-to-wordpress-contributor/feed/ 1
10up ranked among fully remote companies https://10up.com/blog/2017/time-fully-remote-hiring/ https://10up.com/blog/2017/time-fully-remote-hiring/#respond Wed, 15 Mar 2017 21:04:27 +0000 https://10up.com/?p=18507 We were featured in Time’s Money “10 fully remote companies that are hiring” roundup. Joining team 10up means that—with reliable internet access and a drive to serve clients on their timeline—you can work from anywhere in the world. Interested in joining our team? Take a look at our Careers section and find your next professional opportunity.

https://10up.com/blog/2017/time-fully-remote-hiring/feed/ 0
Keeping your WordPress options table in check https://10up.com/blog/2017/wp-options-table/ https://10up.com/blog/2017/wp-options-table/#comments Fri, 10 Mar 2017 17:01:16 +0000 https://10up.com/?p=18477 When troubleshooting a slow WordPress site, an often overlooked culprit is the wp_options database table. This table houses a variety of crucial site data, including:

  • permalinks
  • site settings
  • scheduled posts
  • widget data

In fact, nearly every WordPress page—from the front end to the admin screens—executes the query SELECT option_name, option_value FROM wp_options WHERE autoload = 'yes'. If this query does not run efficiently, the results can be devastating to a site’s speed.

Why wp_options doesn’t scale

Not all WordPress database tables suffer as they grow. The wp_posts table, for instance, can be many times larger than the wp_options table without seriously impacting site performance thanks to an indexing strategy designed to accommodate very large datasets.

A database index is similar to a textbook index, which lists every mention of a term in its pages. With clearly marked page numbers, any term can be quickly found. Without this index, every page in the book would need to be flipped through to locate a specific term, every time.

If a database query doesn’t have an index on the requested field (as in our earlier example query on the options table, which looks for records where the “autoload” field is set to“yes”), MySQL will have to search every single record in the database table.

The wp_options table is not intended to hold thousands of records, so, in theory, it does not need an index for the “autoload” query. As retooling a part of WordPress core like this is a huge endeavor—as this wp_options trac ticket shows—engineers are discouraged from adding records to the wp_options table unnecessarily.

Cause & effect

And yet, this table can become bloated quite quickly and keeping its size under control is not a small effort. 10up Systems Engineers often see wp_options ballooning due to:

  • Plugins installed on large WordPress sites that were designed for smaller sites. These plugins often store data in wp_options rather than tables designed for larger data sets (such as the postmeta table for post-specific data) or external platforms better suited to “big data” like analytics;
  • A bug in otherwise well-designed plugins, like this issue found with Yoast’s SEO plugin;
  • Theme developers adding data tracking code—E.g. ad tracking or social media counters—in the wp_options table.

In many cases, issues like these slowly bloat the table and degrade performance over time, offering no clear warning signs. Without constant monitoring of the wp_options table size, a simple theme or plugin update can be the start of a big problem. 10up uses a basic bash script running in system cron to email alerts if the wp_options table exceeds a few thousand rows. 

To quantify the impact of a bloated wp_options table, 10up ran the “autoload” query against a large website whose wp_options table contained 38,654 records. Before cleaning up the table, the test query took 52.66ms. After cleaning up abandoned transients records, Yoast’s SEO sitemap cache records, and legacy ad tracking data, the wp_options table was slimmed down to 528 records, and the query took only 1.4ms. That’s 37 times faster!

Add an index

When cleaning up the table isn’t enough, adding an index to the “autoload” field can be a huge help. Many managed WordPress hosting providers do this automatically to protect against performance degradation.

The 10up Systems team performed some test scenarios on a wp_options table with a typical number of autoloaded records to show how adding an autoload index to wp_options queries can boost performance. Again, the results were dramatic.

Without an index, the time to query for the autoload options increases linearly with table size, with no limit. With an index, the query hits a slowdown ceiling around 4ms and remains there.

Object caching

Many high traffic WordPress instances can mask poor performing autoload queries by using the WordPress Object Cache. With an object caching system in place (E.g. memcached, redis, APCu), WordPress will cache wp_options values with autoload set to “yes” as an array called “alloptions”. WordPress will no longer fetch options from the database on each page load, eliminating this potentially slow query. However, an excessively large wp_options table can greatly degrade the effectiveness of some caching strategies.

There are a number of WordPress caching plugins, but 10up recommends Memcached. Memcached requires some configuration to work optimally. By default, Memcached places a 1MB limit on individual values stored in the cache. A large wp_options table can create an alloptions array that easily exceeds the 1MB limit, preventing it from being cached. Every page would suffer from the large query itself, plus an added delay due to the failed Memcached call.

Our recommendations

The simplest way to avoid the pitfalls of a large wp_options table is to keep it small—we recommend keeping this database table under 500 rows. This requires monitoring to ensure that newly installed or updated plugins don’t diverge from best practices and start storing data within wp_options.

We also set an index on the wp_options “autoload” field, protecting clients from poor performance if the table unexpectedly grows. 

Memcached’s default 1MB item size is adjusted to accommodate the alloptions array as necessary. Avoid increasing the item size more than absolutely necessary, as the increased threshold requires more memory to store the same amount of data, making Memcached less efficient in it’s memory usage.

While wp_options might seem like a minor area for optimization, sites scaling to tens of millions of pageviews can see a huge difference by tuning a table queried on every single page load. While the WordPress community actively improves wp_options indexing, large WordPress site administrators need to safeguard against this common performance issue. 

https://10up.com/blog/2017/wp-options-table/feed/ 1
Join 10up at A Day of REST Boston https://10up.com/blog/2017/day-of-rest-boston/ https://10up.com/blog/2017/day-of-rest-boston/#respond Thu, 02 Mar 2017 18:51:11 +0000 https://10up.com/?p=18462 On March 9th, join me at A Day of REST Boston: a conference devoted to exploring the WordPress REST API in-depth. My lightning talk, 5-10 Use Cases in 10 Minutes, describes various ways organizations are using the REST API in their digital projects.

In Backbone & the REST API: A Love Story, Lead Web Engineer Adam Silverstein explains how Backbone is used in WordPress core and walks through the core REST API JavaScript client, started and led by 10up. As a follow-up to this session, on March 10th, Adam is leading a half day workshop on developing with Backbone and the REST API.

https://10up.com/blog/2017/day-of-rest-boston/feed/ 0
Six years of 10up https://10up.com/blog/2017/six-year-anniversary/ https://10up.com/blog/2017/six-year-anniversary/#respond Mon, 13 Feb 2017 20:09:45 +0000 https://10up.com/?p=18442
If we spent our first five years pioneering and staking our claim in the world, in our sixth year we cultivated the organization and culture we pioneered. We rallied around trends and shifts in our industry and redoubled our investment into telling our story.

The initiative to better express our story culminated in a refresh of our company website, prominently featuring a new mission statement, proudly summarized by a promise to deliver “finely crafted websites and tools that make the web better.” We reinvigorated our project case studies, moving to a layout that better celebrates the challenges we’ve conquered with our clients. And we completely overhauled our Careers section, taking deliberate strides to better represent our culture of diversity and inclusion.

All this while growing our revenue by 12%.

Here are some of the ways we adapted to a shifting landscape and embodied our new mission since our last company anniversary:

Here’s to another year of innovation, creativity, and making the web better.

https://10up.com/blog/2017/six-year-anniversary/feed/ 0
Meet ElasticPress.io: a hosted search and query engine for ElasticPress https://10up.com/blog/2017/elasticpress-hosted-search/ https://10up.com/blog/2017/elasticpress-hosted-search/#respond Fri, 10 Feb 2017 16:59:36 +0000 https://10up.com/?p=18432

We’re proud to announce ElasticPress.io: a hosted service that integrates with ElasticPress, our popular plugin, to provide a fast and flexible search and query engine for WordPress.

We built ElasticPress to overcome higher-end performance and functional limits posed by the more traditional, structured (SQL) database underpinning WordPress. Storing content in a modern (noSQL) query engine like Elasticsearch empowers us to produce superior keyword search and related content results, and supercharge the performance of complex queries like a filter on multiple product properties or a location. Smarter and faster content makes for a better web and, not accidentally, is important to search engines and visitor retention / conversion.

While our plugin made it simple for WordPress-savvy engineers to talk to Elasticsearch, the need to manage Elasticsearch hosting added friction and complexity, at odds with the simple user experience 10up strives for. As we prototyped exciting use cases involving private content, we realized that end-to-end security added even more complexity.

ElasticPress.io solves all of that—making it dead-simple to start using enterprise-caliber search and query technology with WordPress. It enables innovative features like accelerated admin performance that require end-to-end control and security.

Some of our site hosting partners offer similar solutions; Automattic even offers Elasticsearch with their enterprise plans. In many cases, those solutions serve their customers very well, are recommended and supported by us, and can even integrate with ElasticPress. There are also ElasticPress adopters who prefer hosting and managing their own Elasticsearch infrastructure: we’ll continue to support self-hosting as a popular use case for our plugin, and our plugin will always be free and open.

Starting at $299/month, with 99.9% uptime across all our plans, ElasticPress.io fills a need for customers whose WordPress site hosting doesn’t already include a solution like ours, and who want an enterprise-caliber, end-to-end, no fuss solution with superior customer service.

While we’re just beginning to open this product to the public, we have been privately using ElasticPress.io with select clients for more than a year. Thanks to our strict privacy policy, we can’t tell you about all of the big brands relying on ElasticPress.io, but we can tell you that customers like JDRF—one of the largest nonprofits in the world—and publications like Texas Monthly rely on ElasticPress.io.

ElasticPress.io is tested, mature, and ready to welcome new customers. Want to learn more? Check out the new website, and reach out today!

https://10up.com/blog/2017/elasticpress-hosted-search/feed/ 0
Introducing the WordPress Component Library https://10up.com/blog/2017/wordpress-component-library/ https://10up.com/blog/2017/wordpress-component-library/#comments Wed, 08 Feb 2017 22:04:18 +0000 https://10up.com/?p=18414

We’re proud to introduce the WordPress Component Library: a collection of front-end components constructed with WordPress and accessibility at the forefront.

Many of the HTML and CSS components we build for our clients are structurally similar, particularly for prolific features like menus, search forms, posts, and blogrolls. A common starting point offers efficiencies to our clients while simultaneously raising the bar on polish and compliance with standards like accessibility. In evaluating existing libraries, we found that the industry was missing a good, open source project built with WordPress’s often opinionated markup (e.g. menus) and basic layout structure in mind.

Since accessibility is a top priority for many of our clients, and critical to our mission to make the web a better place, each component in the library is WCAG 2.0 accessible. We think that this project will help engineers and clients who value accessibility, but may struggle to budget for it, achieve a higher standard with little-to-no added cost.

We are actively adding to and improving the components. Hosted on GitHub, we welcome feedback, questions, and pull requests.

https://10up.com/blog/2017/wordpress-component-library/feed/ 8
10up client FiveThirtyEight publishes top story of 2016 https://10up.com/blog/2017/fivethirtyeight-top-story-2016/ https://10up.com/blog/2017/fivethirtyeight-top-story-2016/#respond Fri, 27 Jan 2017 18:25:14 +0000 https://10up.com/?p=18387 10up client FiveThirtyEight’s political coverage earned the stats-minded publisher four spots in ChartBeat’s top 25 most engaging stories of 2016, including #1 for their 2016 election forecast. This interactive feature provided predictions in the US presidential race, as well as 34 Senate contests nationwide, leading up to the November elections.

We love seeing clients like FiveThirtyEight topping the charts alongside long-established publishers like BBC, the New York Times, and NPR.

https://10up.com/blog/2017/fivethirtyeight-top-story-2016/feed/ 0