Make WordPress Core

Opened 20 years ago

Closed 20 years ago

Last modified 5 months ago

#6 closed defect (bug) (fixed)

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

Reported by: anonymousbugger's profile anonymousbugger Owned by: ryan's profile ryan
Milestone: Priority: normal
Severity: minor Version:
Component: Template Keywords: has-patch has-unit-tests
Focuses: Cc:

Description

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.

Change History (46)

#2 @ryan
20 years ago

  • Owner changed from anonymous to rboren
  • Status changed from new to assigned

#3 @ryan
20 years ago

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

#4 @TechGnome
20 years ago

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

#5 @ryan
20 years ago

  • Resolution changed from 10 to 20
  • Status changed from assigned to closed

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.

This ticket was mentioned in PR #2500 on WordPress/wordpress-develop by ramonjd.


2 years ago
#7

  • Keywords has-patch has-unit-tests added

🚧 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:

Trac ticket: TBD

gziolo commented on PR #2500:


2 years ago
#8

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

aaronrobertshaw commented on PR #2500:


2 years ago
#9

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.

gziolo commented on PR #2500:


2 years ago
#10

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.

ramonjd commented on PR #2500:


2 years ago
#11

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

anton-vlasenko commented on PR #2500:


2 years ago
#13

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

anton-vlasenko commented on PR #2500:


2 years ago
#14

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

This ticket was mentioned in PR #2531 on WordPress/wordpress-develop by jsnajdr.


2 years ago
#15

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.

This ticket was mentioned in PR #3411 on WordPress/wordpress-develop by oandregal.


19 months ago
#17

## 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.

oandregal commented on PR #3411:


19 months ago
#18

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?

dream-encode commented on PR #3411:


19 months ago
#19

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

oandregal commented on PR #3411:


19 months ago
#20

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

This ticket was mentioned in PR #3946 on WordPress/wordpress-develop by @jorgefilipecosta.


15 months ago
#22

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.

@jorgefilipecosta commented on PR #3946:


15 months ago
#23

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

@mukesh27 commented on PR #3946:


15 months ago
#24

Thanks @jorgefilipecosta I can't my name in props

@jorgefilipecosta commented on PR #3946:


15 months ago
#25

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!

This ticket was mentioned in PR #4097 on WordPress/wordpress-develop by @oandregal.


14 months ago
#26

## 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.

https://i0.wp.com/user-images.githubusercontent.com/583546/219651244-4310263d-a116-4e51-b481-c517360b748a.png

## 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 |
| --- | --- |
| https://i0.wp.com/user-images.githubusercontent.com/583546/219652222-2aca88ad-c4b4-4d6f-9b3f-707df626711e.png | https://i0.wp.com/user-images.githubusercontent.com/583546/219652291-3c1f3246-4ac4-49f8-a087-50949f21b48b.png |

  • 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).

#27 @oandregal
14 months ago

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.

@oandregal commented on PR #4097:


14 months ago
#28

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

@oandregal commented on PR #4097:


13 months ago
#29

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% |

@youknowriad commented on PR #4097:


13 months ago
#30

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

@oandregal commented on PR #4097:


12 months ago
#31

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.

@flixos90 commented on PR #4097:


12 months ago
#32

@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 commented on PR #4097:


12 months ago
#33

@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.

@flixos90 commented on PR #4097:


12 months ago
#34

@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 :)

@oandregal commented on PR #4097:


9 months ago
#36

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

This ticket was mentioned in PR #5505 on WordPress/wordpress-develop by @kafleg.


6 months ago
#38

Update version, tested upto, changelog and CSS version

@kafleg commented on PR #5505:


6 months ago
#39

@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?

@sabernhardt commented on PR #5505:


6 months ago
#40

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

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.

@kafleg commented on PR #5505:


6 months ago
#41

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

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?

@sabernhardt commented on PR #5505:


6 months ago
#42

@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.

@desrosj commented on PR #5505:


6 months ago
#43

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.

@sabernhardt commented on PR #5505:


6 months ago
#44

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

@desrosj commented on PR #5505:


5 months ago
#45

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!

@desrosj commented on PR #5505:


5 months ago
#46

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!

Note: See TracTickets for help on using tickets.