-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
Iframed editor: Fix relative wp-content URLs #66751
Conversation
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the Unlinked AccountsThe following contributors have not linked their GitHub and WordPress.org accounts: @tambourine-man, @Pat-Relentless, @nicolasleroy. Contributors, please read how to link your accounts to ensure your work is properly credited in WordPress releases. If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.
To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
Size Change: +83 B (0%) Total Size: 1.82 MB
ℹ️ View Unchanged
|
@@ -272,6 +272,7 @@ function Iframe( { | |||
<html> | |||
<head> | |||
<meta charset="utf-8"> | |||
<base href="${ window.location.origin }"> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this work, regardless of how the site is configured (top level, sub folder, ...) and also for third-party block editors?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This shouldn't matter for relative urls starting with /
, they should always use the root.
But for relative urls that don't start with a slash it's trickier. We'd have always use the current post URL etc. This wouldn't work without an iframe either (in the admin), so not sure if it's worth fixing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds good!
Btw I just tested this manually setting an image block's URL. |
I trust you'll understand that I've removed the This is because we are now past the final public RC and any further changes targeting the main 6.7 release need to be discussed and approved by a release lead. Looking at the PR it's unclear to me whether this is a bug introduced during the Beta/RC period or something that's been present for a while. If it's a longstanding bug then in the interests of stability I'd vote to defer this to 6.7.1. Update: I noticed the Issue refers to WordPress 6.3 so this seems to be a longstanding bug. Pinging @colorful-tones @ndiego @kevin940726 for confidence check as I may have missed something critical. Also it looks like the PR needs a rebase against |
@getdave As of WordPress 6.3, the Post Editor is iframed if all registered blocks have a Block API version 3 or higher and no traditional metaboxes are registered. With WordPress 6.7 the editor is iframed also with metaboxes active: So we have a problem after the update. Some of our sites are no longer editable in wp-admin. There is no filter or anything to disable it. We need to add a block with API V2 to get an editor that works with relative URLs again. It's not a new bug, but it will now be visible to more users after the update to WordPress 6.7. |
Given the release's timing and the fact that this issue is not unique to 6.7, I would be inclined to punt to 6.7.1.
That said, I agree that this will likely impact many more people now that the Editor is iframed, even when metaboxes are active. To reduce the impact on users and developers, I recommend we try and include this in 6.7. |
I'm afraid I didn't understand the impact of the original Issue until a few moments ago. Given the potential scope I'd also be inclined to include. I see activity from @ellatrix and @youknowriad. How confident are you in this fix landing 6.7? |
It would have been good if the impact was included in the PR or issue description. Fwiw, I think this is safe. It will only affect relative URLs in the block canvas of links and resources. WordPress doesn't even normally use relative links. |
The failure is legit. This breaks the footnote back links, which are relative has urls. Since the So either we fix all links, or we only fix relative hash links. In both cases we'd have to intercept clicks on anchors tags in the iframe. |
@getdave At this part of the release cycle, only bug fixes for regressions introduced in-cycle can be included so this will need to wait until WP 6.8. |
With 6.6 it works. After the 6.7 update, all images in the backend are broken. I think that it should at least be included in 6.7.1. But perhaps we should wait and see whether we are a special case or whether it is a problem for other people. |
@peterwilsoncc Thanks for jumping in here. There's been some disagreement and discussion above about whether or not to try and include this, but yes this was an issue outside of the Beta / RC so on balance I think I stick by my original analysis - do not include in 6.7. I don't see any reason why we can't move to 6.7.1 though, unless there are some rules around what can be included in those point releases that I'm not aware of. |
Unlinked contributors: tambourine-man, Pat-Relentless, nicolasleroy. Co-authored-by: Soean <[email protected]> Co-authored-by: youknowriad <[email protected]> Co-authored-by: ellatrix <[email protected]> Co-authored-by: getdave <[email protected]> Co-authored-by: cweiske <[email protected]> Co-authored-by: peterwilsoncc <[email protected]>
I noticed a minor error with the fix - #68024. |
What?
Adds a
<base>
element to the iframed editor to work with relative URLs.Fixes #54262
Rebase of #56533
Why?
Currently the editor in the iframe does not work with relative URLs.
Relative URLs work in the editor without iframe, where the media are loaded relative to the admin URL. The element restores the old behavior. In further iterations, we can make the editor even more flexible so that it can also work with other URLs.
Testing Instructions