Updated: passed test percentage logic to include scannable post types and handle cases with no posts scanned. - #1291
Conversation
… and handle cases with no posts scanned.
Summary of ChangesHello @SteveJonesDev, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request refines the scan statistics logic to enhance the accuracy and relevance of the displayed data. It ensures that issue queries are limited to only scannable post types and introduces a more robust calculation for the "passed percentage," preventing its display when no meaningful data is available. This leads to more reliable and contextually appropriate scan reports. Highlights
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
WalkthroughThe Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~12 minutes
Possibly related PRs
Suggested reviewers
Poem
Pre-merge checks and finishing touches✅ Passed checks (3 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
Comment |
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request correctly updates the scan statistics logic to only consider scannable post types when calculating failed rules and the passed tests percentage. The logic now correctly handles cases where no posts are scanned or no post types are scannable, preventing misleading statistics. My review includes a suggestion to improve performance by reducing redundant function calls within the summary method.
| $rule_query = new Issues_Query( | ||
| [ | ||
| 'rule_slugs' => [ $rule_slug ], | ||
| 'post_types' => Settings::get_scannable_post_types(), |
There was a problem hiding this comment.
The function Settings::get_scannable_post_types() is called multiple times within the summary method (here inside a loop, and on lines 199, 206, 216, 227, 240, and 251). This can be inefficient as the function may perform database queries. To improve performance, consider calling it once at the start of the summary method, storing the result in a variable, and reusing that variable throughout the method.
There was a problem hiding this comment.
This seems like a nice change here but it's somewhat out of scope of the actual thing being fixed here.
The method does make a query to get an option and then processes it but the option is autoloaded so only retrieved once from database then from memory on subsequent calls.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
admin/class-scans-stats.php (1)
198-200:passed_percentagegating avoids misleading values and divide-by-zeroInitializing
passed_percentageto'N/A'and only computing it when there are scannable post types, at least one scanned post, andtests_count > 0cleanly prevents showing100%when nothing has actually been scanned and also guards against division by zero when there are no tests. This aligns with how other metrics fall back to'N/A'.As a minor optimization, if you find yourself calling
Settings::get_scannable_post_types()frequently insummary(), consider caching it in a local variable once per call, but this is optional.
📜 Review details
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.
📒 Files selected for processing (1)
admin/class-scans-stats.php(2 hunks)
🧰 Additional context used
📓 Path-based instructions (3)
**/*.php
📄 CodeRabbit inference engine (.github/copilot-instructions.md)
**/*.php: Follow WordPress Coding Standards (WPCS) in all PHP files
Class names use CamelCase (ClassNameConvention) for new classes
Use edac_ prefix for all custom action/filter hook names
Ensure PHP 7.4+ compatibility
Use type hints where appropriate (parameters, return types, properties)
Sanitize inputs, validate data, and escape outputs following WordPress security best practices; use nonces for forms/AJAX
Use the WordPress database API ($wpdb) for all database operations
Prefix functions and classes in the global namespace with edac_
Use WordPress transients for caching temporary data where appropriate
All user-facing text in PHP must be translatable using the accessibility-checker text domain
Use PHPDoc for all public classes, methods, and properties
Document all custom hooks (actions/filters) with docblocks including parameters and types
Files:
admin/class-scans-stats.php
admin/**/*.php
📄 CodeRabbit inference engine (.github/copilot-instructions.md)
Place admin classes and admin-only PHP code in the /admin directory
Files:
admin/class-scans-stats.php
**/class-*.php
📄 CodeRabbit inference engine (.github/copilot-instructions.md)
**/class-*.php: Legacy PHP class files must use WordPress style naming class-class-name.php
Legacy class names use WordPress underscore style (Class_Name_Convention)
Files:
admin/class-scans-stats.php
🧬 Code graph analysis (1)
admin/class-scans-stats.php (1)
admin/class-settings.php (2)
Settings(13-98)get_scannable_post_types(42-71)
🔇 Additional comments (1)
admin/class-scans-stats.php (1)
183-190: Per-rule Issues_Query restricted to scannable post types looks correctConfining the per-rule
Issues_QuerytoSettings::get_scannable_post_types()ensuresrules_failedonly reflects issues on scannable content, which matches how the rest of the stats already scope queries. Using a limit of1is appropriate here since you only care about existence (count() > 0), and should reduce unnecessary query work.
|
I updated this branch with the test changes from after 6.9 release. Test now pass again. I also tested the code here and confirmed that the change does show N/A when there is no issues. I tested it by toggling off all my post types to get the issues cleared out. 
|
2 participants
This pull request updates the scan statistics logic in
admin/class-scans-stats.phpto better handle scannable post types and calculation of passed percentage. The main improvements focus on ensuring that only relevant post types are considered and that the passed percentage is calculated more accurately.Scan statistics improvements:
Issues_Queryinitialization now includes apost_typesparameter set to the result ofSettings::get_scannable_post_types(), ensuring that only scannable post types are queried.passed_percentagenow sets it to'N/A'by default and only computes a percentage if there are scannable post types and scanned posts, preventing misleading statistics when no relevant data is present.Fixes: PRO-265
Summary by CodeRabbit
Release Notes
✏️ Tip: You can customize this high-level summary in your review settings.