- None this week
Focus area updates
- @adamsilverstein not much to update from my end this week. I have been mostly thinking about/planning for WordCamp Asia & contributor day, coming up with a plan for that. I’d love feedback about good ways to engage new contributors on performance
- @spacedmonkey several issues to update on:
- New tickets
- Still in need of review and has unit tests
- @spacedmonkey spent a lot of time working on https://core.trac.wordpress.org/ticket/56975 where there’s some interesting profiling data on the before and after captured here https://github.com/WordPress/wordpress-develop/pull/3887#issuecomment-1402055695
- @joegrainger: been away for a few days but have been making progress on the Plugin Checker infrastructure. Still more to be done, but you can see the work carried out here https://github.com/10up/plugin-check (we’re developing the project here, but will be eventually moved to the WordPress organisation).
- The plugin checker will be run through both the CLI and the WP Admin. Feel free to take a look at the issues and leave thoughts/ideas you may have
JS & CSS
- No updates
- @aristath Last week, SQLite was released as a stand-alone plugin. No announcement action etc was taken. I left that TBD so we can coordinate our policy and strategy as a performance team. The submission was done early to get a head-start with the plugin review process etc – which made sense since this was a direct request from Matt.
- The repo for the stand-alone plugin was moved to the WordPress organization on GitHub
- The call-for testing post was updated to include links both to the PL plugin as well as the stand-alone plugin.
- @olliejones Ari released the SQLite DBMS engine integration as a standalone plugin https://wordpress.org/plugins/sqlite-database-integration/ … And I assume we’ll take up https://github.com/WordPress/performance/issues/625 during the open-floor time
- @olliejones The SQLite DBMS project is going to require large-scale testing to get to beta status
- @spacedmonkey asked where is the best place to provide feedback for this plugin – best course of action to create an issue here https://github.com/OllieJones/sqlite-object-cache/issues
- @flixos90 No recent updates, however I opened https://github.com/WordPress/performance/issues/627 yesterday. What I’m proposing in that issue is to bump the minimum version requirement of Performance Lab to WordPress 6.1. This will allow us to remove the two Site Health cache modules that were already launched in WordPress 6.1, which at this point are a bit of unnecessary baggage to still have in there
- Note that per our version support policy our commitment is to only support the latest WordPress release anyway, so this should be okay
- Discussion around plugin versioning:
- @flixos90 I see there’s a suggestion by @joemcgill to potentially have a 1.10.0 with that code being deprecated first. I don’t think that would help here. FWIW, the modules are already not loaded today when you have WP 6.1. So nothing changes for you either way when they’re removed:
- Either you are on WP
- Or you are on WP 6.1, which means you already are using the core feature, and the PL modules for the same purpose are not loaded.
- That was behind the https://make.wordpress.org/performance/handbook/performance-lab/version-support-policy/
- @joemcgill Makes sense to me. Just getting up to speed on the process here now that I have time dedicated to work on these performance projects. The documented policy seems quite clear
- Agreed no vote required on this
- @olliejones discussed the module proposal for SQLite Persistent Object Cache
- It’s a standalone plugin. Does it make sense to build it into PL, to put it onto a track to go into core?
- @spacedmonkey I think it needs to live as a plugin for a while
- @flixos90 A bit of a tricky question. Of course we are working towards unbundling the PL plugin. But we’re still pending a decision on how exactly, and at this point it may make sense in the PL plugin. Is it already published on wp.org or not?
- @olliejones Absolutely live as a plugin. There’s no other way to get decent field experience. And this kind of thing requires field experience.
- @spacedmonkey I want to test it on bigger sites, multisite, ensure cache invalidation works, support wp_cache_get_multiple and some other stuff
- Yes, published, https://wordpress.org/plugins/sqlite-object-cache/ If it goes into PL, we’ll need to sort out the use of the object-cache.php drop-in module.
- @flixos90 Okay, we should definitely keep it published like that then. I think at this point, let’s just keep it like that? We could potentially add it as a PL module too, but depending on the path decided on for unbundling the PL plugin, that would just be unnecessary work – so probably most efficient (until we have a decision) to work in its own repo for now
- @spacedmonkey discussed the Trac ticket for making php 7.2 the minimum version of support php in WordPress https://core.trac.wordpress.org/ticket/57345 and asked if this is something we should be pushing for as the performance team
- @olliejones I say yes, smaller QA matrices are always good
- @joemcgill It could certainly have some positive performance implications, though I’m not sure how much impact we would have since the process for bumping versions is pretty well established (unless I’m wrong). It would be nice to help support that effort with some evidence about the performance benefits from any automated testing we do against different versions.