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.

Sign up for GitHub

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

Jump to bottom

HREF with reference.content_path in UsageView doesn't do anything #12014

Open
lizriderwilson opened this issue Jun 5, 2024 · 2 comments · May be fixed by #12045
Open

HREF with reference.content_path in UsageView doesn't do anything #12014

lizriderwilson opened this issue Jun 5, 2024 · 2 comments · May be fixed by #12045
Labels
Sprint topic type:Bug

Comments

@lizriderwilson
Copy link

Issue Summary

In the UsageView for a Page or Snippet, the Field column displays a list of fields containing a reference to that object. In references_cell.html, each reference is wrapped in a link to that object's edit view, appended with #content-path-{{ reference.content_path }}. This appears to be meant as a way to jump to that specific field when opening the edit page, but no such ids are present on the elements and so they don't do anything - each link just opens the edit page from the top content, as usual.

Steps to Reproduce

  1. From the edit view for a Page or Snippet, click on the "i" Status icon in the top right and then go to the Usage page (provided there is at least one occurrence)
    image
  2. From the Usage page, click any example under the field column to go to the edit page for that item.
    image
  3. The url for the edit page will end in something like edit/#content-path-body_streamfield.85af2509-0a67-4848-9808-b5f432492258, but no such id exists on the page.
  • I have confirmed that this issue can be reproduced as described on a fresh Wagtail project:
    • Yes. Confirmed on a new install of Bakery demo.

Technical details

  • Python version: 3.11.3
  • Django version: 5.0.3
  • Wagtail version: 6.1.2
  • Browser version: Chrome on Mac v125.0.6422.142

Working on this

Anyone can contribute to this. View our contributing guidelines, add a comment to the issue once you’re ready to start.
@lizriderwilson lizriderwilson added status:Unconfirmed Issue, usually a bug, that has not yet been validated as a confirmed problem. type:Bug labels Jun 5, 2024
@zerolab zerolab removed the status:Unconfirmed Issue, usually a bug, that has not yet been validated as a confirmed problem. label Jun 5, 2024
@zerolab
Copy link
Contributor

zerolab commented Jun 5, 2024 •
edited
Loading

Confirmed. For StreamField block references, for example, the ref path is something like
content-path-body.81e913c4-b95b-4cae-8b91-326fff250bb1 whereas the block id is block-81e913c4-b95b-4cae-8b91-326fff250bb1-section.

For regular fields, ref is something the id in the editor is content-path-FIELDNAME.

This was flagged in #10007

@laymonage
Copy link
Member

This is a tricky problem, because the panel IDs we have in the HTML are generated differently for different BoundPanels:

wagtail/wagtail/admin/templates/wagtailadmin/shared/panel.html

Lines 19 to 20 in 49ef727

{% fragment as prefix %}{% if id_prefix %}{{ id_prefix }}-{% endif %}{{ id }}{% endfragment %}
{% fragment as panel_id %}{{ prefix }}-section{% endfragment %}

wagtail/wagtail/admin/templates/wagtailadmin/panels/object_list.html

Lines 8 to 10 in 49ef727

{% panel id_prefix=self.prefix id=identifier classname=child.classes|join:' ' attrs=child.attrs heading=child.heading heading_size="label" icon=child.icon id_for_label=child.id_for_label is_required=child.is_required %}
{% component child %}
{% endpanel %}

wagtail/wagtail/admin/panels/group.py

Lines 101 to 106 in 49ef727

child.get_bound_panel(
instance=self.instance,
request=self.request,
form=self.form,
prefix=(f"{self.prefix}-child-{identifier}"),
)

wagtail/wagtail/admin/panels/inline_panel.py

Lines 108 to 113 in 49ef727

self.child_edit_handler.get_bound_panel(
instance=subform.instance,
request=self.request,
form=subform,
prefix=("%s-%d" % (self.prefix, index)),
)

wagtail/wagtail/blocks/struct_block.py

Lines 350 to 352 in 49ef727

PlaceholderBoundBlock(
block, value.get(name), prefix=f"{prefix}-{name}"
),

wagtail/client/src/components/StreamField/blocks/BaseSequenceBlock.js

Lines 134 to 136 in 49ef727

const panelId = `block-${id}-section`;
const headingId = `block-${id}-heading`;
const contentId = `block-${id}-content`;

The reference index stores a "content path" to the reference in a given model instance, which is unrelated to how the string for the panel ID is generated. To fix this issue, we need to either:

  • Calculate the correct ID to use as the anchor when linking to the reference
    • I don't think this is possible without traversing the panel tree and following the same code path as how the panel IDs are generated, which can be too complex given that we may be dealing with different model instances when rendering the "Usage" view.
    • Some of the logic for generating the ID exists in client-side code for stuff like StreamField blocks, which aren't fully rendered by the server (they are partially rendered by the client). This is shown in the BaseSequenceBlock.js snippet above.
    • Some inputs don't have a <section> element, e.g. a field in a MultiFieldPanel.
  • Instead of relying on the link to point to the correct ID for the panel, use a smarter (or possibly fuzzy) logic on the client to find the closest panel based on the content path of the reference index. I think all fields have a corresponding data-contentpath attribute where the value is the part that makes up the full content path for the reference index.
    • For example, the content path of the reference index may be something like body.df102372-cd23-463c-b594-29b224bd409e.725285ae-b823-404e-8439-f5ebe3b48b31.text. We can make use of the data-contentpath attribute, I think we can target the appropriate element by using the following selector: 
      '[data-contentpath="body"] [data-contentpath="df102372-cd23-463c-b594-29b224bd409e"] [data-contentpath="725285ae-b823-404e-8439-f5ebe3b48b31"] [data-contentpath="text"]'
      I believe this was the original intention in

      wagtail/wagtail/admin/templates/wagtailadmin/tables/references_cell.html

      Line 6 in 49ef727

      <a href="{{ edit_url }}#content-path-{{ reference.content_path }}">
      but of course it didn't work because you can't use data attributes for # anchors, so this needs some additional logic in the JS.

@laymonage laymonage linked a pull request Jun 13, 2024 that will close this issue
Draft
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Sprint topic type:Bug
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Fix content path links in usage view to scroll to the correct element laymonage/wagtail
3 participants
@zerolab @laymonage @lizriderwilson