thanks to dear member @chavez updated Scalability Pro with a new update entry:
20th June 2024
Read the rest of this update entry...
20th June 2024
Read the rest of this update entry...
* Added new SPRO_SQL_CALC_ROWS_FINGERPRINT definition to defines.php to allow users to decide additional WP_Queries which should have SQL_CALC_ROWS removed from the query
- Customer was using TagDiv Composer library to build their website and with 8 blocks on their page, this was adding 0.1s, 0.8s to the page generation
- by adding a fingerprint definition into their wp-config.php with this new option, those blocks have SQL_CALC_ROWS removed and speed of those queries becomes instant
-...
* Hotfix for settings upgrade from yesterday1
* Updated slow query log profiling to improve handling when wp-config.php cannot be edited
- for best results with the query profiling, make sure you have the db.php symlink in place and wp-config.php edited
* Upgraded the Remove Row Count feature
- limits itself to running against post queries with < 10 rows requested
- transforms news and magazine sites or those with mega menus where you have a dozen or so short queries for posts on your various pages
- added similar code to the Admin version of Remove Row Count
- we're seeing newpaper page load speeds drop from 12s to 1.4s uncached
* Added new tagDiv recent posts indexes for these newspaper websites
* Fixed the remove product category hierarchy option in wp-admin > products list view
* Hotfix for pagination page 1!
* Fixed remove group by option so that it ONLY applies to that dropdown
- @hakan found that filtering the wp-admin > product list by category was broken unless the cat was a top level cat
* Updated settings page interface - added logo, added context help
* Moved settings page to underneath Super Speedy
* Updated license checker code
* Minor optimisation in SQL_CALC_FOUND_ROWS code
* Updated SQL_CALC_FOUND_ROWS to not run for REST API requests - note: this will be reintroduced in future, but with a better solution. REST API calls tend to fetch page after page, so in their case, I could allow SQL_CALC_FOUND_ROWS on the first call, then cache the total count for page 2+ so that...