Closed (fixed)
Project:
Project Wiki
Version:
1.x-dev
Component:
Code
Priority:
Minor
Category:
Task
Assigned:
Reporter:
Created:
2 Oct 2024 at 14:10 UTC
Updated:
6 May 2026 at 10:30 UTC
Jump to comment: Most recent, Most recent file
We already print title_suffix and the entity attributes, but contextual links are not present in the wiki overview.
This is especially important to have edit links in the overview.
If we can't provide contextual links for technical reasons, we should provide custom edit links.
https://www.drupal.org/docs/drupal-apis/menu-api/providing-module-define...
| Comment | File | Size | Author |
|---|
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #2
thomas.frobieterComment #5
lrwebks commentedComment #6
anybodyDon't waste too much time here, this isn't really important. Skip it, if it and leave as-is, if it takes more than 15min.
Comment #7
anybody@thomas.frobieter still missing, any ideas how to fix?
Comment #8
lrwebks commentedWe are already rendering the entity in full view mode, so I am unsure why the contextual links are not added automatically.
Maybe we need to add content_attributes?
Comment #9
thomas.frobieterI don't have anything else to add. The template is correct. See, for example:
https://api.drupal.org/api/drupal/core%21modules%21block%21templates%21b...
oder
https://api.drupal.org/api/drupal/core%21modules%21node%21templates%21no...
On the output side, a 'contextual-region' class should be added automatically through attributes (not content_attributes). And title_suffix should print the contextual menu:
Comment #10
thomas.frobieterComment #11
anybody@thomas.frobieter then it sounds like it's not worth it? Maybe we'll find the reason and resultion one day?
Comment #12
thomas.frobieterMaybe, but we should add a custom 'Edit' button. At the moment, you have to go to the entry details page and click on the 'Edit' tab, which is a bit annoying.
So I'll take over.
Comment #13
lrwebks commentedI think I get what's the problem here. It's not a semantic one, since even after manually adding the
contextual-regionclass via twig does not make anything appear even though the contextual library is properly loaded on the page.The actual issue is that we in fact are not actually rendering a real entity here, despite it looking like that. Even though we discussed it before (“it's rendered in full view mode”, etc.) that is not what is happening. The controller asks the plugin manager to gather all wiki entries from all providers, meaning both markdown and content entities. And to turn both types into a compatible format we convert them both to
ProjectWikiValueObjects via their plugin definitions. These value objects are not Drupal entities though but rather simple PHP classes. So it is clear that the contextual links library does not think of the rendered output as a place to attach links to even though thecontextualclass is there. It simply does not know what to do with it.So I do not see a feasible way to implement this. Either we try for something like a
links.contextual.ymlwhich could be really cumbersome to get it to work specifically for content entries, or we find out what makes the contextual links library think that some rendered content is a content entity.Comment #14
lrwebks commentedComment #15
anybodylinks.contextual.ymlwould be too much.We either find a way to render it "regularly" somehow or build a workaround for content entities for now.
@thomas.frobieter this is what copilot says:
https://copilot.microsoft.com/shares/WkTEFtXmdrfzbs2x3Ca31
So maybe we're just missing
{{ title_suffix }}?Comment #16
thomas.frobieterNo. See #9. I'll add the custom edit link (if user has permission 'administer project_wiki_entity_content').
Comment #17
lrwebks commented@thomas.frobieter, do you have a way to discern what kind of entry (markdown or content) is rendered in twig? Or should I add a parameter for you?
Comment #18
thomas.frobieterDone. It's already been tested and the link and permission check are working well.
Comment #19
anybodyComment #20
thomas.frobieterGood point. I forgot about the Markdown entries, let me check this..
Comment #21
thomas.frobieterWe already have: provider string (29) "project_wiki_markdown_content", this should do it!
Comment #22
lrwebks commentedGlad that thinking ahead pays out at least sometimes, even if three years later... :D
Comment #24
thomas.frobieter