PCH Performance Stats: Show stats for posts with a trackable status #2893
Conversation
📝 WalkthroughWalkthroughThe changes in this pull request involve enhancements to the Parsely tracking functionality within a WordPress environment. A new optional property, Changes
Assessment against linked issues
Possibly related PRs
Suggested labels
Suggested reviewers
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
Documentation and Community
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Outside diff range and nitpick comments (3)
src/@types/assets/window.d.ts (1)
35-35: Add JSDoc documentation for the new property.
The new property should be documented with a JSDoc comment explaining its purpose and structure.
Add the following documentation above the property:
+ /**
+ * Array of WordPress post statuses that should be tracked by Parse.ly.
+ *
+ * This array contains post statuses (e.g., 'publish', 'future') for which
+ * Parse.ly analytics should be collected and displayed in the Performance panel.
+ *
+ * @since 3.14.0
+ */
wpParselyTrackableStatuses: string[];src/content-helper/editor-sidebar/class-editor-sidebar.php (1)
173-180: LGTM! Consider improving the comment documentation.
The implementation correctly injects trackable statuses for the frontend. However, the comment could be more descriptive about its purpose.
Consider updating the comment to be more descriptive:
-// Inject the trackable statuses.
+// Inject the trackable post statuses to enable performance stats for posts with custom statuses.src/content-helper/editor-sidebar/performance-stats/provider.ts (1)
61-66: Enhance comment and add defensive coding.
While the implementation correctly handles trackable statuses, consider these improvements:
- Enhance the comment to better explain the purpose:
-// Get the current post's status.
+// Get the current post's status and check if it's trackable according to wp_parsely_trackable_statuses filter.- Add defensive coding for window object:
-const trackableStatuses = window.wpParselyTrackableStatuses ?? [ 'publish' ];
+const trackableStatuses = typeof window !== 'undefined' && window.wpParselyTrackableStatuses ?
+ window.wpParselyTrackableStatuses : [ 'publish' ];📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
⛔ Files ignored due to path filters (2)
build/content-helper/editor-sidebar.asset.phpis excluded by!build/**build/content-helper/editor-sidebar.jsis excluded by!build/**
📒 Files selected for processing (4)
- src/@types/assets/window.d.ts (1 hunks)
- src/class-parsely.php (2 hunks)
- src/content-helper/editor-sidebar/class-editor-sidebar.php (1 hunks)
- src/content-helper/editor-sidebar/performance-stats/provider.ts (2 hunks)
🧰 Additional context used
📓 Path-based instructions (4)
src/@types/assets/window.d.ts (1)
Pattern **/*.{js,ts,tsx,jsx}: "Perform a detailed review of the provided code with following key aspects in mind:
- Review the code to ensure it is well-structured and adheres to best practices.
- Verify compliance with WordPress coding standards.
- Ensure the code is well-documented.
- Check for security vulnerabilities and confirm the code is secure.
- Optimize the code for performance, removing any unnecessary elements.
- Validate JSDoc comments for accuracy, currency, and adherence to WordPress coding standards.
- Ensure each line comment concludes with a period.
- Confirm every JSDoc comment includes a @SInCE tag indicating the next version of the plugin to include the code.
- Guarantee compatibility with the latest version of WordPress, avoiding deprecated functions or features."
src/class-parsely.php (1)
Pattern **/*.{html,php}: "Perform a detailed review of the provided code with following key aspects in mind:
- Review the HTML and PHP code to ensure it is well-structured and adheres to best practices.
- Ensure the code follows WordPress coding standards and is well-documented.
- Confirm the code is secure and free from vulnerabilities.
- Optimize the code for performance, removing any unnecessary elements.
- Validate comments for accuracy, currency, and adherence to WordPress coding standards.
- Ensure each line comment concludes with a period.
- Verify code compatibility with the latest version of WordPress, avoiding deprecated functions or features."
src/content-helper/editor-sidebar/class-editor-sidebar.php (1)
Pattern **/*.{html,php}: "Perform a detailed review of the provided code with following key aspects in mind:
- Review the HTML and PHP code to ensure it is well-structured and adheres to best practices.
- Ensure the code follows WordPress coding standards and is well-documented.
- Confirm the code is secure and free from vulnerabilities.
- Optimize the code for performance, removing any unnecessary elements.
- Validate comments for accuracy, currency, and adherence to WordPress coding standards.
- Ensure each line comment concludes with a period.
- Verify code compatibility with the latest version of WordPress, avoiding deprecated functions or features."
src/content-helper/editor-sidebar/performance-stats/provider.ts (1)
Pattern **/*.{js,ts,tsx,jsx}: "Perform a detailed review of the provided code with following key aspects in mind:
- Review the code to ensure it is well-structured and adheres to best practices.
- Verify compliance with WordPress coding standards.
- Ensure the code is well-documented.
- Check for security vulnerabilities and confirm the code is secure.
- Optimize the code for performance, removing any unnecessary elements.
- Validate JSDoc comments for accuracy, currency, and adherence to WordPress coding standards.
- Ensure each line comment concludes with a period.
- Confirm every JSDoc comment includes a @SInCE tag indicating the next version of the plugin to include the code.
- Guarantee compatibility with the latest version of WordPress, avoiding deprecated functions or features."
🔇 Additional comments (5)
src/@types/assets/window.d.ts (1)
35-35: Verify consistent usage of the new property.
Let's ensure the property name is consistently used across the codebase.
✅ Verification successful
Based on the shell script results, I can now generate the final response:
Property wpParselyTrackableStatuses is consistently integrated across the codebase
The property is:
- Correctly defined in TypeScript definitions (
window.d.ts) - Properly initialized in
editor-sidebar.phpusing theget_trackable_statuses()method - Consistently used in the frontend code (
performance-stats/provider.ts) - Well integrated with WordPress's filter system via
wp_parsely_trackable_statuses
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify consistent usage of wpParselyTrackableStatuses across the codebase
# Test 1: Check for any variations in property name usage
echo "Checking for property name consistency..."
rg -i "parsely.*trackable.*status" --type ts --type php
# Test 2: Verify initialization of the property
echo "Checking property initialization..."
rg "wpParselyTrackableStatuses\s*=" --type php
Length of output: 7960
src/content-helper/editor-sidebar/class-editor-sidebar.php (1)
168-168: LGTM! Explicit window scope improves code clarity.
The change to use window. prefix for the global variable is a good practice as it makes the scope explicit and prevents potential naming conflicts.
src/content-helper/editor-sidebar/performance-stats/provider.ts (1)
65-66: Verify handling of "future" status posts.
The current implementation should handle "future" posts if they're included in wpParselyTrackableStatuses, but let's verify this assumption:
✅ Verification successful
Implementation properly handles "future" post status
The implementation correctly supports "future" posts through the wp_parsely_trackable_statuses filter. The code:
- Defines default trackable status as 'publish'
- Allows custom statuses (including 'future') via the filter
- Properly checks current post status against trackable statuses
- Provides documentation for adding custom statuses
The current implementation in performance-stats/provider.ts will work with "future" posts as long as 'future' is added to trackable statuses through the WordPress filter.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify if "future" status is properly handled in the codebase
# Check if "future" status is included in trackable statuses
rg -l "future.*wp_parsely_trackable_statuses"
# Check for any special handling of future posts
ast-grep --pattern 'future.*status'
Length of output: 85
Script:
#!/bin/bash
# Let's try a broader search to understand trackable statuses implementation
# Check for trackable statuses definition and usage
rg -A 5 "trackableStatuses"
# Check for status-related configurations
rg -l "wp_parsely_trackable_statuses"
# Look for filter implementations
ast-grep --pattern 'apply_filters($$$wp_parsely_trackable_statuses$$$)'
# Check test files for future status handling
fd -e test.php -e spec.php -e test.ts -e spec.ts | xargs rg "future.*status"
Length of output: 1327
Script:
#!/bin/bash
# Let's check the specific files that define trackable statuses
# Check settings page implementation
cat src/UI/class-settings-page.php | grep -A 10 "trackable_statuses"
# Check parsely class implementation
cat src/class-parsely.php | grep -A 10 "trackable_statuses"
# Check changelog for related changes
cat CHANGELOG.md | grep -A 5 "trackable_statuses"
Length of output: 2346
src/class-parsely.php (2)
235-259: LGTM! Well-structured method extraction.
The new get_trackable_statuses method is well-documented and follows WordPress coding standards. The extraction of the filter logic into a separate method improves code maintainability and reusability.
423-424: LGTM! Clean implementation using the new method.
The modification successfully integrates the new get_trackable_statuses method while maintaining the existing caching mechanism. This change supports the PR's objective of handling custom trackable statuses.
acicovic
changed the title
Description
The WP Parse.ly plugin offers a filter -
wp_parsely_trackable_statuses- that allows defining custom post status that shall be tracked by Parse.ly. On the other hand, the PCH Performance panel does not respect this filter, and will not show stats unless the post is actually published (with thepublishstatus).This PR changes that behaviour, so if the post has any of the statuses set by
wp_parsely_trackable_statuses, it will attempt to show the performance stats for that post.I also changed slightly the text when the post has 0 views, so it shows the post title instead of the post ID, as seen on the screenshot.
Motivation and context
How has this been tested?
Tested locally and validated that posts with a trackable status try to fetch performance stats from Parse.ly
Screenshots (if appropriate)
Summary by CodeRabbit
New Features
Windowinterface.Editor_Sidebarto inject new trackable statuses into the frontend.Bug Fixes
Refactor