the_excerpt() on non-excerpt posts doesn't stripslashes

[anonymousbugger]

In trying to use the th_excerpt() function of WP, I noticed that my tick marks were still escaped. The key to this is that there was no excerpt entered for the posts.
Review of the code revealed that if there is an excerpt, it gets stripslashes, but when there is no exceprt, it attempts to use the post content. The check for empty excerpt isn't done until after the call to stripslashes. this means that when the content is used, it doesn't go through the stripslashes, causing them to show in the "faked" excerpt.

[ryan]

I cannot reproduce this with CVS. stripslashes should not be necessary. We'll be removing almost every call to stripslashes sometime soon. Posts saved with older versions of Wordpress had double slashes added to them. These old posts will show up with slashes. A script to strip extra slashes present in old posts is in the works.

edited on: 06-11-04 11:00

[TechGnome]

I guess I should have mentioned that I am using 1.2 Mingus...
Ok, if it's fixed in the CVS, I'll grab that file and see if the problem persists. The note about older versions of WP probably holds true for my case too. Ahhhh the joys of development.

TG

[ryan]

Resolving. There isn't really one file that will fix this. The changes are widespread. I'll create a separate bug to track the problem with extra slashes in old posts.

🚧 Adding this diff pending discussion.

This diff migrates block support spacing and associated tests from Gutenberg 12.9.0 to WordPress 6.0

The goal is to include the latest plugin, while skipping the Style Engine integration. The Style Engine class doesn't bring any new functionality - it's more of a first iteration in a set of long-term changes.

In summary:

• Include individual serialization changes from ​https://github.com/WordPress/gutenberg/commit/6de16981c7fef3db7cc4a9d6cfcb0ad85c916c62
• Skip Style Engine integration from ​https://github.com/WordPress/gutenberg/commit/44925a947fde29feaab512e0adf4291272209d59`

Trac ticket: TBD

We already have a Trac ticket https://core.trac.wordpress.org/ticket/55505 that @hellofromtonya opened for all backporting necessary for the Gutenberg plugin.

The block support serialization changes included in this PR so far (all except layout.php) look good and cover those introduced in ​https://github.com/WordPress/gutenberg/pull/36293.

I'm happy to review again once the layout.php updates are also added.

I'm happy to review again once the layout.php updates are also added.

This patch looks big already. Can we land that part separately? I could do some additional review pass in 1-2 hours and commit changes if no blockers discovered.

This patch looks big already. Can we land that part separately? I could do some additional review pass in 1-2 hours and commit changes if no blockers discovered.

Layout over here: ​https://github.com/WordPress/wordpress-develop/pull/2518

Committed with https://core.trac.wordpress.org/changeset/53076.

Please disregard my code review as I haven't noticed that the task is closed 🤦

Please disregard my code review as I haven't noticed that the PR is closed 🤦

Changes the REST endpoints that get preloaded when displaying a page for post, site and widgets editor, so that they are in sync with what the latest version of Gutenberg to be shipped with Core 6.0 really requests.

This patch finished backport of the ​`gutenberg_optimize_preload_paths` filter in Gutenberg, and that filter can be removed after this is merged.

Post Editor
The types and taxonomies requests have context changed from edit to view, because these requests were modified in ​https://github.com/WordPress/gutenberg/pull/37685.

Adding two new preloads: list of reusable blocks (wp_block post type, loaded from /wp/v2/blocks) and permissions for creating pages (OPTIONS /wp/v2/pages). Both requests are made in the useBlockEditorSettings hook, at the top of the post editor React tree.

Site Editor
Like in Post Editor, modify the types request context from edit to view.

The taxonomies preload, together with four other ones, can be removed because the Site Editor doesn't request that data.

Site Editor also doesn't need to preload /wp/v2/settings. These are used only in specialized blocks like Site Title, and by the useTitle hook which is by no means on critical path.

Widgets Editor
Adds a preload for the /wp/v2/widget-types endpoint requested by the registerLegacyWidgetVariations called during initialization.

Committed with https://core.trac.wordpress.org/changeset/53094.

## What

This PR fixes an issue by which the styles of cite element declared via theme.json are not enqueued.

## Why

All element's styles should work.

## How

By registering the element into the proper allowed list array.

## Test

• Add the following snippet to your theme's theme.json (I've tested with TwentyTwentyTwo):

{{{json
{

"elements": {

"cite": {

"color": {

"background": "hotpink"

}

}

}

}
}}}

• Go to the post editor and add a quote block. Fill it with text and a cite.

The expected result is that in the editors and the frontend the cite of the quote should have hotpink as background color.

## Notes

Note this works as expected with the Gutenberg plugin active but not in core without the plugin because ​it's part of the registry.

The failures all stem from the same issue:

Error: Can't use 'tar -xzf' extract archive file: /home/runner/work/_actions/_temp_32a0853a-9104-4759-ba7c-68850ae844d4/ee071250-5379-4bec-b7ae-dc7e0befd324.tar.gz. return code: 2.

According to the ​tar manual, this is because it could not process the file. Perhaps because there was some issue and wasn't downloaded properly? I can't re-run the tests, which should probably fix this. Can anybody help with this?

@oandregal I re-ran the failed jobs, and they are OK now.

@dream-encode Thanks for that. I still see one failure for ​this job.

Committed at ​https://github.com/WordPress/wordpress-develop/commit/f3c0f743b373c2cae4239b3dd05b7d429067c37e.

Backports ​https://github.com/WordPress/gutenberg/pull/45814 into the core.

## Testing
I pasted the following sample pattern on lib/compat/wordpress-6.2/block-patterns.php.

register_block_pattern(
	'query/template-type-test',
	array(
		'title'      => __( 'Template type test', 'gutenberg' ),
		'templateTypes' => array( '404' ),
		'content'    => '
						<p class="has-text-align-center has-x-large-font-size">404</p>
						',
	)
);

I opened the post editor and the developer tools and pasted wp.apiFetch( { path: '/wp/v2/block-patterns/patterns' } ).then( console.log ); on the browser console.
I verified that the API response for included query/template-type-test include 404 in the templateTypes.

Thank you for the feedback @mukeshpanchal27 it was applied. Committed at ​https://github.com/WordPress/wordpress-develop/commit/620760e1c173aeddf31d313eb790248031287456.

Thanks @jorgefilipecosta I can't my name in props

Thanks @jorgefilipecosta I can't see my name in props

Hi @mukeshpanchal27, sorry for missing your name on the commit message I had an issue while formatting the message, but as referred in slack, your name was manually added to the props of the CPT on the system we use for props and should be accounted for in any stats. Thank you for the feedback!

## What

This PR improves the performance of block template resolution.

## Why

In a production-like environment, it provides a two-digit improvement for themes with block templates: +15% for TwentyTwentyThree and +25% for TwentyTwentyTwo.

This change does not affect themes that don't have block templates. The variance reported for classic themes can be ignored (lower than 1ms), and should be attributed to the variance of the doing the tests: template resolution is unaffected for classic themes, given they ​bail early if they don't support block templates.

## How

The get_block_templates function is responsible to find block templates that match a given search. The function is provided a query parameter that is used to find the relevant user templates (database) and theme templates (file directory). The query parameter includes data such the slugs of the templates or the areas of the template parts.

I've found that the get_block_templates retrieves and processes ​all block templates provided by the theme, to later ​ignore the ones that don't match the given slug.

This function can be more performant if it only retrieves/processes the templates that match a given slug, instead of them all.

The following profile shows the impact of this modification:

| Before | After |
| --- | --- |
| | |

• The time it takes as measured by XDebug profiler: 55ms (before) vs 27ms (after).
• The number of times the _build_block_template_result_from_file is called: 22 (before) vs 5 (after).

## How to test

• Start the bundled environment.
• Set .env to production by applying the following patch:

{{{diff
diff --git a/.env b/.env
index 63a8169f64..9b1d52ac50 100644
--- a/.env
+++ b/.env
@@ -54,10 +54,10 @@ LOCAL_DB_TYPE=mysql

LOCAL_DB_VERSION=5.7

# The debug settings to add to wp-config.php.

-LOCAL_WP_DEBUG=true
-LOCAL_WP_DEBUG_LOG=true
-LOCAL_WP_DEBUG_DISPLAY=true
-LOCAL_SCRIPT_DEBUG=true
+LOCAL_WP_DEBUG=false
+LOCAL_WP_DEBUG_LOG=false
+LOCAL_WP_DEBUG_DISPLAY=false
+LOCAL_SCRIPT_DEBUG=false

LOCAL_WP_ENVIRONMENT_TYPE=local

# The URL to use when running e2e tests.

}}}

• Run 100 test of the homepage: seq 100 | xargs -Iz curl -o /dev/null -H 'Cache-Control: no-cache' -s -w "%{time_starttransfer}\n" http://localhost:8889 | xclip -selection clipboard.
• Copy the results to a spreadsheet like ​this one to measure the changes.

## TODO

• $fits_slug_query can be probably removed.
• Review whether the area can be filtered earlier as well.
• Decide whether this should be prepared for Gutenberg first. I submitted it for core because it modifies functions that are no longer there:
  • _get_block_templates_files: no longer present.
  • get_block_templates: the corresponding gutenberg_get_block_templates is ​still present, but it'll be removed once WordPress 6.2 is published. It won't be present in Gutenberg when this PR lands (WordPress 6.3 cycle).

[oandregal]

I don't know why ​https://github.com/WordPress/wordpress-develop/pull/4097 has been matched to this ticket, since it refers to https://core.trac.wordpress.org/ticket/57756. It's definitely unrelated.

ok, this is now ready to review :) cc @youknowriad @ockham @creativecoder @carlomanf as people who has worked in this area, according to ​https://github.com/WordPress/wordpress-develop/pull/1267

The ​perf job reports the following (copy/pasted here in a single table, otherwise it's difficult to compare the results):

• Home classic theme

| Metric | This PR | Base | Variance |
| --- | --- | --- | --- |
| wpBeforeTemplate | 24.32 | 25.33 | +3.98% |
| wpTemplate | 50.67 | 56.97 | +11.05% |
| wpTotal | 75.28 | 80.32 | +6.25% |

• Home block theme

| Metric | This PR | Base | Variance |
| --- | --- | --- | --- |
| wpBeforeTemplate | 28.33 | 31.80 | +10.91% |
| wpTemplate | 53.37 | 71.39 | +25.24% |
| wpTotal | 81.34 | 102.74 | +20.82% |

Can't talk about the performance impact but this looks great to me. Thanks for the updates @oandregal

Thanks @oandregal for the changes. Can you share updated performance number?

I've rebased this upon trunk in preparation for commiting, and updated the issue description with the numbers reported by the perf CI job.

@oandregal How did you get the numbers from the perf CI job? I'm asking since they only really run for trunk commits as far as I know. Did you trigger it yourself and look at the workflow run logs? The fact that classic themes see a notable improvement strikes me as potentially incorrect, since the change here should only affect block themes like you're saying.

@oandregal How did you get the numbers from the perf CI job? I'm asking since they only really run for trunk commits as far as I know. Did you trigger it yourself and look at the workflow run logs?

:thinking:

Oh. I looked at the ​performance CI job that ran for this PR. My understanding was that the numbers under "Print performance test results" was this PR and the numbers under "Print base line test results" was the baseline to compare to. Is that how should I look at them @felixarntz ?

The first time I ran my own numbers they were on the same range that the CI job, so I didn't bother doing my own again. Happy to if I'm reading this wrong.

The fact that classic themes see a notable improvement strikes me as potentially incorrect, since the change here should only affect block themes like you're saying.

Yeah, I don't understand this either. I presumed it was related to the variability of the tests.

@oandregal

Oh. I looked at the ​performance CI job that ran for this PR. My understanding was that the numbers under "Print performance test results" was this PR and the numbers under "Print base line test results" was the baseline to compare to. Is that how should I look at them @felixarntz ?

Ah that may be a misunderstanding and slightly confusing. The "base line test results" are not the current stats for trunk, but rather a re-run of getting metrics for trunk in the same baseline state that was originally measured (which I believe we have set to the last commit hash of WP 6.1.1). So this isn't the state of latest trunk.

Looking at the printed "performance test results" is a great idea though. What you need to compare that too though is the similar data for the last commit in trunk that is in your branch here.

All of that is of course not how this should work, but to be fair the performance CI workflow in its current stage was not yet meant to be used to assess PRs. Reporting diffs between the last commit in the branch and the PR automatically in a PR comment is high on the todo-list though :)

This has been committed at https://core.trac.wordpress.org/changeset/55687

This has created an issue with child themes, see instructions at ​https://github.com/WordPress/gutenberg/issues/53138 I'm looking into this.

Fix at ​https://github.com/WordPress/wordpress-develop/pull/4940

Update version, tested upto, changelog and CSS version

@sabernhardt I found small versioning issue in 2019 theme.

The current version of theme in org is 2.5 but I found that the version 2.6 is already released according to readme file and mentioned version, ​https://codex.wordpress.org/Twenty_Nineteen_Theme_Changelog#Version_2.6

Would you please give a look on it?

All 13 themes were updated in August. However, half of them are a version behind that at ​wordpress.org/themes.

• ​Twenty Sixteen
• ​Twenty Seventeen
• ​Twenty Nineteen
• ​Twenty Twenty
• ​Twenty Twenty-One
• ​Twenty Twenty-Two

Also note that Twenty Twenty _might_ still have a version 2.4 this month and then 2.5 with the other themes in November (Trac 59576). The special effort of a separate update becomes less valuable each day, though.

All 13 themes were updated in August. However, half of them are a version behind that at ​wordpress.org/themes.

• ​Twenty Sixteen
• ​Twenty Seventeen
• ​Twenty Nineteen
• ​Twenty Twenty
• ​Twenty Twenty-One
• ​Twenty Twenty-Two

Also note that Twenty Twenty _might_ still have a version 2.4 this month and then 2.5 with the other themes in November (Trac 59576). The special effort of a separate update becomes less valuable each day, though.

What can I do in this case? Can i update the theme version based on the trunk version?

@desrosj should be involved in this conversation too. My advice would be to continue updating the version according to trunk.

I would like to know whether Twenty Twenty will have a separate version to fix the iframe editor background color (which was backported to 6.3). If we delay the change three more weeks instead, I could close 59576 as a duplicate of 58832 and change the milestone on 59086 to 6.4. My patch for Twenty Twenty does not (yet) update the "Tested up to" version, but that might be almost as appropriate if released this week as it would be November 7.

Thanks all for working on this!

I've gone back and tried to find a reason why those themes were not uploaded on 6.3 release day and I couldn't find any. I have gone back and uploaded the updates for all of those that were missing in the state that they were on release day. This includes Twenty Twenty without the iframe changes.

I think it's best to just include the iframe change in 2 weeks with the WP 6.4 coordinated release, which will now be 2.4.

I still need to give a true review to this PR, but wanted to update my progress so far. Will circle back in the next 48 hours to do that, though I think there may be a few updates that need to be added for Twenty Twenty now as well.

I made a new ​PR 5601 that includes Twenty Nineteen to Twenty Twenty-Three, plus it corrects the changelog link for Twenty Twenty-Four.

This was handled in https://core.trac.wordpress.org/changeset/57069. I missed this connected PR when committing but @kafleg I've manually added you as a contributor to the change, though!

This was handled in https://core.trac.wordpress.org/changeset/57069. I missed this connected PR when committing but @kafleg I've manually added you as a contributor to the change, though!

Trac ticket:

Merged in https://core.trac.wordpress.org/changeset/59221.