- Issue created by @Gábor Hojtsy
- 🇪🇸Spain fjgarlin
We can create the block plugin here, like these two: https://git.drupalcode.org/project/drupalorg/-/tree/1.0.x/src/Plugin/Blo...
Then we'll worry about how to place it.
Right now we are in an interim situation where the content of the new site is managed by a small group of people, so probably the link should go to this issue queue and then we can triage and redirect from here.
- 🇺🇸United States drumm NY, US
We’ll want to port the “How to improve this page” block from documentation pages like https://www.drupal.org/docs/getting-started/system-requirements/web-serv... →
First we should port it without functionality changes, so regular documentation pages will be set up correctly. Drupal CMS documentation is an exception, so after the basics are done, adjustments should be made. For example, there will not be general edit or commenting (discuss) access for these pages.
Some notes from when I’ve discussed this before:
The D7 version has Discuss, which is regular node comments moved to a separate local task page, which we'll want for regular documentation. For the CMS documentation section & pages, we'll want to make sure comments are off and this block has logic to detect that. We're somewhat building this backwards since the CMS documentation's special cases should be built on top of the base documentation functionality, which we should keep mostly as-is.
I hadn't looked into how this was done in D7 yet, that we might want to change. Its a View, with a field formatter for all the text https://git.drupalcode.org/project/drupalorg/-/blob/089409007720bc9009d6...
So changing the text based on logged in status, edit access, comment status, doesn't happen. We could put in some all-or-nothing checks with Views filters or block visibility rules, but anything with different versions of the text would get messy in Views.The equivalent on D7, https://www.drupal.org/docs/user_guide/en/index.html → is imported, looks like it has the block hidden when there's a field set that indicates it was imported. And there's a different block that shows in the footer.
I'm thinking it would be best to have this all in one block, so it gets placed once, consistently. We can get as far as possible with logic in custom code, that works for normal documentation pages. If we need something additionally special for the CMS guide, we can add logic to check for the page being in that guide.
- First commit to issue fork.