10up https://10up.com finely crafted websites and tools Fri, 21 Jul 2017 17:37:58 +0000 en-US hourly 1 https://wordpress.org/?v=4.8 Sponsoring WordCamp DC https://10up.com/blog/2017/sponsoring-wordcamp-dc/ https://10up.com/blog/2017/sponsoring-wordcamp-dc/#respond Fri, 14 Jul 2017 16:25:38 +0000 https://10up.com/?p=18771 As one of the Washington, DC metro area’s local 10uppers, I’m proud to share that 10up is a Silver tier sponsor of this weekend’s WordCamp DC.  With our diverse client portfolio including government, political, nonprofit, and national news organizations, an event celebrating open platforms and a better web in Washington, DC was a natural fit for our support.

If you’re attending, be sure to catch Lead Engineer Adam Silverstein speaking on Friday afternoon, in his session, Ten tips for securing your WordPress JavaScript. Pick up our postcard on the swag table, and find Adam and me roaming the event: ask us about working at 10up, hiring 10up for your project, and our newest hosted solution, ElasticPress.io.

https://10up.com/blog/2017/sponsoring-wordcamp-dc/feed/ 0
Operation LiftUp: Welcome Lift UX to 10up https://10up.com/blog/2017/10up-acquires-lift-ux/ https://10up.com/blog/2017/10up-acquires-lift-ux/#respond Tue, 11 Jul 2017 16:28:21 +0000 https://10up.com/?p=18736

We’re delighted to announce that after nearly one year of discussion and due diligence, 10up has completed an acquisition of Lift UX: a boutique, distributed, Emmy-nominated agency that specializes in making user experience design driven websites powered by WordPress. The Lift team, including its founding partners, Chris Wallace and Brad Miller, join 10up effective immediately.

Founded as a boutique digital creative shop in 2009, Lift has delivered web projects for clients like Frito-Lay, The Next Web, eBay, GoDaddy, and Disney. Lift earned acclaim when a “second screen” experience built for AMC’s Walking Dead was nominated for an Emmy Award in the interactive program category in 2012. Their work earn a second nomination in 2015 for Mad Men: The Fan Cut. Among their innovations, Lift built and sold a WordPress themes shop (UpThemes), and started a career center for distributed companies, RemoteJobs.com. They recently launched CampusInsiders.com, a project spotlighted by Automattic’s WordPress.com VIP program; the project earned Lift an invitation to become an official VIP agency partner.

As 10up’s President & Founder, I am elated to welcome this outstanding team, award recognized portfolio, and client roster to the 10up family. This acquisition accelerates our growth in Experience Design, adding executive-tier design leadership and enriching our growing portfolio of design stories. It represents a special opportunity for all parties to go further and faster as we partner with clients to make a better web.

Chris Wallace, Partner & Creative Director at Lift, will become 10up’s Vice President of Experience Design. His finely crafted design work, hands on front end build experience, and engagement with design and developer communities uniquely positions him to be 10up’s first exclusively design focused executive. He will report to Chief Executive Officer John Eckman.

Brad Miller, Partner & Executive Director at Lift, will assume the title Vice President & Associate Director of Client Strategy. Brad will be applying his winning track record building accounts and relationships, as he joins our Client Strategy team. He will report to Vice President of Client Strategy Grant Landram, partnering with accounts leadership to advance design opportunities. A fellow business owner and entrepreneur, I’m looking forward to the fresh perspective Brad will add to 10up’s executive leadership.

Also joining 10up: Christian Chung, Lift’s Director of Technology, and Anthony Garand, Front End Developer at Lift. They will come aboard in Senior Web and Front End Engineering positions, respectively, providing continuity for incoming clients and further bolstering our talented engineering team. In reviewing their work as part of due diligence, our Director of Engineering called their work, “impressive” – and I agree.

Lift’s leadership adds to 10up’s existing Experience Design team: two Visual Designers, four User Experience Designers – including User Experience Director Taylor Dewey, and two Audience & Revenue Strategists, to say nothing of our many UX and design oriented Front End Engineers, Client Strategists, and Project Managers. 10up is committed to offering its clients best-in-class expertise and execution across the full spectrum of content-centric digital experiences.

We also remain firmly committed to our engineering and strategic services, and to our many clients and partners who look for 10up to complement their own design competencies or offerings. Adding more experience design expertise to our company DNA enhances our empathy and ability to collaborate with design partners in an era of interactive, responsive design where divisions between “design” and “engineering” have eroded. (And it doesn’t hurt to know that we can pinch hit!)

It takes a special kind of chemistry and alignment for a deal like this to work. We often explore opportunities to join forces, and pass on most. In our conversations with Lift, it became apparent that their client, team, and community centricity, expertise with our preferred platforms, and palpable passion for digital creation were almost eery in their alignment with 10up. We share the same core values: service, craftsmanship, creativity, and innovation. Brad and Chris are thoughtful, ambitious, honest, and humble leaders. If working closely on this deal for months is any indication, they will be a pleasure to work with.

I can’t wait to see what we make together.

https://10up.com/blog/2017/10up-acquires-lift-ux/feed/ 0
Restricted Site Access for WordPress optimized for multisite https://10up.com/blog/2017/restricted-site-access-wordpress-multisite/ https://10up.com/blog/2017/restricted-site-access-wordpress-multisite/#respond Fri, 16 Jun 2017 16:00:52 +0000 https://10up.com/?p=18671 We’ve released a major update to Restricted Site Access, our popular WordPress plugin that intelligently limits website access. Designed to keep unwanted visitors out of staging, test, and private sites, the plugin is active on more than 20,000 websites and has a 5 star rating.

Restricted Site Access 6.0 adds full support for WordPress network (multisite) installations. Network administrators can enforce restriction rules across the entire network, or set default restriction rules that are applied as new sites are added. If you have a network of private blogs or internal sites, or need time to configure new sites in your network before taking them live, this is the update you’ve been waiting for.

There are a handful of other refinements:

  • Administrators are proactively warned about potential compatibility issues when page caching is enabled. This will alleviate a common point of confusion, since some page caching solutions will deliver content before the plugin can analyze the visitor.
  • We’ve modernized the development workflow with Grunt to facilitate internal development and open source contributions.
  • We’ve tweaked and updated some code and user-facing language throughout.

The plugin is up to date on Github and the WordPress.org repository. If you need help building, protecting, or managing a network of sites, get in touch.

https://10up.com/blog/2017/restricted-site-access-wordpress-multisite/feed/ 0
Estimates and estimation https://10up.com/blog/2017/estimates/ https://10up.com/blog/2017/estimates/#respond Thu, 08 Jun 2017 16:00:41 +0000 https://10up.com/?p=18637

“In preparing for battle I have always found that plans are useless, but planning is indispensable.”
Dwight D. Eisenhower

Why we estimate

Suppose you’re preparing for a trip and deciding which suitcase to take. You have a small suitcase that you like because it’s easy to carry and will fit into an airplane’s overhead storage bin. You also have a large suitcase, which you don’t like because you’ll have to check it in and then wait for it at baggage claim, lengthening your trip. You lay your clothes beside the small suitcase, and it appears that they will almost fit. What do you do? You might try packing them very carefully, not wasting any space, and hoping they all fit. If that approach doesn’t work, you might try stuffing them into the suitcase with brute force, sitting on the top and trying to squeeze the latches closed. If that still doesn’t work, you’re faced with a choice: leave a few clothes at home or take the larger suitcase. —Steve McConnell, Software Estimation: Demystifying the Black Art

As an engineer, nothing pleases me more than rolling up my sleeves and writing code. But before doing that, a sense of how to approach a task and the required resources (people, time, software licenses, third-party API access) need to be determined. These details support clear project expectations, which are foundational to the great client experiences we strive to create. Estimates, give all project stakeholders—internal and external—a chance to agree on a few key things before work is begun:

  • That we understand what is being asked for;
  • That we have a plan to efficiently deliver quality results;
  • That we’ve asked (and answered) all project team questions;
  • That we’ve considered all the risks, edge cases, and alternatives;
  • That we’ve considered the effects on usability, accessibility, and SEO;
  • That the available budget and desired timeline support the approach.

Quite often, larger estimates become the centerpiece at the negotiation table, kicking off a process of scope narrowing, prioritization, and concession. At 10up, we create two estimate documents for every project or large feature: a Qualitative and a Quantitative document.

The Qualitative Estimate

An estimate is an artifact. But it stands at the end of an estimation process. Here at 10up, the Qualitative Estimate document is where most of the process happens, wholly inside of Google Docs for easy collaboration; it’s rare for an estimate to be the work of a single contributor. The resulting document should be born of friendly arguments, constructive collaboration, and the benefits of Team 10up’s diverse skills and backgrounds.

The Qualitative Estimate provides two things:

  • During the estimation process, it gives the team a space to flesh out the approach.
  • Once complete, it provides internal stakeholders with proof of a workable approach.

The Qualitative Estimate requires more detail than a proposal or pitch might include. Each line item needs to be well-thought out and accompanied by specific details that might include:

  • Restating the task in the writer’s own words;
  • Identifying the client’s underlying business reason for the task;
  • Questions and answers from the Discovery process, calls, or Basecamp threads;
  • Our planned approach to the task including libraries, major components, and a high-level overview of how the code will work.

The amount of detail is relative to the task. There’s little sense in writing a three-page explanation around a clickable site logo. A more important component or feature demands considerable detail to back up the high number of hours it is anticipated to take.

The end goal of this process is to quickly narrow what Steve McConnell calls The Cone of Uncertainty. As a project progresses from raw ideas to a finished product, each step moves the team closer to an understanding of how much time the project will take. It’s preferable to work with a client early in a project to ask for more hours than when close to launch. By then, the client has already scheduled training, bought advertising, and/or spent the rest of the budget elsewhere. More details and up-front planning contribute to estimate certainty and help everyone manage expectations.

The Cone of Uncertainty (McConnell)

The Quantitative Estimate

The Quantitative Estimate is a more traditional spreadsheet. It’s broken out into major groups of functionality, with room to add line items describing the individual tasks within those bigger units. Each line item challenges the estimator to consider the efforts for:

  • Front-end engineering;
  • Back-end engineering (including Systems);
  • Design;
  • QA and code review.

Subtotals and totals are computed automatically, giving immediate feedback on the impact a task has on the whole project. This instant feedback loop breeds experimentation, estimating different approaches to see how the alternatives affect the grand total. This is important information to share with the project team so that different options can be presented to the client.

A rule of thumb for QA/Code Reviews at 10up is to start with 20% of the sum of the other disciplines, rounded up to the next quarter-hour. So, a task needing four hours of front-end engineering, 12 hours of back-end engineering, and one hour of design would be calculated by 17.0 * .2 = 3.4 hours, rounded up to 3.5 hours. But that’s just a starting point; the estimator can raise or lower that number to reflect the complexity of the task.

Distribution of relative effort overruns (van Genuchten)

Tasks often end up taking more time than expected. There is no shortage of platitudes about this: Take your estimate, double it, then double it again; Multiply every number by 1.5; Multiply by pi and convert to the next time magnitude (one day = 3.14 weeks!). But to cite specifics, a study (Jenkins, Naumannm, and Whetherbe, referenced by Michiel van Genuchten) noted that, of 72 projects surveyed, “the average effort overrun was 36%.”

The Programmer Time Translation Table by Anders Abel tries to map programmers’ initial estimates to a more realistic amount of time, taking into account common issues that occur when working on a task. Note how important it is to account for time spent outside a text editor or IDE.

The last line of that chart is important: a huge task, one expected to take more than a couple days’ work, is too big to estimate with a lot of certainty. In order to narrow that Cone of Uncertainty, the task needs to be broken down into smaller line items.

Steve McConnell advocates a very scientific approach to estimating. 10up embraces a more agile and nimble workflow than this more rigorous method can accommodate, but the first half of his book Software Estimation: Demystifying the Black Art is full of wisdom on the whys and hows of estimates. It includes a list of things engineers tend to forget to account for when estimating:

Software-Development Activities Commonly Missing from Software Estimates (McConnell)

By developing estimates through qualitative and quantitative processes, we’re able to provide more confident project pricing for our clients, minimize surprise budget overruns, and avoid the temptation to over-promise.

Further Resources

https://10up.com/blog/2017/estimates/feed/ 0
Get to know New Relic Reporting for WordPress https://10up.com/blog/2017/new-relic-wordpress/ https://10up.com/blog/2017/new-relic-wordpress/#respond Wed, 31 May 2017 16:04:24 +0000 https://10up.com/?p=18614 New Relic is a SaaS product that offers application performance monitoring (APM), which provides developers with real-time data for use in proactive diagnostics as well as debugging. This data—including basic information about WordPress hooks, plugins, and themes—can be queried and visualized using the New Relic Insights dashboard.

Seeing an opportunity to maximize the utility of APM and Insights, we created New Relic Reporting for WordPress, which supplements out-of-the-box data collection with additional WordPress-specific information.

New Custom Attributes

New Relic APM’s “transaction traces” are the foundation for its detailed insight into application performance. These traces record each step (transaction) along the path to satisfy an application request, such as a website page request. Each recorded transaction includes a number of attributes—metadata about the transaction—such as its time and date. Our plugin adds and extends attributes for the transaction data logged in New Relic, to aid debugging and performance analytics.

While our technical documentation is more detailed, at the high level, our plugin adds the following transaction attributes:

  • User data. Whether a logged in WordPress user was executing the transaction, and if so, the ID of the user.
  • Post ID. If a single post was being requested, the ID of that post.
  • Template. If a theme template was being requested, the file path for the template.
  • Theme. The name of the theme in use at the time of the transaction.
  • Request type. Whether the transaction was made as part of a standard web request (most common), an AJAX request, or a CLI request. New request types can be added using a filter (wp_nr_request_type).
  • Runtime of async tasks. Tracks the runtime of Gearman async tasks, building on our WP-Gears work.

Our plugin also improves reporting for some existing, key attributes:

  • Transaction name. Adds more recognizable names for common WordPress application requests, e.g. website “Front Page” or admin “Dashboard”, in lieu of generic transaction names like “index.php”.
  • Error messages. Log errors/notices for the current transaction with a new PHP function.

More granular debugging

The additional custom attributes we attach to transaction traces empowers engineers to better diagnose unusual site behavior. As an example, let’s look at how our plugin can assist in debugging a common scenario: complaints by an editor that the site is loading slowly.

When someone reports slow page loads, we can query New Relic Insights for slow transactions using New Relic’s ‘duration’ attribute. Because our plugin adds a custom attribute identifying the WordPress user to each transaction, the engineer can investigate whether the performance is isolated to logged in users, and even determine whether it’s localized to specific users. We can include the WordPress user as a column in the transaction results, or refine the query to be limited to users who are (or are not) logged in, even restricting results to a specific user ID (perhaps the user who reported the problem).

In the below screenshot, we queried for some important attributes, including duration, for all transactions by WordPress user ID 53, ordered reverse chronological by the timestamp (date and time of transaction) attribute.

Pinpoint trends before they become problems

While duration is a standard New Relic attribute, query results are, by default, limited to attributes that make it difficult to correlate slow times with specific site usage patterns in WordPress. By adding details like the category name to the transaction name attribute, New Relic can report on load times for category pages, enabling developers to more quickly recognize patterns associated with atypical performance before they become major issues.

Queries like this one—the average duration for categories—can be embedded in the New Relic Insights dashboard, keeping developers up-to-date with real-time data at a glance. By adding warning and critical performance thresholds, support engineers can actively track site performance to proactively remedy trends before they affect site visitor experiences.

Learn more about, or download, New Relic Reporting for WordPress from GitHub or WordPress.org.

https://10up.com/blog/2017/new-relic-wordpress/feed/ 0
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/ 9
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