Bring your Ideas and Projects to the October 24th Hosting Community Meeting

The #hosting-community team is looking for new opportunities to enhance the WordPress experience for WordPress users! Hosts and others in the WordPress community are welcome to join the team at the October 24th meeting Wednesday, October 24th, 2018 at 1700 UTC. The team would also like to ask regular contributors and team members to outline 2-3 ideas for new initiatives for the team to work on.

The #hosting-community wants to hear all ideas, big or small, especially for projects related to or for improving WordPress hosting. Some of the team’s previous projects include:

New ideas and initiatives do not have to be limited to these kinds of projects. Contributors and newcomers alike are welcome to suggest any new initiatives or efforts that could improve the hosting experience for WordPress users in general.

Send Your Delegates to the July 11th Hosting Community Meeting

The Hosting Community (#hosting-community) wants to help prepare hosting support teams for the launch of Gutenberg by producing documentation and resources hosting companies can use to prepare their support teams to best assist their users with Gutenberg before Gutenberg launches.

Anyone interested in preparing for the launch of Try Gutenberg and the launch of Gutenberg in general is welcome to attend the meeting of the Hosting Community team at Wednesday, July 11th, 2018 at 1700 UTC. This will be an opportunity for everyone to meet, establish key milestones, and figure out how to collaborate. Feel free to join #hosting-community in the Slack before then if you have any questions, etc.

At a high level, our goals are to help hosting support teams:

  1. Understand what Gutenberg is and how it works.
  2. Be confident in diagnosing support requests / bug reports / plugin conflicts.
  3. Know how to act on the result of their diagnosis (let it be opening a new Gutenberg issue, reporting the conflict to the plugin author, etc.).

Gutenberg is the redesigned WordPress editor launching later this year with WordPress 5.0. It marks a relatively significant change to WordPress’s editor interface, and the Hosting Community team wants to support a smooth transition to Gutenberg for hosting companies’ customers.

WordPress users will also soon receive an invitation in their WordPress admin dashboard to Try Gutenberg. Users who opt in to Try Gutenberg will have the Gutenberg plugin installed to their WordPress websites. We expect that WordPress users will go to their hosting providers’ support teams first for help with Gutenberg.

We are developing documentation that outlines the best practices for assisting customers with Gutenberg and where support teams can find additional help. The documentation currently lives in a shared Google Document. It contains information about Gutenberg, including:

  1. What is Gutenberg
  2. How to try Gutenberg before it launches
  3. Common support questions
  4. Common bugs
  5. How to file a bug template
  6. Suggested steps for troubleshooting Gutenberg-related issues
  7. Guidance on looking for plugin conflicts with Gutenberg

We want to work directly with hosting companies to cultivate Gutenberg Subject Matter Experts who can take the lead in coordinating with their hosting team and the Hosting Community team to prepare for Gutenberg. Hosting companies interested in collaborating on plans for preparing their teams for Gutenberg should send a representative to the Wednesday, July 11th, 2018 at 1700 UTC. We will discuss the launch of Try Gutenberg and Gutenberg in more detail at that meeting.

We aim to partner with hosting companies to capture user feedback about Gutenberg in order to help drive improvements in Gutenberg. Hosting companies are well-positioned to best assists WordPress users with the move to Gutenberg and to communicate to the Gutenberg team the problems their users are experiencing with Gutenberg. Hosting support teams can contribute to Gutenberg directly through submitting bug reports and providing feedback to the Gutenberg team and the Hosting Community team on how Gutenberg can be made better for WordPress users.

We look forward to seeing you on July 11th!

Hosting Meeting Notes: May 9nd, 2018

Here’s the summary of our meeting #hosting-community on Wednesday, May 9nd, 2018 at 1700 UTC (Slack archive).

@mikeschroder @andrewtaylor-1 @jadonn @dhsean @pdclark @danielbachhuber

Hosting Best Practices Documentation



Miss this week’s meeting and want to discuss the initiatives above? Spend some time in the comments and share your thoughts!

Next Meeting

The next meeting will be in #hosting-community on Wednesday, May 16th, 2018, 1700 UTC. Hope to see you then!

Hosting Meeting Notes: April 25th, 2018

Here’s the summary of our meeting #hosting-community on Wednesday, April 25th, 2018 at 1700 UTC (Slack archive).

@mikeschroder @danielbachhuber @andrewtaylor-1 @jadonn @aaroncampbell @josh2k5 @antpb @brettface @desrosj

Team Organization

  • contributor and team badges were given out.
    • Contributor badges are for concrete contributions, such as making a contribution to one of the team’s active projects.
    • Team badges are for team members who show a combination of contributions, participation, and helping with planning and execution of team projects.
    • If you did not receive a badge, and you feel like you should have, please message @mikeschroder on Slack.
  • The Contributor Drive documentation was passed back to community team for inclusion in future contributor drives.
    • Thank you everyone who added to this documentation!

Hosting Best Practices Documentation


  • @danielbachhuber had three updates
    • Plugin compatibility test results:
      • Plugin compatibility database, announced March 1st, 2018, has had 70 testers who have tested 861 out of 5000 total plugins.
      • Of 861 tested plugins:
        • 219 (25.44%) are compatible.
        • 518 (60.16%) are likely compatible.
        • 25 (2.9%) are likely not compatible.
        • 39 (4.53%) are not compatible.
        • 60 (6.97%) are in “testing” (i.e. someone started a test and did not complete the test)
    • @danielbachhuber would like to focus on acquiring more data, with Try Gutenberg being a big opportunity.
    • @danielbachhuber proposed having the plugin compatibility database be moved into, which would be a large amount of work, but worthwhile if it brings in a lot of useful data.
  • Try Gutenberg is currently scheduled to launch in WordPress 4.9.6, which is scheduled for release on May 15th scheduled to launch in WordPress 4.9.7 as of May 2nd, 2018 (thanks to @aaronrutley for pointing out this was changed).
    • @danielbachhuber asked if team members’ support teams were ready to address Gutenberg support requests
      • @jadonn and @josh2k5 responded they would have to check with their support team for readiness.
      • @jadonn and @josh2k5 asked for official documentation that could be provided to support teams to help prepare support teams
        • @danielbachhuber recommended drawing up an outline of information that their supports teams would like like to have


Miss this week’s meeting and want to discuss the initiatives above? Spend some time in the comments and share your thoughts!

Next Meeting

The next meeting will be in #hosting-community on Wednesday, May 2nd, 2018, 1700 UTC. Hope to see you then!

Hosting Meeting Notes: March 28, 2018

Here’s a summary of our meeting in #hosting-community on Wednesday, March 28, 2018, 1:00 PM CST

(Slack archive).

Contribution Documentation

  • @mikeschroder mentioned that Angela Jin is helping document contributor groups and drives, including info on how to contribute and projects available for contribution. An open call was made for Hosting Community contributors to help write up and proof documentation. @antpb and @ataylorme expressed interest in helping proof and write up info. If anyone else would like to help on this front, please ping @mikeschroder on slack.
  • Two initiatives need attention — @danielbachhuber’s Gutenberg testing, and Hosting Best Practice docs, which @ataylorme has been leading. They’re both in need of significant help.
  • In the last meeting folks mentioned that it might be a good idea to pick a day or days to work together on docs, because pre-scheduled time might help. It was determined that Friday 4/6 at 1700 UTC we will meet to discuss documentation. Please come join us! When the event starts, instructions will be posted in the channel for optionally joining a hangout while working.

Hosting Community Discussion

  • @mikeschroder expressed a need to bring in more representatives for the Hosting Community group. There is open call for nominations (self or otherwise) to help the group with things like organizing meetings, notes, or getting things together for camps and contributor days.

Gutenberg Testing

  • @jadonn mentioned the need for Gutenberg Testing outreach and @miker has joined the group to help in those efforts (Welcome!). A resource was shared by @pdclark on Gutenberg testing:
  • The signup process in the testing site was mentioned to be a bit of a hassle/blocker in contributions to testing. Some discussion was had around sharing authentication via users. @danielbachhuber mentioned that considering things like automation the level of effort to link the two may be overkill. 
  • @danielbachhuber mentioned that we don't take ownership of updating the plugins ourselves, but instead focus on making the compatibility data available/accurate, and then assist the plugin author with guidance on how to make their plugin Gutenberg compatible. Our main focus is just getting data around what is/isn't compatible. 
  • On the topic of automation @danielbachuber warned "The challenge with the existing implementation is that some plugins require configuration before they expose editor UI. Simply taking screenshots of a fresh WordPress install with the plugin activated in some automated manner isn't sufficient. However, if a hosting company were open to it, we could grab customer databases with the plugins already activated, spin them up in some isolated environment, and do our screenshot analysis."
  • @danielbachuber also mentioned "We could potentially generate a ton of plugin incompatibility data by screening the support forums"
  • @danielbachuber also shared a comment that outlines some great steps for testing compatibility:


Miss this week’s meeting and want to know more about anything above? Spend some time in the comments and share your thoughts! OR….Come join us!

Have some questions on how you can get involved? Join #hosting-community and feel free to ask at any time.

Next Meeting

The next meeting will be in #hosting-community on Wednesday, April 4, 2018, 1:00 PM CST. Hope to see you then!


Announcing Beta Period for Distributed Host Testing

Just over a year ago, Aaron Jorbin suggested a simple idea:

If WordPress really wants to do quality automated testing, we need to rely on the people hosting sites to test vs their stack. To do that, Core needs to provide an infrastructure that both encourages and enables easy automated testing.

Today, we’re happy to announce the beginning of a beta period for exactly this: a framework for any hosting company to run the WordPress PHPUnit test suite on their infrastructure and report the results back to

At a high level, this framework is two parts:

  1. The phpunit-test-runner, which prepares the environment, runs the test suite, and reports the results back to
  2. The phpunit-test-reporter, which receives the results, stores them in the database, and displays them in an accessible manner.

We’d love to see dozens of hosting companies participate in this program. Check out Getting Started for an overview on how you can set it up. Then, stop by the #hosting-community channel in Slack with any questions you might have.

Thanks to DreamHost and WP Engine for volunteering the engineering effort to make this project possible.

Call for Best Practices Documentation

One of the topics that has been largely discussed during #hosting-community meetings is coming up with a list of best practices for hosting companies to follow. Currently, we know that virtually every hosting company has a different server OS, default php.ini values, NGINX/Apache configs, etc. We’re looking to get some of those things aggregated to provide suggested defaults and best practices.

Here is some of the data we are looking for:

  • Any plugins or mu-plugins installed by default
  • Any modifications made to wp-config.php by default
  • PHP versions offered
  • Modules available in each PHP version
  • Default php.ini files
  • Default caching configs (Varnish, Memcache, Redis, etc)
  • Default web server configs (NGINX, Apache, etc)

Of course, we’re aware that some things (i.e. security configurations) may be sensitive. We don’t want those things.

This information will be compared, discussed, and picked apart to determine best practices to follow. Our goal is not to debate which hosting company is better. This should be an objective analysis by involved individuals from many hosting companies and potentially individuals not affiliated with any hosting company.

If you would like to contribute to the formation of WordPress hosting best practices and have information to offer, please contact @voldemortensen on Slack.


WordPress Community Summit 2017

As mentioned in weekly meetings, the WordPress Community Summit is coming up, and our team has some decisions to make!

The summit organizers have asked for the following by the end of next week:

  1. A list of topics/issues that are relevant for the progress of the team and the WordPress open source project as a whole, prioritizing topics or tasks which are sensitive enough to require in-person discussion.
  2. A list of representatives to attend the Community Summit (this will be based primarily on the topics or tasks).
  3. One or two contributors who are willing to help with the organization of the event.

If you have any suggestions for topics or tasks that would benefit from in-person discussion, or are interested in helping out with organizing the event, please comment below or ping myself or @boogah directly so we can put a list together.

There is also a post with a survey to apply to attend and submit questions if you’re more comfortable with that route.



Building a Machine-Readable List of WordPress Events

In #hosting-community, it was brought up that several hosts are interested in collecting data of local WordCamps and WordPress Meetups to promote attendance to customers. With many events happening around the world, the first task is to build a reliable source of data. The most important WordPress-related events are collected in two places: WordCamp Central and Meetup. Both sites have APIs to retrieve these lists.

WordCamp Central Events

The WordCamp Central API does not require an API key, so no setup is required. To pull the last 100 modified WordCamp events use the following request:

[user@localhost]$ curl -g '[posts_per_page]=100'

The response is formatted as JSON. If filter[posts_per_page] isn’t added, you’ll get only the default amount of results (8, at the time of writing this). To get a more readable output, you can use jq and less on Linux/MacOS (you may need to install jq using your package manager):

[user@localhost]$ curl -g '[posts_per_page]=100' | jq '.' | less

The top level element is a list. Each element in the list is an object with key/value pairs. The post_meta element is a list that contains objects for metadata including location, Twitter hashtag, start and end date (in epoch format), and other useful details of approved WordCamps. The location does not follow a strict format and is usually “city, country” or “city, state” if in the United States, but some WordCamps follow a slightly different format, and the Community Team has suggested an effort to standardize format and normalize the previous values. A good next step is to connect with the Community team to see if the Hosting team can help out here, since that will make it so that the country retrieved will always be accurate.

Meetup Events

The other source of events is on Meetup Their API requires a developer key, which can be created for free. To get a JSON formatted object of all scheduled WordPress Meetups, use:

[user@localhost]$ curl -g "$KEY&sign=true"

Be sure to change $KEY in the URL to your API key or it will not work. Again, you can use jq and less to parse the JSON:

[user@localhost]$ curl -g "$KEY&sign=true" | jq '.' | less

The member_id value 72560962 is the id for the WordPress Foundation Meetup account, and by specifying this, the API returns all WordPress official events, rather than the events for a single Meetup group.

The JSON that the Meetup API returns has a different schema than the WordCamp Central API JSON responses. For Meetup, the top level entity is an object, and the main key to look at is results. This contains a list of objects, and each object represents a WordPress Meetup. Each Meetup has a lot of metadata associated with it. Some important ones to know about are time, which is in epoch format * 1000, venue, which is an object with information about the venue, name, which is the name of the WordPress Meetup, and event_url, which is the website for the event. The venue‘s localized_country_name and city keys can be used together to replicate the WordCamp API’s location object.

Bringing it All Together

To get the full list of WordCamps and Meetups, a script is needed to pull from both sources and combine them into one list. An example script can be found on GitHub to see how a host might retrieve the data and combine the two sources. There is also an Official WordPress Events plugin, which creates this page, that can be used.


Dive Into Distributed Unit Tests

Recently, I have spent some time looking into using pre-built tools for distributed unit tests. What I found was that all of them were built to fetch the test results. What we need, for this project, is to have the results sent to us. At this point it seems like a custom WordPress solution will be the best route.

There was some discussion in #hosting-community about how the tests would be triggered. Some hosts have scripts that run nightly, so slipping tests into that process would make implementation easy. However, using a nightly solution would make it more difficult to determine exactly which commit caused an issue.

If we move forward with running tests on a per-commit basis, do hosts watch for commits and then report the results? Or do we ping hosts? It seems like pinging hosts would be ideal, but it might not be an option for all hosts. It would be really nice to get some feedback here, so your thoughts would be appreciated.

The first step is to start on the method used to report results. This will be a WordPress based application, with a REST API. Hosts will submit the results with the commit SHA to be aggregated. I’m going to dig into this over the next several weeks and will share a GitHub link when I have something up and running.