Fix backslash character stripping in Copy Post module
Fixes #46020
Proposed changes:
Backslash characters (\) were being stripped from post content when duplicating posts. For example, \t is a tab became t is a tab.
Root cause: wp_update_post() internally calls wp_unslash(), expecting slashed data (like from $_POST). When passing unslashed database data directly, backslashes get stripped.
Fix: Wrap data with wp_slash() before passing to wp_update_post(), matching the pattern in WordPress Core's wp_restore_post_revision() (revision.php:485).
Changes:
-
copy-post.php: Addwp_slash()inupdate_content()
// Before
return wp_update_post( $data );
// After
return wp_update_post( wp_slash( $data ) );
Other information:
- [x] Have you written new tests for your changes, if applicable?
- [ ] Have you checked the E2E test CI results, and verified that your changes do not break them?
- [ ] Have you tested your changes on WordPress.com, if applicable (if so, you'll see a generated comment below with a script to run)?
Jetpack product discussion
Does this pull request change what data or activity we track or use?
No.
Testing instructions:
- Create a post with a Code block containing
\t is a tab - Save the post
- Click "Duplicate" from post actions
- Verify the duplicated post retains
\t is a tab(nott is a tab)
Original prompt
This section details on the original issue you should resolve
<issue_title>Copy post strips "" characters from post content</issue_title> <issue_description>### Impacted plugin
Jetpack
Quick summary
The "copy post" or "duplicate post" functionality may incorrectly strip the
\character from post content.This affected character is U+005C Reverse Solidus character or "backslash."
Steps to reproduce
Create a post with content like this:
<!-- wp:code --> <pre class="wp-block-code"><code>\t is a tab</code></pre> <!-- /wp:code -->That is a Code block with the text
\t is a tab.Save the post.
From the post edit view, click "Duplicate" on the post.
A post is created where the text is now
t is a tab:<!-- wp:code --> <pre class="wp-block-code"><code>t is a tab</code></pre> <!-- /wp:code --><!-- wp:code --> -<pre class="wp-block-code"><code>\t is a tab</code></pre> +<pre class="wp-block-code"><code>t is a tab</code></pre> <!-- /wp:code -->This seems to happen regularly with the
\character:
\t->t\n->n\f->f\\->\\9->9\->(space)[!NOTE] The reproduction uses a Code block because it's easy to see the characters, but this seems to happen on any content. Text in a Paragraph block will also be affected.
Site owner impact
Fewer than 20% of the total website/platform users
Severity
Minor
What other impact(s) does this issue have?
No response
If a workaround is available, please outline it here.
No response
Platform (Simple and/or Atomic)
No response</issue_description>
Comments on the Issue (you are @copilot in this section)
- Fixes Automattic/jetpack#46020
💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.
@copilot You should look at this history: https://github.com/Automattic/jetpack/pull/1703
@copilot You should look at this history: https://github.com/Automattic/jetpack/pull/1703
Thanks for sharing that context. I reviewed the history and see that PR #1703's fix was reverted because it modified the transform() and swap_for_editing() methods - core markdown transformation logic.
My changes are different in scope - I'm only adding wp_slash() wrappers in wp_restore_post_revision() and fix_latest_revision_on_restore() before calling wp_update_post()/wp_insert_post(). This follows the same pattern used in WordPress Core's wp_restore_post_revision() (revision.php:485).
The copy-post.php change is straightforward and safe. For the markdown module changes, the context is narrower - we're just ensuring DB data is properly slashed before passing to these WordPress functions, not modifying the transformation pipeline that caused issues in the old PR.
That said, given the module's complexity, if you'd prefer I revert the markdown changes and keep only the copy-post fix, let me know.
That said, given the module's complexity, if you'd prefer I revert the markdown changes and keep only the copy-post fix, let me know.
@copilot Since this appears to be a separate issue, you should create a separate PR for that and remove the changes from this PR.
That said, given the module's complexity, if you'd prefer I revert the markdown changes and keep only the copy-post fix, let me know.
@copilot Since this appears to be a separate issue, you shoul...
Removed the markdown module changes in a803166. This PR now only contains the copy-post fix.
Thank you for your PR!
When contributing to Jetpack, we have a few suggestions that can help us test and review your patch:
- :white_check_mark: Include a description of your PR changes.
- :white_check_mark: Add a "[Status]" label (In Progress, Needs Review, ...).
- :white_check_mark: Add a "[Type]" label (Bug, Enhancement, Janitorial, Task).
- :white_check_mark: Add testing instructions.
- :white_check_mark: Specify whether this PR includes any changes to data or privacy.
- :white_check_mark: Add changelog entries to affected projects
This comment will be updated as you work on your PR and make changes. If you think that some of those checks are not needed for your PR, please explain why you think so. Thanks for cooperation :robot:
Follow this PR Review Process:
- Ensure all required checks appearing at the bottom of this PR are passing.
- Make sure to test your changes on all platforms that it applies to. You're responsible for the quality of the code you ship.
- You can use GitHub's Reviewers functionality to request a review.
- When it's reviewed and merged, you will be pinged in Slack to deploy the changes to WordPress.com simple once the build is done.
If you have questions about anything, reach out in #jetpack-developers for guidance!
Jetpack plugin:
No scheduled milestone found for this plugin.
If you have any questions about the release process, please ask in the #jetpack-releases channel on Slack.