<div style="text-align:center"></div><div>
<p><a href="https://make.wordpress.org/core/2023/04/25/performance-chat-agenda-25-april-2023/">Meeting agenda here</a> and the full chat log is available <a href="https://wordpress.slack.com/archives/C02KGN5K076/p1682434772025969">beginning here on Slack</a>.</p>
<h2 class="wp-block-heading">Announcements</h2>
<ul>
<li>Updated the cadence of bug scrubs to be every 2 weeks – next one scheduled for <a href="https://www.timeanddate.com/worldclock/fixedtime.html?iso=20230426T1500"><abbr class="date" title="2023-04-26T15:00:00+00:00">April 26, 2023 at 15:00 UTC</abbr></a>.</li>
<li><a href="https://profiles.wordpress.org/flixos90/" class="mention"><span class="mentions-prefix">@</span>flixos90</a> Also briefly sharing that I just published a performance retrospective post on WP 6.2 that I had been working on over the past few weeks: <a rel="noreferrer noopener" data-hasqtip="32" href="https://make.wordpress.org/core/2023/04/25/the-benefits-of-prioritizing-and-measuring-performance-in-wordpress-6-2/" target="_blank">https://make.wordpress.org/core/2023/04/25/the-benefits-of-prioritizing-and-measuring-performance-in-wordpress-6-2/</a> It highlights some of the key aspects which changed in 6.2 in how we dealt with performance and also summarizes high level numbers. It can be seen as somewhat complementing <a rel="noreferrer noopener" href="https://make.wordpress.org/core/2023/04/05/wordpress-6-2-performance-improvements-for-all-themes/" target="_blank">https://make.wordpress.org/core/2023/04/05/wordpress-6-2-performance-improvements-for-all-themes/</a>, at a higher level however without looking as much at specific improvements.</li>
<li>Discussion regarding the <strong>decoupling of the SQLite plugin </strong>from the performance lab work. In reference to <a rel="noreferrer noopener" href="https://wordpress.slack.com/archives/C02KGN5K076/p1680019422571839" target="_blank">this conversation</a> that came up in a previous performance chat. Would love to have an open discussion about peoples preferences here and whether we do decouple this?
<ul>
<li><a href="https://profiles.wordpress.org/olliejones/" class="mention"><span class="mentions-prefix">@</span>olliejones</a> I favor that approach. It will usually be deployed independently of the stuff in PL.</li>
<li><a href="https://profiles.wordpress.org/10upsimon/" class="mention"><span class="mentions-prefix">@</span>10upsimon</a> I tend to lean more toward an agreement with <a href="https://profiles.wordpress.org/rmccue/" class="mention"><span class="mentions-prefix">@</span>rmccue</a> in that SQLite is not necessarily performance improvements focused (or at least that is not the primary goal), and probably belongs outside of the realm of the performance lab work.</li>
<li><a href="https://profiles.wordpress.org/spacedmonkey/" class="mention"><span class="mentions-prefix">@</span>spacedmonkey</a> To be clear, I think that performance team should continue to support SQlite getting into core, to much sure it done in a performant way. But SQlite is not a performance benefit on the face of it, so it is confusing why we part of performance lab plugin.</li>
<li><a href="https://profiles.wordpress.org/rmccue/" class="mention"><span class="mentions-prefix">@</span>rmccue</a> Yeah, that was basically my thought; I think it’s beneficial all-round to separate it out (but with performance still consulting as <a href="https://profiles.wordpress.org/spacedmonkey/" class="mention"><span class="mentions-prefix">@</span>spacedmonkey</a> says)</li>
<li><a href="https://profiles.wordpress.org/olliejones/" class="mention"><span class="mentions-prefix">@</span>olliejones</a> yes, having SQLite headed for core is good. I believe the issue is about monorepo and multifunction plugins on the one hand and a separate repo and plugin on the other.</li>
<li><a href="https://profiles.wordpress.org/aristath/" class="mention"><span class="mentions-prefix">@</span>aristath</a> I agree with what was mentioned above 100%. SQLite <em>can</em> be related to performance, but is not in itself a “performance” module/plugin. It should be developed in collaboration with the performance team since it can have a big impact, but I’d vote to decouple it from the performance-lab plugin</li>
<li><a href="https://profiles.wordpress.org/olliejones/" class="mention"><span class="mentions-prefix">@</span>olliejones</a> Maybe in a parallel universe or another year, there can be a separate database team. But for now the perf. team has the talent.</li>
<li><a href="https://profiles.wordpress.org/spacedmonkey/" class="mention"><span class="mentions-prefix">@</span>spacedmonkey</a> If you want to setup a meeting for a database team, that could work. Many component meetings have less than 5 people.</li>
<li><a href="https://profiles.wordpress.org/flixos90/" class="mention"><span class="mentions-prefix">@</span>flixos90</a> To clarify, this conversation is slightly different and mostly unrelated to the “unbundling Performance Lab plugin” effort. While we are publishing other PL modules as standalone plugins, those standalone plugins will still be directly associated with the performance team, developed in the monorepo, referenced from the PL main plugin etc. Removing / decoupling SQLite from PL would be different: We would still support getting the plugin towards WP core of course, but it wouldn’t be in any way connected to PL anymore. Maybe that was clear, but just in case.</li>
<li>Next steps clarification:
<ul>
<li><a href="https://profiles.wordpress.org/aristath/" class="mention"><span class="mentions-prefix">@</span>aristath</a> I think the only thing to do here would be to remove the module from PL, and add a notice so in case the user previously had the module activated, they’ll be prompted to install the standalone plugin</li>
<li><a href="https://profiles.wordpress.org/joemcgill/" class="mention"><span class="mentions-prefix">@</span>joemcgill</a> I assume we’ll remove the module from the performance lab plugin in the same release where we remove other modules. How we handle the transition so as to not break any active sites, is not clear to me at the moment.</li>
<li><a href="https://profiles.wordpress.org/olliejones/" class="mention"><span class="mentions-prefix">@</span>olliejones</a> Do we have any usage telemetry to help guide that decision?</li>
<li><a href="https://profiles.wordpress.org/flixos90/" class="mention"><span class="mentions-prefix">@</span>flixos90</a> Potentially. As mentioned, I think this conversation is decoupled from the general PL unbundling effort, so we could do it at the same time, but also sooner. I would love to find a way to make the transition smooth though. For sites that already have the SQLite module active, we should probably recommend activating the SQLite plugin before deactivating the feature.</li>
<li><a href="https://profiles.wordpress.org/aristath/" class="mention"><span class="mentions-prefix">@</span>aristath</a> That’s a good idea…</li>
<li><a href="https://profiles.wordpress.org/flixos90/" class="mention"><span class="mentions-prefix">@</span>flixos90</a> Has anyone tried yet to activate the SQLite standalone plugin on a site where the PL SQLite module is already active? We need to make sure it doesn’t throw fatal errors
<ul>
<li><a href="https://profiles.wordpress.org/aristath/" class="mention"><span class="mentions-prefix">@</span>aristath</a> Adding it on my TODO list for tomorrow, though from what I recall I tried it last month and I there were no issues. I’ll need to test that again just to be sure, it’s been a long time</li>
</ul>
</li>
<li><a href="https://profiles.wordpress.org/10upsimon/" class="mention"><span class="mentions-prefix">@</span>10upsimon</a> I feel strongly about not intentionally breaking users sites, however few are using it. Perhaps we need to defer the removal to 2 versions from now, and raise a notice or similar in the admin making it very clear that from version <em>n</em> it will no longer be supported as a core PL module.
<ul>
<li><a href="https://profiles.wordpress.org/flixos90/" class="mention"><span class="mentions-prefix">@</span>flixos90</a> agreed <a href="https://profiles.wordpress.org/10upsimon/" class="mention"><span class="mentions-prefix">@</span>10upsimon</a> adding though that for a smooth transition the plugin should be activated before deactivating the PL module, so we have to make sure that that is actually possible</li>
</ul>
</li>
<li><a href="https://profiles.wordpress.org/joemcgill/" class="mention"><span class="mentions-prefix">@</span>joemcgill</a> A similar transition plan will be good for all of the modules, to be honest, even though SQLite is the most critical due to potential breakage.</li>
<li><a href="https://profiles.wordpress.org/flixos90/" class="mention"><span class="mentions-prefix">@</span>flixos90</a> <a href="https://profiles.wordpress.org/joemcgill/" class="mention"><span class="mentions-prefix">@</span>joemcgill</a> I think for the other modules we’ll handle that in a central effort as part of unbundling, but with SQLite it will now be bit different, since that plugin will not be referenced directly from PL in the future. But I agree it’s most critical there to have a smooth transition since switching back to a MySQL / MariaDB database accidentally will break any site that actually relies on SQLite right now</li>
</ul>
</li>
</ul>
</li>
</ul>
<h2 class="wp-block-heading" id="focus-group-updates">Priority Projects</h2>
<h3 class="wp-block-heading" id="images">Server Response Time</h3>
<p><a href="https://make.wordpress.org/performance/roadmap-2023/#category-server-response-time">Link to roadmap projects</a></p>
<p>Contributors: <a href="https://profiles.wordpress.org/joemcgill/" class="mention"><span class="mentions-prefix">@</span>joemcgill</a> <a href="https://profiles.wordpress.org/spacedmonkey/" class="mention"><span class="mentions-prefix">@</span>spacedmonkey</a> <a href="https://profiles.wordpress.org/aristath/" class="mention"><span class="mentions-prefix">@</span>aristath</a></p>
<ul>
<li><a href="https://profiles.wordpress.org/spacedmonkey/" class="mention"><span class="mentions-prefix">@</span>spacedmonkey</a> I landed lazy loading term meta<br /><a rel="noreferrer noopener" href="https://github.com/WordPress/wordpress-develop/commit/2c6bf77a9e7532c6ac3a03502b44d108cae86179" target="_blank">https://github.com/WordPress/wordpress-develop/commit/2c6bf77a9e7532c6ac3a03502b44d108cae86179</a>
<ul>
<li>I hope to get comment meta in the next week.<br /><a rel="noreferrer noopener" href="https://github.com/WordPress/wordpress-develop/pull/4128" target="_blank">https://github.com/WordPress/wordpress-develop/pull/4128</a> – Code review welcome</li>
<li>Related to term meta, <a rel="noreferrer noopener" href="https://github.com/WordPress/wordpress-develop/pull/4259" target="_blank">https://github.com/WordPress/wordpress-develop/pull/4259</a> also need code review</li>
<li>This saves around 15k calls to sanitise term function per page load</li>
<li>TLDR, there was no need to call <code>get_term</code> , we already had the term id, so just remove that</li>
<li>I also reviewed this – <a rel="noreferrer noopener" href="https://github.com/WordPress/wordpress-develop/pull/4097" target="_blank">https://github.com/WordPress/wordpress-develop/pull/4097</a> (amazing work <a href="https://profiles.wordpress.org/oandregal/" class="mention"><span class="mentions-prefix">@</span>oandregal</a>)</li>
<li><a href="https://profiles.wordpress.org/joemcgill/" class="mention"><span class="mentions-prefix">@</span>joemcgill</a> This is a huge one that I had noticed in my profiling research, so nice to see this already addressed!</li>
<li><a href="https://profiles.wordpress.org/10upsimon/" class="mention"><span class="mentions-prefix">@</span>10upsimon</a> Call me cheesy, but 15% <em>server time</em> alone across many WP hosts is a positive contribution to the environment alone</li>
<li><a href="https://profiles.wordpress.org/mukesh27/" class="mention"><span class="mentions-prefix">@</span>mukesh27</a> With all this improvement, 6.3 is faster than 6.2
<ul>
<li><a href="https://profiles.wordpress.org/flixos90/" class="mention"><span class="mentions-prefix">@</span>flixos90</a> Yeah, this alone will make block theme performance in 6.3 almost as much faster as it got faster in 6.2</li>
</ul>
</li>
<li><a href="https://profiles.wordpress.org/flixos90/" class="mention"><span class="mentions-prefix">@</span>flixos90</a> Certainly the highest performance improvement in a single PR that I’ve seen so far</li>
<li><a href="https://profiles.wordpress.org/joemcgill/" class="mention"><span class="mentions-prefix">@</span>joemcgill</a> Worth noting that the 15% improvement on that PR is compared against WP 6.1.1, not the commit prior to that one, so it would be interesting to A/B against the commit prior (if I’m reading the workflow correctly)
<ul>
<li><a href="https://profiles.wordpress.org/flixos90/" class="mention"><span class="mentions-prefix">@</span>flixos90</a> No, the 15% is against today’s <code>trunk</code>. The original metrics on the PR are incorrect, but then I measured it against <code>trunk</code> and that’s where the 15% come from</li>
</ul>
</li>
</ul>
</li>
</ul>
<h3 class="wp-block-heading" id="images">Database Optimization</h3>
<p><a href="https://make.wordpress.org/performance/roadmap-2023/#category-database-optimization">Link to roadmap projects</a></p>
<p>Contributors: <a href="https://profiles.wordpress.org/aristath/" class="mention"><span class="mentions-prefix">@</span>aristath</a> <a href="https://profiles.wordpress.org/spacedmonkey/" class="mention"><span class="mentions-prefix">@</span>spacedmonkey</a> <a href="https://profiles.wordpress.org/olliejones/" class="mention"><span class="mentions-prefix">@</span>olliejones</a> <a href="https://profiles.wordpress.org/rjasdfiii/" class="mention"><span class="mentions-prefix">@</span>rjasdfiii</a></p>
<ul>
<li><a href="https://profiles.wordpress.org/olliejones/" class="mention"><span class="mentions-prefix">@</span>olliejones</a> I’ve been on the SQLite Object Cache, making it more useful for <a href="https://profiles.wordpress.org/spacedmonkey/" class="mention"><span class="mentions-prefix">@</span>spacedmonkey</a> hopefully – Nothing on the bigger SQLite project.</li>
<li><a href="https://profiles.wordpress.org/spacedmonkey/" class="mention"><span class="mentions-prefix">@</span>spacedmonkey</a> Not related to database, but object caching. I have been working WP CLI support new functionality object cache
<ul>
<li><a rel="noreferrer noopener" href="https://github.com/wp-cli/cache-command/issues/79" target="_blank">https://github.com/wp-cli/cache-command/issues/79</a></li>
<li><a rel="noreferrer noopener" href="https://github.com/wp-cli/cache-command/issues/80" target="_blank">https://github.com/wp-cli/cache-command/issues/80</a></li>
</ul>
</li>
</ul>
<h3 class="wp-block-heading" id="object-caching">JavaScript &#038; CSS</h3>
<p><a href="https://make.wordpress.org/performance/roadmap-2023/#category-javascript-css">Link to roadmap project</a></p>
<p>Contributors: <a href="https://profiles.wordpress.org/mukesh27/" class="mention"><span class="mentions-prefix">@</span>mukesh27</a> <a href="https://profiles.wordpress.org/10upsimon/" class="mention"><span class="mentions-prefix">@</span>10upsimon</a> <a href="https://profiles.wordpress.org/adamsilverstein/" class="mention"><span class="mentions-prefix">@</span>adamsilverstein</a></p>
<ul>
<li><a href="https://profiles.wordpress.org/10upsimon/" class="mention"><span class="mentions-prefix">@</span>10upsimon</a> Regarding “Enhancing the WP Scripts API with a Loading Strategy”:
<ul>
<li>We’ve had a good amount of feedback and iteration on our draft PR</li>
<li>We’ve had some valuable feedback come in this week, so we’ll be addressing that with the goal of opening a PR against core later this week. Thanks <a href="https://profiles.wordpress.org/joemcgill/" class="mention"><span class="mentions-prefix">@</span>joemcgill</a> <a href="https://profiles.wordpress.org/adamsilverstein/" class="mention"><span class="mentions-prefix">@</span>adamsilverstein</a> and <a href="https://profiles.wordpress.org/westonruter/" class="mention"><span class="mentions-prefix">@</span>westonruter</a> for the invaluable feedback thus far (and to <a href="https://profiles.wordpress.org/spacedmonkey/" class="mention"><span class="mentions-prefix">@</span>spacedmonkey</a>)</li>
<li>We’ve established a mostly approved documentation plan/roadmap, with slight ongoing tweaks thereto. Draft documentation and documentation updates can commence soon</li>
</ul>
</li>
<li><a href="https://profiles.wordpress.org/flixos90/" class="mention"><span class="mentions-prefix">@</span>flixos90</a> One more thing regarding JS &#038; CSS, last week I opened <a rel="noreferrer noopener" href="https://github.com/WordPress/gutenberg/issues/49927" target="_blank">https://github.com/WordPress/gutenberg/issues/49927</a> to optimize how block CSS is loaded in classic themes (it’s great in block themes, but not so much for classic themes, and we can probably improve that). There have been some great conversations on that. <a href="https://profiles.wordpress.org/aristath/" class="mention"><span class="mentions-prefix">@</span>aristath</a> has pointed out a detailed code example with how we could improve this by printing inline styles per block type right before the first block of each type is rendered
<ul>
<li><a href="https://profiles.wordpress.org/aristath/" class="mention"><span class="mentions-prefix">@</span>aristath</a> If you have some capacity to work on a PR, I think that would be a great next step</li>
<li><a href="https://profiles.wordpress.org/flixos90/" class="mention"><span class="mentions-prefix">@</span>flixos90</a> If we can find a solution that works reliably, maybe we can eventually even change the default behavior so that it’s no longer opt-in but just works out of the box </li>
<li><a href="https://profiles.wordpress.org/spacedmonkey/" class="mention"><span class="mentions-prefix">@</span>spacedmonkey</a> I have a PR for the above – <a rel="noreferrer noopener" href="https://github.com/spacedmonkey/wordpress-develop/tree/try/inline-styles" target="_blank">https://github.com/spacedmonkey/wordpress-develop/tree/try/inline-styles</a> It might be useful in discovery</li>
</ul>
</li>
</ul>
<h3 class="wp-block-heading" id="measurement">Images</h3>
<p><a href="https://make.wordpress.org/performance/roadmap-2023/#category-images">Link to roadmap projects</a></p>
<p>Contributors: <a href="https://profiles.wordpress.org/flixos90/" class="mention"><span class="mentions-prefix">@</span>flixos90</a> <a href="https://profiles.wordpress.org/thekt12/" class="mention"><span class="mentions-prefix">@</span>thekt12</a> <a href="https://profiles.wordpress.org/adamsilverstein/" class="mention"><span class="mentions-prefix">@</span>adamsilverstein</a> <a href="https://profiles.wordpress.org/joemcgill/" class="mention"><span class="mentions-prefix">@</span>joemcgill</a></p>
<ul>
<li>No updates this week</li>
</ul>
<h3 class="wp-block-heading" id="javascript">Measurement</h3>
<p><a href="https://make.wordpress.org/performance/roadmap-2023/#category-measurement">Link to roadmap projects</a></p>
<p>Contributors: <a href="https://profiles.wordpress.org/adamsilverstein/" class="mention"><span class="mentions-prefix">@</span>adamsilverstein</a> <a href="https://profiles.wordpress.org/olliejones/" class="mention"><span class="mentions-prefix">@</span>olliejones</a> <a href="https://profiles.wordpress.org/joemcgill/" class="mention"><span class="mentions-prefix">@</span>joemcgill</a> <a href="https://profiles.wordpress.org/mukesh27/" class="mention"><span class="mentions-prefix">@</span>mukesh27</a></p>
<ul>
<li><a href="https://profiles.wordpress.org/joemcgill/" class="mention"><span class="mentions-prefix">@</span>joemcgill</a> I’ve been working to prioritize a set of “next steps” for automated performance testing. For me, the “next step” is to turn these tasks into trac tickets that we can address as capacity allows.
<ul>
<li>One of the big ones is to improve the stability of the results and make them more atomic, so we can use them to evaluate specific PRs (like the discussion we had earlier about the <code>get_block_templates</code> PR)</li>
</ul>
</li>
</ul>
<h3 class="wp-block-heading">Ecosystem Tools</h3>
<p><a href="https://make.wordpress.org/performance/roadmap-2023/#category-ecosystem-tools">Link to roadmap projects</a></p>
<p>Contributors: <a href="https://profiles.wordpress.org/joegrainger/" class="mention"><span class="mentions-prefix">@</span>joegrainger</a></p>
<ul>
<li><a href="https://profiles.wordpress.org/joegrainger/" class="mention"><span class="mentions-prefix">@</span>joegrainger</a> We’re still progressing through the issues raised in the Plugin Checker Milestone 1 Review/QA and will continue to be working on these over the coming weeks. You can follow the progress on the <a rel="noreferrer noopener" href="https://github.com/10up/plugin-check/" target="_blank">GitHub repo</a> and any thoughts/ideas/comments are welcome. Thanks!</li>
<li><a href="https://profiles.wordpress.org/spacedmonkey/" class="mention"><span class="mentions-prefix">@</span>spacedmonkey</a> Got some feedback from the community – <a rel="noreferrer noopener" href="https://github.com/10up/plugin-check/issues/153" target="_blank">https://github.com/10up/plugin-check/issues/153</a></li>
</ul>
<h3 class="wp-block-heading" id="infrastructure">Creating Standalone Plugins</h3>
<p><a href="https://github.com/WordPress/performance/issues/656">Link to GitHub overview issue</a></p>
<p>Contributors: <a href="https://profiles.wordpress.org/flixos90/" class="mention"><span class="mentions-prefix">@</span>flixos90</a> <a href="https://profiles.wordpress.org/mukesh27/" class="mention"><span class="mentions-prefix">@</span>mukesh27</a> <a href="https://profiles.wordpress.org/10upsimon/" class="mention"><span class="mentions-prefix">@</span>10upsimon</a></p>
<ul>
<li><a href="https://profiles.wordpress.org/flixos90/" class="mention"><span class="mentions-prefix">@</span>flixos90</a> We’re still waiting to get the Fetchpriority standalone plugin approved, beyond that and then the same for Dominant Color, we have basically completed the work for “Milestone 1” in <a rel="noreferrer noopener" href="https://github.com/WordPress/performance/issues/656" target="_blank">https://github.com/WordPress/performance/issues/656</a>
<ul>
<li>We should probably close <a rel="noreferrer noopener" href="https://github.com/WordPress/performance/issues/661" target="_blank">https://github.com/WordPress/performance/issues/661</a> following the conversation earlier, or we can break it out as another issue to discuss how to remove SQLite from PL</li>
</ul>
</li>
<li><a href="https://profiles.wordpress.org/flixos90/" class="mention"><span class="mentions-prefix">@</span>flixos90</a> Separately, we need to explore what we want the user experience for “Milestone 2” to look like, both in terms of the regular UI of the PL plugin going forward (in which it controls certain plugins as well as the Site Health modules), and for a smooth migration from the modules to remove to their standalone plugins</li>
</ul>
<h2 class="wp-block-heading" id="infrastructure">New Projects / Proposals</h2>
<ul>
<li><a href="https://profiles.wordpress.org/spacedmonkey/" class="mention"><span class="mentions-prefix">@</span>spacedmonkey</a> I would love feedback on – <a rel="noreferrer noopener" href="https://github.com/WordPress/performance/issues/718" target="_blank">https://github.com/WordPress/performance/issues/718</a> a new module proposal for adding object caching information to site health
<ul>
<li>I want to make it easier for users to understand what kind of object cache they are using and what features it supports.</li>
<li>Specially if your object cache drop in supports multiple gets. I got a lot of questions after this <a rel="noreferrer noopener" href="https://xwp.co/object-caching-improvement-wordpress-6-2/" target="_blank">article</a> was published.</li>
</ul>
</li>
</ul>
<h1 class="wp-block-heading">Open Floor</h1>
<ul>
<li>No updates</li>
</ul>
<p><strong>Our next chat will be held on <a href="https://www.timeanddate.com/worldclock/fixedtime.html?iso=20230502T1500"><abbr class="date" title="2023-05-02T15:00:00+00:00">Tuesday, May 2, 2023 at 15:00 UTC</abbr></a> in the <a href="https://wordpress.slack.com/messages/core-performance/">#core-performance channel</a> in <a href="https://make.wordpress.org/chat/">Slack</a>.</strong></p>
<p class="o2-appended-tags"><a href="https://make.wordpress.org/core/tag/core-media/" class="tag"><span class="tag-prefix">#</span>core-media</a>, <a href="https://make.wordpress.org/core/tag/core-performance/" class="tag"><span class="tag-prefix">#</span>core-performance</a>, <a href="https://make.wordpress.org/core/tag/performance/" class="tag"><span class="tag-prefix">#</span>performance</a>, <a href="https://make.wordpress.org/core/tag/performance-chat/" class="tag"><span class="tag-prefix">#</span>performance-chat</a>, <a href="https://make.wordpress.org/core/tag/summary/" class="tag"><span class="tag-prefix">#</span>summary</a></p>
</div>

As October winds down, so too does Blocktober, Tammie Lister’s month-long challenge to create a…
The WordPress Foundation and WooCommerce have joined Automattic and Matt Mullenweg in countersuing WP Engine,…
The first-ever CloudFest USA Hackathon, taking place November 4 in Miami, will bring together contributors…
Canada’s largest gathering of WordPress enthusiasts drew a strong turnout at Carleton University last weekend,…
WooCommerce 10.3 was released this week, introducing one of the most requested features for store…
Automattic has hired GiveWP co-founder Devin Walker as Artistic Director for Jetpack, where he will…