class/class-mainwp-child-maintenance.php (1)

263-264: LGTM! Appropriate justification for uncached query.

The comment correctly explains why caching is not suitable for this query—revision IDs are fetched for immediate deletion and the data becomes stale instantly. The prepared statement is properly parameterized.

Minor formatting note: Line 264 has a double space after FROM before $wpdb->posts.

Apply this diff to fix the formatting:

-            $results_posts    = $wpdb->get_results( $wpdb->prepare( "SELECT `ID`, `post_modified` FROM  $wpdb->posts WHERE `post_parent`= %d AND `post_type`='revision' ORDER BY `post_modified` ASC", $results[ $i ]->post_parent ) );
+            $results_posts    = $wpdb->get_results( $wpdb->prepare( "SELECT `ID`, `post_modified` FROM $wpdb->posts WHERE `post_parent`= %d AND `post_type`='revision' ORDER BY `post_modified` ASC", $results[ $i ]->post_parent ) );

class/class-mainwp-child-timecapsule.php (1)

1929-1935: MySQL version caching is implemented correctly; optional TTL constant usage

The MySQL version caching via wp_cache_get/wp_cache_set with a dedicated group is sound and avoids repeating the SELECT VERSION() call within the cache window. The strict false === $mysql_version check is also appropriate.

If you want to align with other WordPress code, you could swap the literal 3600 for HOUR_IN_SECONDS, but that’s purely stylistic.

class/class-mainwp-child-pagespeed.php (1)

530-552: Pagespeed caching + filter-option hardening look good; minor refactor opportunities

• Caching the computed Pagespeed aggregates per strategy via wp_cache_get/wp_cache_set using a key derived from $strategy and get_filter_options( 'all' ) is a solid approach that avoids re-running the heavy queries on every sync.
• The $allowed_score_columns mapping and selection of $score_column from the validated strategy prevent arbitrary column injection into the SQL.
• Both gpi_page_stats and gpi_page_reports queries rely on the get_filter_options() contract (fragment in [0], values in [1] with %s placeholders), and the updated docblock plus the custom‑post‑type comment make that safety argument explicit.
• Caching custom_url_types via wp_cache_get/wp_cache_set in get_filter_options() is a nice touch to cut down on repeated SELECT DISTINCT type FROM ...gpi_custom_urls calls, especially on larger datasets.

If you want to tighten things further without changing behavior:

• Consider calling get_filter_options( 'all' ) only once in cal_pagespeed_data() and reusing the result for both $data_typestocheck and $reports_typestocheck to avoid duplicated work.
• For consistency with other caches in this PR, you might also standardize TTL usage on HOUR_IN_SECONDS everywhere (where you aren’t already).

These are polish-level suggestions; the current implementation is functionally sound.

Also applies to: 557-568, 617-620, 652-653, 680-685

class/class-mainwp-child-woocommerce-status.php (1)

134-181: Status whitelisting and cached monthly sales/top-seller queries look safe; consider normalizing the cache key time component

Positives:

• The woocommerce_reports_order_statuses result is intersected with an explicit $allowed_statuses list before being used in the IN ( {$placeholders} ) clause, which is a good hardening step.
• Dynamic placeholders plus array_merge( $safe_statuses, array( $month_start, $month_end ) ) keep the query parameterized and avoid any injection via statuses or dates.
• Caching both sales and top_seller results for the “current month” in the mainwp_woocommerce group with a 1‑hour TTL aligns with the PR’s performance goal.

One nuance: the cache keys include $month_end formatted as Y-m-d H:i:s. Because that value changes every second, repeated calls to sync_data() will almost always compute a new cache key, so cache hits will be rare and you may accumulate many short‑lived entries under a persistent object cache.

If you want the cache to be effective while still reflecting near‑real‑time stats, you could normalize the time part used in the key to an hour (or a day) while still using the full $month_end in the query, for example:

-        $month_start = date( 'Y-m-01' ); // phpcs:ignore -- local time.
-        $month_end   = date( 'Y-m-d H:i:s' ); // phpcs:ignore -- local time.
+        $month_start = date( 'Y-m-01' ); // phpcs:ignore -- local time.
+        $month_end   = date( 'Y-m-d H:i:s' ); // phpcs:ignore -- local time.
+        $cache_window = date( 'Y-m-d H:00:00' ); // Normalize to hour for cache key.

-        $cache_key = 'wc_sales_' . md5( implode( '_', $safe_statuses ) . '_' . $month_start . '_' . $month_end );
+        $cache_key = 'wc_sales_' . md5( implode( '_', $safe_statuses ) . '_' . $month_start . '_' . $cache_window );

-        $cache_key_top = 'wc_top_seller_' . md5( implode( '_', $safe_statuses ) . '_' . $month_start . '_' . $month_end );
+        $cache_key_top = 'wc_top_seller_' . md5( implode( '_', $safe_statuses ) . '_' . $month_start . '_' . $cache_window );

That keeps the 1‑hour TTL meaningful and avoids effectively “no‑op” caching.

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

Disabled knowledge base sources:

• Linear integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.

class/class-mainwp-child-pagespeed.php (1)

597-608: Fix undefined $data when no filter options are returned (still present)

When get_filter_options( 'all' ) returns null (no types enabled), the if ( ! is_null( $reports_typestocheck ) ) block is skipped, $data is never defined, and is_array( $data[0] ) will emit PHP notices. This was flagged in an earlier review and remains unresolved.

Consider guarding the last‑modified computation with an explicit default variable, e.g.:

-        if ( ! is_null( $reports_typestocheck ) ) {
-            $gpi_page_stats = $wpdb->prefix . 'gpi_page_stats'; // @wordpress-security:ignore UnescapedDBParameter -- Table name is safe: wpdb->prefix + constant.
-				$data           = $wpdb->get_results( $wpdb->prepare( "SELECT $_select FROM $gpi_page_stats WHERE ( $reports_typestocheck[0] ) AND $nullcheck", $reports_typestocheck[1] ), ARRAY_A ); // phpcs:ignore WordPress.DB.DirectDatabaseQuery.DirectQuery,WordPress.DB.DirectDatabaseQuery.NoCaching,PluginCheck.Security.DirectDB.UnescapedDBParameter -- $_select is hardcoded from switch statement (lines 589, 593), $gpi_page_stats is safe constant (line 598), $reports_typestocheck[0] is validated SQL fragment (line 557), $nullcheck is hardcoded (lines 588, 592).
-        }
-
-        $result = array(
-            'last_modified' => is_array( $data[0] ) && isset( $data[0]['last_modified'] ) ? $data[0]['last_modified'] : 0,
+        $last_modified = 0;
+        if ( ! is_null( $reports_typestocheck ) ) {
+            $gpi_page_stats = $wpdb->prefix . 'gpi_page_stats'; // @wordpress-security:ignore UnescapedDBParameter -- Table name is safe: wpdb->prefix + constant.
+            $data           = $wpdb->get_results(
+                $wpdb->prepare(
+                    "SELECT $_select FROM $gpi_page_stats WHERE ( $reports_typestocheck[0] ) AND $nullcheck",
+                    $reports_typestocheck[1]
+                ),
+                ARRAY_A
+            ); // phpcs:ignore WordPress.DB.DirectDatabaseQuery.DirectQuery,WordPress.DB.DirectDatabaseQuery.NoCaching,PluginCheck.Security.DirectDB.UnescapedDBParameter -- $_select is hardcoded, $gpi_page_stats is safe, $reports_typestocheck is validated.
+            if ( ! empty( $data[0]['last_modified'] ) ) {
+                $last_modified = $data[0]['last_modified'];
+            }
+        }
+
+        $result = array(
+            'last_modified' => $last_modified,
             'average_score' => $average_score,
             'total_pages'   => $total_pages,
         );

Please rerun with a configuration where get_filter_options( 'all' ) returns null (e.g., all types unchecked) to confirm the notices are gone.

class/class-mainwp-child-woocommerce-status.php (2)

134-216: Status whitelist + cached sales/top‑seller query look sound

The status handling (filter → intersect with $allowed_statuses → fallback to ['completed']), dynamic IN‑clause placeholders, and cache keys tied to statuses + month range all look correct and safe; the queries remain parameterized and benefit from caching.

If you want to reduce duplication and future drift, consider extracting a small helper like get_safe_order_statuses_and_placeholders() that returns both $safe_statuses and $placeholders, and reuse it in both sync_data() and report_data(). Please also sanity‑check that the status slugs here match the versions of WooCommerce you still support on this legacy code path.

---

285-363: Report data caching mirrors sync logic correctly

The report‑range sales and top‑seller queries reuse the same status‑whitelisting and placeholder pattern, with cache keys bound to statuses + explicit start/end dates; that’s consistent with sync_data() and should avoid redundant DB work across identical report requests.

You might want to share a tiny internal helper for building the cache key (statuses + date window) so sync_data() and report_data() can’t diverge subtly over time; verify via a quick test that different permutations of the same statuses (e.g., ['completed','processing'] vs ['processing','completed']) don’t need to share a cache entry for your use case.

class/class-mainwp-child-pagespeed.php (2)

557-571: Reports query correctly scopes by strategy; consider reusing filter options

The updated reports query properly constrains by r.strategy = %s and passes the strategy plus the validated filter‑options array into $wpdb->prepare, keeping the SQL safe while enabling per‑strategy aggregation.

Since both $data_typestocheck and $reports_typestocheck are derived from get_filter_options( 'all' ), you could call it once, assign to a local variable, and reuse it for both queries to avoid duplicated option reads/DB lookups (the new custom_url_types caching already makes the underlying query cheap, but this would still simplify control flow).

---

617-619: Filter‑options contract and custom URL type caching look good

The updated docblock for get_filter_options() clearly documents the [0] SQL fragment / [1] parameters contract, and the new custom_url_types caching (via wp_cache_get/set in the mainwp_pagespeed group) is a simple, safe way to avoid repeated DISTINCT queries against gpi_custom_urls.

If you find yourself using different restrict_type values frequently, you might later extend the custom_url_types cache key to include $restrict_type or split caches by use‑case, but the current global key is fine given the single underlying query; a quick runtime test with/without custom URLs will verify that behavior matches expectations.

Also applies to: 652-652, 680-685

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

Disabled knowledge base sources:

• Linear integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.

class/class-mainwp-child-pagespeed.php (1)

597-605: Still possible undefined offset on $data[0] when no rows are returned

Even though $data is now initialized to an empty array, the expression is_array( $data[0] ) && isset( $data[0]['last_modified'] ) will still trigger a PHP notice when $data is empty, because $data[0] is an undefined offset. This can happen if:

• get_filter_options( 'all' ) returns null (no types enabled) → the query is skipped and $data stays array(), or
• The query runs but returns zero rows for the selected types.

You can avoid this by computing $last_modified separately and only reading $data[0]['last_modified'] when it exists, as previously suggested:

-        $data = array();
-
-        if ( ! is_null( $reports_typestocheck ) ) {
-            $gpi_page_stats = $wpdb->prefix . 'gpi_page_stats'; // @wordpress-security:ignore UnescapedDBParameter -- Table name is safe: wpdb->prefix + constant.
-            $data           = $wpdb->get_results( $wpdb->prepare( "SELECT $_select FROM $gpi_page_stats WHERE ( $reports_typestocheck[0] ) AND $nullcheck", $reports_typestocheck[1] ), ARRAY_A ); // phpcs:ignore WordPress.DB.DirectDatabaseQuery.DirectQuery,WordPress.DB.DirectDatabaseQuery.NoCaching,PluginCheck.Security.DirectDB.UnescapedDBParameter -- $_select is hardcoded from switch statement (lines 589, 593), $gpi_page_stats is safe constant (line 598), $reports_typestocheck[0] is validated SQL fragment (line 557), $nullcheck is hardcoded (lines 588, 592).
-        }
-
-        $result = array(
-            'last_modified' => is_array( $data[0] ) && isset( $data[0]['last_modified'] ) ? $data[0]['last_modified'] : 0,
+        $last_modified = 0;
+        if ( ! is_null( $reports_typestocheck ) ) {
+            $gpi_page_stats = $wpdb->prefix . 'gpi_page_stats'; // @wordpress-security:ignore UnescapedDBParameter -- Table name is safe: wpdb->prefix + constant.
+            $data           = $wpdb->get_results(
+                $wpdb->prepare(
+                    "SELECT $_select FROM $gpi_page_stats WHERE ( $reports_typestocheck[0] ) AND $nullcheck",
+                    $reports_typestocheck[1]
+                ),
+                ARRAY_A
+            ); // phpcs:ignore WordPress.DB.DirectDatabaseQuery.DirectQuery,WordPress.DB.DirectDatabaseQuery.NoCaching,PluginCheck.Security.DirectDB.UnescapedDBParameter -- $_select is hardcoded, $gpi_page_stats and $reports_typestocheck are validated.
+            if ( ! empty( $data[0]['last_modified'] ) ) {
+                $last_modified = $data[0]['last_modified'];
+            }
+        }
+
+        $result = array(
+            'last_modified' => $last_modified,
             'average_score' => $average_score,
             'total_pages'   => $total_pages,
         );

This keeps behavior the same when data exists but removes undefined-offset notices when it does not.

class/class-mainwp-child-pagespeed.php (2)

530-535: Caching strategy looks sound; consider avoiding duplicate filter computation

The new cache layer keyed by strategy and the serialized filter fragment ($data_typestocheck) is reasonable, and using the mainwp_pagespeed group with HOUR_IN_SECONDS TTL is consistent with the rest of the PR. The whitelisting of $score_column via $allowed_score_columns keeps the dynamic column safe.

You can shave some work and keep the logic more obviously consistent by reusing the first get_filter_options( 'all' ) result instead of recomputing it for $reports_typestocheck, e.g.:

-        $data_typestocheck = self::get_filter_options( 'all' );
+        $data_typestocheck = self::get_filter_options( 'all' );
         ...
-        $reports_typestocheck = self::get_filter_options( 'all' );
+        $reports_typestocheck = $data_typestocheck;

(Or rename to an appropriate shared variable.) This is optional, but reduces one DB-backed call per execution path.

Also applies to: 537-552, 557-571, 609-610

---

537-542: Guard against future misuse of $strategy when indexing $allowed_score_columns

Right now $strategy is validated earlier to be either 'desktop' or 'mobile', so $allowed_score_columns[ $strategy ] is safe. If this function ever gets called from another path without that guard, it could emit a notice.

A small defensive tweak keeps it robust:

-        $score_column = $allowed_score_columns[ $strategy ];
+        $score_column = isset( $allowed_score_columns[ $strategy ] )
+            ? $allowed_score_columns[ $strategy ]
+            : 'desktop_score'; // or return false here if you prefer strictness

This is not required today but makes the function safer against future refactors.

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

Disabled knowledge base sources:

• Linear integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.