Skip to content
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

Expanding the contents of the details panel when viewing a page #48482

Closed
jameskoster opened this issue Feb 27, 2023 · 5 comments · Fixed by #48650
Closed

Expanding the contents of the details panel when viewing a page #48482

jameskoster opened this issue Feb 27, 2023 · 5 comments · Fixed by #48650
Assignees
Labels
[Feature] Site Editor Related to the overarching Site Editor (formerly "full site editing")

Comments

@jameskoster
Copy link
Contributor

When you navigate to a Page in the Site Editor here's what you see:

Screenshot 2023-02-27 at 13 25 19

In the future it will be nice to have a UI for making high-level page edits in the dark sidebar. In the interim it would be good to at least include the page URL (most likely as an actual link):

Screenshot 2023-02-27 at 13 30 07

We should also tidy up the spacing / alignment, but it's probably okay for that to be a separate effort.

@jameskoster jameskoster added Needs Dev Ready for, and needs developer efforts [Feature] Site Editor Related to the overarching Site Editor (formerly "full site editing") labels Feb 27, 2023
@richtabor
Copy link
Member

(most likely as an actual link)

Are you thinking an ExternalLink?

@jeryj
Copy link
Contributor

jeryj commented Mar 1, 2023

Update: I misunderstood which area of the site editor we were talking about. I thought it was Site Editor -> Templates -> Page template, not Site Editor -> Navigation -> Page List -> Individual Page.


I'm feeling stuck on this issue, as I can't find an easy way to identify which page is assigned to the template.

tl;dr: Templates don't care about what posts/pages/etc are using them, so there isn't a way to easily access which page is referenced from this template. And without knowing which page is being used in the template, we don't know which link to use. It would be technically possible to find it, but in the current architecture, this would be a very expensive operation. To do this efficiently, it would take a change in core, and likely not a small one.

Also, there's a very real chance that I'm wrong here and someone will chime in with "Oh, just use X function."

Sorry for the long post — I wanted to document my research since it did take awhile do debug this and it was too much to keep in my head all at once 😅

How I investigated this since this is my first time looking at templates

I started at the template edit screen javascript to see if there was a reference to the page that is using the template. I had thought since the page title was referenced in the template title (for example, in this issue screenshot, "Sample Page"), it would mean it was referencing the Sample Page itself. And if we have access to the page title, we probably have access to the page. Easy!

However, it is getting the "Sample Page" title from the template title in the database, not the original page. When a custom template is created for a page, it sets the title for that template as the page it came from so they'll match. Similarly, if you update the original post/page that created the template, it will also update the custom template name to match the updated name. This is set in the database for the template custom post type, not by referencing the page. So, the "Sample Page" in this issue screenshot isn't the Sample Page title, it's the template title named "Sample Page."

Note: I still need to debug how the template title is kept up-to-date with the page title, likely using the save_post or like hook. I'm curious if there's some faster way of identifying the template by page that I'm unaware of.

Since I wasn't making progress on how to identify a page by the template, I tried figuring out how a page identifies its template. If it was quick enough, maybe we could just search all pages and return the template. For example, I see that there's a request already returning some info about the pages in this editor screen. If that meta info included or could include the template ID it was using, then we could quickly locate it without making additional requests.

However, this would be quite an expensive query with the current architecture as there is no stored relationship between a page and its custom template.

When a page is being edited, to identify the template it uses, it runs through resolve_block_template(), which looks through all possible templates for this page and return the one with the highest priority match. We'd have to do this for every page, checking every template until we had our match, which would be quite expensive.

Why I don't think we should do a change in core to address this

So, the issue is we don't have a quick reference between the page and template IDs. I had thought maybe we could store some meta info for the template, like, this template will always use x page, so store the post_id in the post_meta table for that template to make this faster to lookup. But I think this would be ill-advised since templates work by priority not by a direct association.

Templates work by viewing all possible sources a template could come from and be valid for that page/post, then selecting the one with the highest priority. For example, an about page could use a file within the theme named:

  • page.php
  • about-page.php
  • page-${post_id}.php
  • or the custom template post-type (what's being used for the templates in this issue).

And if it's a child theme, it also checks these same things within the parent theme. So, it was never built to have a 1:1 relationship of a template to a page, but in our custom templates, it forces a 1:1 relationship in some instances by being more and more specific about the theme (this custom template post type will have the highest priority when checking for which template to apply). But it still has to go through all the steps to locate the page (get the page info, sort through all potential templates, reorder them by best match, return the best match).

To do all of this to access the page related to the custom post here would be quite expensive, so I think it's best to close this issue unless it was the start of a large overhaul of the template editor or blocking a future design direction that needs to get solved. If this issue was intended to be an easy win, unfortunately, it isn't at the moment unless I'm missing something (very possible). 😕

@jameskoster
Copy link
Contributor Author

I'm feeling stuck on this issue, as I can't find an easy way to identify which page is assigned to the template.

Forgive a potentially silly question, why do we need to identify that assignation here? This issue is purely about querying the relevant page and displaying the URL.

@jeryj
Copy link
Contributor

jeryj commented Mar 1, 2023

Forgive a potentially silly question, why do we need to identify that assignation here?

No worries! I thought this issue would be much simpler than it is, so I'm still holding out for something obvious I was overlooking to come up, so please keep asking!

This issue is purely about querying the relevant page and displaying the URL.

Agreed! Unfortunately, that is what's difficult to do. There isn't a non-expensive way of identifying the page and URL from only having the template info.

@scruffian
Copy link
Contributor

Here's an idea: #48650

@github-project-automation github-project-automation bot moved this from 📥 Todo to ✅ Done in WordPress 6.2 Editor Tasks Mar 2, 2023
@priethor priethor removed the [Status] In Progress Tracking issues with work in progress label May 17, 2023
@priethor priethor removed the Needs Dev Ready for, and needs developer efforts label Jul 24, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Feature] Site Editor Related to the overarching Site Editor (formerly "full site editing")
Projects
No open projects
Development

Successfully merging a pull request may close this issue.

5 participants