Skip to content

Add log level threshold for Email Editor #60255

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 3 commits into
base: trunk
Choose a base branch
from

Conversation

yuliyan
Copy link
Contributor

@yuliyan yuliyan commented Aug 7, 2025

Submission Review Guidelines:

Changes proposed in this Pull Request:

  • Add custom log level threshold for Email Editor logging set to WC_Log_Levels::WARNING as default.
  • Add WooCommerce docs for the email editor logging.
  • Fix email editor package logger to use custom log filepath defined in WP_DEBUG_LOG when specified.
  • Fix email editor documentation errors for logging.

Closes WOOPLUG-5003: Review and Refine Logging in the Email Editor.

Screenshots or screen recordings:

N/A

How to test the changes in this Pull Request:

  1. Enable the block-based email editor from WooCommerce → Settings → Advanced → Features → Block Email Editor (alpha)
  2. Make sure Logger is enabled in WooCommerce → Status → Logs → Settings
  3. Inspect the plugin-woocommerce log in WooCommerce → Status → Logs → Browse
  4. It is expected that nothing from the Email Editor below WC_Log_Levels::WARNING is logged.
  5. Modify the log level threshold for the email editor using the woocommerce_email_editor_logging_threshold filter, e.g.:
add_filter( 'woocommerce_email_editor_logging_threshold', function() {
    return WC_Log_Levels::DEBUG;
} );
  1. Refresh the website a few times and open the plugin-woocommerce log again.
  2. It should have logged Debug and Info (since it's higher level compare to WC_Log_Levels::WARNING) entries from the email editor.

Testing that has already taken place:

Changelog entry

  • Automatically create a changelog entry from the details below.
  • This Pull Request does not require a changelog entry. (Comment required below)
Changelog Entry Details

Significance

  • Patch
  • Minor
  • Major

Type

  • Fix - Fixes an existing bug
  • Add - Adds functionality
  • Update - Update existing functionality
  • Dev - Development related task
  • Tweak - A minor adjustment to the codebase
  • Performance - Address performance issues
  • Enhancement - Improvement to existing functionality

Message

Changelog Entry Comment

Comment

Add custom log level threshold for Email Editor logging set to WC_Log_Levels::WARNING as default.

@github-actions github-actions bot added Documentation Issues and PRs related to improving documentation plugin: woocommerce Issues related to the WooCommerce Core plugin. labels Aug 7, 2025
@yuliyan yuliyan changed the title Wooplug 5003 review and refine logging in the email editor Add log level threshold for Email Editor Aug 7, 2025
@yuliyan yuliyan added Ballade Issues related to block-based email editor package: @woocommerce/email-editor issues related to the @woocommerce/email-editor package Emails labels Aug 7, 2025
@yuliyan yuliyan requested a review from eason9487 August 7, 2025 14:26
Copy link
Contributor

github-actions bot commented Aug 7, 2025

Testing Guidelines

Hi @eason9487 @woocommerce/developer-advocacy,

Apart from reviewing the code changes, please make sure to review the testing instructions (Guide) and verify that relevant tests (E2E, Unit, Integration, etc.) have been added or updated as needed.

Reminder: PR reviewers are required to document testing performed. This includes:

  • 🖼️ Screenshots or screen recordings.
  • 📝 List of functionality tested / steps followed.
  • 🌐 Site details (environment attributes such as hosting type, plugins, theme, store size, store age, and relevant settings).
  • 🔍 Any analysis performed, such as assessing potential impacts on environment attributes and other plugins, conducting performance profiling, or using LLM/AI-based analysis.

⚠️ Within the testing details you provide, please ensure that no sensitive information (such as API keys, passwords, user data, etc.) is included in this public issue.

@yuliyan yuliyan force-pushed the wooplug-5003-review-and-refine-logging-in-the-email-editor branch from 4ceefcf to 3828071 Compare August 7, 2025 14:28
@yuliyan yuliyan marked this pull request as ready for review August 7, 2025 15:08
@yuliyan yuliyan requested a review from a team as a code owner August 7, 2025 15:08
Copy link
Contributor

coderabbitai bot commented Aug 7, 2025

📝 Walkthrough

Walkthrough

This change refines the logging system for the WooCommerce Email Editor by introducing a configurable severity threshold, improving log file path handling based on the WP_DEBUG_LOG constant, and updating documentation to reflect these behaviors. The Logger class now filters logs below the set threshold, and related documentation and changelogs have been updated.

Changes

Cohort / File(s) Change Summary
Email Editor Logging Documentation
docs/features/email/email-editor-logging.md
Added documentation describing the email editor logging system, severity threshold configuration, and usage examples.
Email Editor Logger Implementation
plugins/woocommerce/src/Internal/EmailEditor/Logger.php
Refactored Logger to use WC_Log_Levels, introduced a severity threshold filter, and unified log handling through a single method.
Email Editor Logger Log File Handling
packages/php/email-editor/src/Engine/Logger/class-default-email-editor-logger.php
Enhanced constructor logic to support both boolean and string values for the WP_DEBUG_LOG constant, refining log file path assignment.
Email Editor Documentation
packages/php/email-editor/README.md
Expanded log location documentation and corrected logger method naming.
Email Editor Changelogs
packages/php/email-editor/changelog/wooplug-5003-review-and-refine-logging-in-the-email-editor,
plugins/woocommerce/changelog/wooplug-5003-review-and-refine-logging-in-the-email-editor
Updated changelogs to document changes in logging threshold and log file path handling.

Sequence Diagram(s)

sequenceDiagram
    participant Client
    participant Logger
    participant WooCommerceLogger

    Client->>Logger: log(level, message, context)
    Logger->>Logger: should_handle(level)?
    alt Level >= threshold
        Logger->>WooCommerceLogger: log(level, message, context)
    else Level < threshold
        Logger-->>Client: (No action)
    end
Loading

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~15–20 minutes

Note

⚡️ Unit Test Generation is now available in beta!

Learn more here, or try it out under "Finishing Touches" below.

✨ Finishing Touches
  • 📝 Generate Docstrings
🧪 Generate unit tests
  • Create PR with unit tests
  • Post copyable unit tests in a comment
  • Commit unit tests in branch wooplug-5003-review-and-refine-logging-in-the-email-editor

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share
🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

  • Review comments: Directly reply to a review comment made by CodeRabbit. Example:
    • I pushed a fix in commit <commit_id>, please review it.
    • Explain this complex logic.
    • Open a follow-up GitHub issue for this discussion.
  • Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
    • @coderabbitai explain this code block.
  • PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
    • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
    • @coderabbitai read src/utils.ts and explain its main purpose.
    • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.

Support

Need help? Create a ticket on our support page for assistance with any issues or questions.

CodeRabbit Commands (Invoked using PR comments)

  • @coderabbitai pause to pause the reviews on a PR.
  • @coderabbitai resume to resume the paused reviews.
  • @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
  • @coderabbitai full review to do a full review from scratch and review all the files again.
  • @coderabbitai summary to regenerate the summary of the PR.
  • @coderabbitai generate docstrings to generate docstrings for this PR.
  • @coderabbitai generate sequence diagram to generate a sequence diagram of the changes in this PR.
  • @coderabbitai generate unit tests to generate unit tests for this PR.
  • @coderabbitai resolve resolve all the CodeRabbit review comments.
  • @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
  • @coderabbitai help to get help.

Other keywords and placeholders

  • Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
  • Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
  • Add @coderabbitai anywhere in the PR title to generate the title automatically.

Documentation and Community

  • Visit our Documentation for detailed information on how to use CodeRabbit.
  • Join our Discord Community to get help, request features, and share feedback.
  • Follow us on X/Twitter for updates and announcements.

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

🧹 Nitpick comments (1)
packages/php/email-editor/src/Engine/Logger/class-default-email-editor-logger.php (1)

39-49: Enhanced WP_DEBUG_LOG handling looks good with a minor security suggestion.

The improved logic properly handles different types of WP_DEBUG_LOG values and is more explicit about the behavior in each case. This aligns well with the updated documentation.

Consider adding path validation for the string case to guard against potentially dangerous inputs:

} elseif ( is_string( WP_DEBUG_LOG ) && ! empty( WP_DEBUG_LOG ) ) {
-				$this->log_file = WP_DEBUG_LOG;
+				// Validate the path to prevent potential security issues
+				$sanitized_path = realpath( dirname( WP_DEBUG_LOG ) );
+				if ( $sanitized_path && is_writable( $sanitized_path ) ) {
+					$this->log_file = WP_DEBUG_LOG;
+				} else {
+					$this->log_file = '';
+				}

This would ensure the directory exists and is writable before attempting to use the custom path.

📜 Review details

Configuration used: .coderabbit.yml
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 0aa1eb3 and 3828071.

📒 Files selected for processing (6)
  • docs/features/email/email-editor-logging.md (1 hunks)
  • packages/php/email-editor/README.md (2 hunks)
  • packages/php/email-editor/changelog/wooplug-5003-review-and-refine-logging-in-the-email-editor (1 hunks)
  • packages/php/email-editor/src/Engine/Logger/class-default-email-editor-logger.php (1 hunks)
  • plugins/woocommerce/changelog/wooplug-5003-review-and-refine-logging-in-the-email-editor (1 hunks)
  • plugins/woocommerce/src/Internal/EmailEditor/Logger.php (11 hunks)
🧰 Additional context used
📓 Path-based instructions (2)
**/*.{php,js,jsx,ts,tsx}

📄 CodeRabbit Inference Engine (.cursor/rules/code-quality.mdc)

**/*.{php,js,jsx,ts,tsx}: Guard against unexpected inputs
Sanitize and validate any potentially dangerous inputs
Ensure code is backwards compatible
Write code that is readable and intuitive
Ensure code has unit or E2E tests where applicable

Files:

  • packages/php/email-editor/src/Engine/Logger/class-default-email-editor-logger.php
  • plugins/woocommerce/src/Internal/EmailEditor/Logger.php
**/*.{php,js,ts,jsx,tsx}

⚙️ CodeRabbit Configuration File

**/*.{php,js,ts,jsx,tsx}: Don't trust that extension developers will follow the best practices, make sure the code:

  • Guards against unexpected inputs.
  • Sanitizes and validates any potentially dangerous inputs.
  • Is backwards compatible.
  • Is readable and intuitive.
  • Has unit or E2E tests where applicable.

Files:

  • packages/php/email-editor/src/Engine/Logger/class-default-email-editor-logger.php
  • plugins/woocommerce/src/Internal/EmailEditor/Logger.php
🧠 Learnings (7)
📓 Common learnings
Learnt from: jorgeatorres
PR: woocommerce/woocommerce#59675
File: .github/workflows/release-bump-as-requirement.yml:48-65
Timestamp: 2025-07-15T15:39:21.856Z
Learning: In WooCommerce core repository, changelog entries for all PRs live in `plugins/woocommerce/changelog/` directory and are processed during releases, not at the repository root level.
Learnt from: triple0t
PR: woocommerce/woocommerce#59186
File: packages/js/email-editor/src/store/initial-state.ts:9-10
Timestamp: 2025-06-26T12:13:32.062Z
Learning: In WooCommerce email editor store initialization (packages/js/email-editor/src/store/initial-state.ts), the current_post_id and current_post_type from window.WooCommerceEmailEditor are required parameters that should cause explicit errors if missing, rather than using fallback values or optional chaining. The design preference is to fail fast when critical initialization data is unavailable.
Learnt from: CR
PR: woocommerce/woocommerce#0
File: .cursor/rules/generate-pr-description.mdc:0-0
Timestamp: 2025-07-21T05:22:46.426Z
Learning: Provide clear, step-by-step instructions for how to test the changes in the PR description.
Learnt from: NeosinneR
PR: woocommerce/woocommerce#0
File: :0-0
Timestamp: 2025-06-26T14:25:08.421Z
Learning: In WooCommerce transactional emails, product images have historically had display issues due to lazy loading attributes being applied, which email clients cannot process since they don't execute JavaScript. This issue existed in both old and new email templates, but became more visible with the new email template system. The fix involves preventing lazy loading on attachment images specifically during email generation by adding skip classes and data attributes.
Learnt from: prettyboymp
PR: woocommerce/woocommerce#59048
File: .github/workflows/cherry-pick-milestoned-prs.yml:60-83
Timestamp: 2025-06-26T12:45:40.709Z
Learning: WooCommerce uses WordPress versioning conventions where minor versions in X.Y.Z format are constrained to 0-9 (Y cannot exceed 9). This means version increment logic should reset minor to 0 and increment major when minor reaches 9, rather than allowing two-digit minor versions like 9.10 or 9.11.
Learnt from: jorgeatorres
PR: woocommerce/woocommerce#60250
File: .github/workflows/release-compile-changelog.yml:165-166
Timestamp: 2025-08-07T10:34:27.702Z
Learning: In WooCommerce release workflows, the VERSION variable used in changelog generation comes from the `validate-selected-branch-version` step, which extracts the version from `plugins/woocommerce/woocommerce.php` using `grep -oP '(?<=Version: )(.+)'` and validates it matches the input version. This ensures the version is always in the correct format by the time it reaches the changelog generation step, making additional error handling for version format validation unnecessary.
📚 Learning: in woocommerce core repository, changelog entries for all prs live in `plugins/woocommerce/changelog...
Learnt from: jorgeatorres
PR: woocommerce/woocommerce#59675
File: .github/workflows/release-bump-as-requirement.yml:48-65
Timestamp: 2025-07-15T15:39:21.856Z
Learning: In WooCommerce core repository, changelog entries for all PRs live in `plugins/woocommerce/changelog/` directory and are processed during releases, not at the repository root level.

Applied to files:

  • packages/php/email-editor/changelog/wooplug-5003-review-and-refine-logging-in-the-email-editor
  • plugins/woocommerce/changelog/wooplug-5003-review-and-refine-logging-in-the-email-editor
  • packages/php/email-editor/README.md
📚 Learning: in woocommerce email editor store initialization (packages/js/email-editor/src/store/initial-state.t...
Learnt from: triple0t
PR: woocommerce/woocommerce#59186
File: packages/js/email-editor/src/store/initial-state.ts:9-10
Timestamp: 2025-06-26T12:13:32.062Z
Learning: In WooCommerce email editor store initialization (packages/js/email-editor/src/store/initial-state.ts), the current_post_id and current_post_type from window.WooCommerceEmailEditor are required parameters that should cause explicit errors if missing, rather than using fallback values or optional chaining. The design preference is to fail fast when critical initialization data is unavailable.

Applied to files:

  • packages/php/email-editor/changelog/wooplug-5003-review-and-refine-logging-in-the-email-editor
  • docs/features/email/email-editor-logging.md
  • plugins/woocommerce/changelog/wooplug-5003-review-and-refine-logging-in-the-email-editor
  • plugins/woocommerce/src/Internal/EmailEditor/Logger.php
📚 Learning: in woocommerce release workflows, the version variable used in changelog generation comes from the `...
Learnt from: jorgeatorres
PR: woocommerce/woocommerce#60250
File: .github/workflows/release-compile-changelog.yml:165-166
Timestamp: 2025-08-07T10:34:27.702Z
Learning: In WooCommerce release workflows, the VERSION variable used in changelog generation comes from the `validate-selected-branch-version` step, which extracts the version from `plugins/woocommerce/woocommerce.php` using `grep -oP '(?<=Version: )(.+)'` and validates it matches the input version. This ensures the version is always in the correct format by the time it reaches the changelog generation step, making additional error handling for version format validation unnecessary.

Applied to files:

  • packages/php/email-editor/changelog/wooplug-5003-review-and-refine-logging-in-the-email-editor
  • plugins/woocommerce/changelog/wooplug-5003-review-and-refine-logging-in-the-email-editor
📚 Learning: in woocommerce transactional emails, product images have historically had display issues due to lazy...
Learnt from: NeosinneR
PR: woocommerce/woocommerce#0
File: :0-0
Timestamp: 2025-06-26T14:25:08.421Z
Learning: In WooCommerce transactional emails, product images have historically had display issues due to lazy loading attributes being applied, which email clients cannot process since they don't execute JavaScript. This issue existed in both old and new email templates, but became more visible with the new email template system. The fix involves preventing lazy loading on attachment images specifically during email generation by adding skip classes and data attributes.

Applied to files:

  • docs/features/email/email-editor-logging.md
  • plugins/woocommerce/changelog/wooplug-5003-review-and-refine-logging-in-the-email-editor
📚 Learning: woocommerce uses wordpress versioning conventions where minor versions in x.y.z format are constrain...
Learnt from: prettyboymp
PR: woocommerce/woocommerce#59048
File: .github/workflows/cherry-pick-milestoned-prs.yml:60-83
Timestamp: 2025-06-26T12:45:40.709Z
Learning: WooCommerce uses WordPress versioning conventions where minor versions in X.Y.Z format are constrained to 0-9 (Y cannot exceed 9). This means version increment logic should reset minor to 0 and increment major when minor reaches 9, rather than allowing two-digit minor versions like 9.10 or 9.11.

Applied to files:

  • plugins/woocommerce/changelog/wooplug-5003-review-and-refine-logging-in-the-email-editor
📚 Learning: the core/spacer block in the woocommerce email editor intentionally does not have a dedicated render...
Learnt from: lysyjan
PR: woocommerce/woocommerce#59070
File: packages/php/email-editor/src/Integrations/Core/class-initializer.php:103-141
Timestamp: 2025-06-23T16:55:58.246Z
Learning: The core/spacer block in the WooCommerce email editor intentionally does not have a dedicated renderer class and is handled by the fallback renderer instead of having an explicit render_email_callback assigned in the switch statement.

Applied to files:

  • plugins/woocommerce/src/Internal/EmailEditor/Logger.php
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
  • GitHub Check: build
🔇 Additional comments (8)
plugins/woocommerce/changelog/wooplug-5003-review-and-refine-logging-in-the-email-editor (1)

1-4: LGTM! Changelog entry follows WooCommerce conventions.

The changelog entry is properly formatted and accurately describes the addition of the custom log level threshold feature for Email Editor logging.

packages/php/email-editor/changelog/wooplug-5003-review-and-refine-logging-in-the-email-editor (1)

1-4: LGTM! Appropriate changelog entry for the logging fix.

The changelog accurately describes the fix to respect custom log file paths defined in WP_DEBUG_LOG. The "fix" type is appropriate for this behavioral improvement.

packages/php/email-editor/README.md (2)

129-133: Excellent documentation of WP_DEBUG_LOG behavior.

The detailed explanation of how different WP_DEBUG_LOG values affect logging behavior is clear and helpful for developers. This aligns well with the improved constructor logic in the logger class.


155-155: Good catch on the method name correction.

Correcting the method name from set_delegate_logger() to set_logger() ensures accuracy in the documentation.

docs/features/email/email-editor-logging.md (1)

1-18: Excellent documentation for the new logging threshold feature.

This documentation clearly explains the severity threshold concept and provides a practical code example. The reference to the main WooCommerce logging documentation is helpful for developers who need more detailed information about log levels.

plugins/woocommerce/src/Internal/EmailEditor/Logger.php (3)

13-13: LGTM! Good use of WooCommerce constants.

Using WC_Log_Levels constants improves type safety and consistency across the logging system.


64-64: Excellent refactoring to centralize logging logic.

Converting all log level methods to delegate to the centralized log() method with proper constants is a great improvement. This eliminates code duplication, ensures consistent threshold handling, and improves maintainability while preserving backwards compatibility.

Also applies to: 75-75, 86-86, 97-97, 108-108, 119-119, 130-130, 141-141


153-155: LGTM! Clean implementation of threshold filtering.

The conditional logging based on should_handle() correctly implements the threshold filtering while maintaining backwards compatibility. The logic is clear and efficient.

Copy link
Contributor

github-actions bot commented Aug 7, 2025

Test using WordPress Playground

The changes in this pull request can be previewed and tested using a WordPress Playground instance.
WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser.

Test this pull request with WordPress Playground.

Note that this URL is valid for 30 days from when this comment was last updated. You can update it by closing/reopening the PR or pushing a new commit.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Ballade Issues related to block-based email editor Documentation Issues and PRs related to improving documentation Emails package: @woocommerce/email-editor issues related to the @woocommerce/email-editor package plugin: woocommerce Issues related to the WooCommerce Core plugin.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants