🇺🇸United States @Amber Himes Matz

Thanks everyone for clarifying the issue. FYI, I've updated the Drupal CMS docs for SEO Checklist about configuring RobotsTxt with recommendations from the RobotsTxt module's README. The skills and permissions required to complete SEO Checklist module's action items range from basic site administration to developer-level skills, so I don't think it hurts to surface the information provided by RobotsTxt module in the Drupal CMS docs. If anything, it would help a site admin troubleshoot why their changes in the UI for RobotsTxt weren't having any effect.

https://new.drupal.org/docs/drupal-cms/promote/using-seo-checklist-in-dr...

The recommendation in the RobotsTxt module's README is to update the project's composer.json like so:

"extra": {
        "drupal-scaffold": {
            "locations": {
                "web-root": "web/"
            },
            "file-mapping": {
                "[web-root]/robots.txt": false
            }
        },

...To prevent Drupal Scaffold from placing robots.txt in the web root, on installation and update.

Would that be a viable option for Drupal CMS?

Updated IS with current URL to the guide.

I wasn't clear previously that all the URLs should be updated to include the initial "docs" path. This was a change I made after publishing these docs, so there were redirects in place, making it hard to catch, since the links all worked.

I've updated all the URLs with the current URLs, so this should be good to go now. Probably needs one more look by a reviewer to catch any typos.

Added a link to an updated doc about backing up Drupal:  https://www.drupal.org/docs/updating-drupal/how-to-back-up-your-drupal-site →

thejimbirch → credited amber himes matz → .

+1 to this proposal.

I think adding a page to the User Guide that explains what Drupal CMS is (Drupal + themes, modules, and configuration that makes it a more newcomer-friendly starting point) makes sense.

I like the idea of a short standard explanation at the beginning of videos that says something like, "This video uses Drupal CMS as a starting point which means the administrative theme's colors, layout, and menu toolbar will look different from a standard installation of Drupal. You can follow this tutorial using either Drupal 11 or Drupal CMS."

Marking this as complete. A new section in the Drupal CMS User Guide has been created and 4 docs published within it.

Drupal CMS User Guide > Promote content with SEO

1. SEO essentials: what you should know
2. Install and explore SEO Tools in Drupal CMS
3. Customize meta tags for individual pages
4. Using SEO Checklist in Drupal CMS

Thanks! I just saw that a moment too late.

Updated title and issue summary.

I'm not sure how to move this to another project's queue. Could use some help with that.

My perspective is from the documentation writer's point of view. To have to say, "Make sure you don't have any leading or trailing spaces when you enter your GTM ID" in documentation for setting up analytics is weird to me. That just smacks of a programmer's problem, not a user's problem.

Since the Google Tag module is responsible for constructing the string for the script tag's src attribute, maybe this issue would be better filed in their queue instead. And instead of suggestion validation, suggesting trimming leading/trailing whitespace from the tagId variable.

web/modules/contrib/google_tag/js/gtm.js, lines 23-30:

config.tagIds.forEach(function (tagId) {
    const script = document.createElement('script');
    script.async = true;
    const dLink = dl != 'dataLayer' ? `&l=${dl}` : '';
    script.src = `https://www.googletagmanager.com/gtm.js?id=${tagId}${gtm_environment}${dLink}`;
    script.type = 'text/javascript';
    document.getElementsByTagName('head')[0].appendChild(script);
  });

@phenaproxima Ok with me to close as won't fix and I'll file it in the Google Tag module's queue instead.

amber himes matz → created an issue.

Screenshots have been added and I've done a final review. These are now ready for acceptance by the D.A.

For anyone working on this issue, please read carefully the issue summary and my feedback in #9.

I reviewed the diff and it looks good to me. The update module's help hook implementation in src/Hook/UpdateHooks.php already refers to the module as "Update Status" and I didn't find any help topics that refer to the module. So I think this issue could be considered fixed. Thanks, dww!

Crediting @eojthebrave for reviewing these docs. And myself for writing them.

Adding credit for @thejimbirch for his review of these docs. Thanks, Jim!

amber himes matz → created an issue.

Updated the issue summary. Thanks everyone!

smustgrave → credited amber himes matz → .

Encountered this while writing documentation for SEO Checklist for Drupal CMS. Fix looks good; manually tested on a Drupal CMS site. Reapplying the SEO Tools recipe fixes the Configure link under Configure the Redirect 404 module in the Clean URLs section.

I'm editing the launcher doc to frame it as a more extensive trial, replacing words like "Install" with "Try" or "Explore" in the title and in the steps. If/when the doc is placed in the "Get started" section, the title, "Try out Drupal CMS using the desktop app" contrasted with "Install Drupal CMS locally with DDEV" will hopefully make it clear what the different purposes are. Also, the intros to both tutorials reiterate the options (install locally with DDEV, try in a browser, try with the desktop app). And the intro text for the section, "Install Drupal CMS", will be edited to outline each of the options and their purpose. In my opinion, with these edits, the doc for the launcher app can be placed in the "Get started" section.

I've completed editing the launcher doc both for clarity and for grammar and punctuation.

I've also edited the changes to the section doc, "Install Drupal CMS" to make it more clear that using the launcher is another way to try out Drupal CMS more extensively.

Also, I've edited the issue summary to add remaining tasks.

Just some minor grammatical issues:

1. source/en/install-ddev.asciidoc: The title, "Setting Up An Environment with DDEV" should have lowercase "an": Setting Up an Environment with DDEV" to be consistent with the other titles in the guide.
2. source/en/install-ddev.asciidoc : Change "DDEV specific" to "DDEV-specific" in 2 places (line 28 and 169).
3. source/en/install-prepare.asciidoc: Add comma after "provider". Lines 39-41. Change sentence to:

Composer and manual download options; if you chose other options, like a
one-click installer from a hosting provider, consult the relevant documentation
for any additional steps. 

That's all I found. Thank you for making this change. +100 for being opinionated about recommending a specific local development environment. I think it's so much more helpful to newcomers than a "Choose Your Own Adventure from many options" approach.

Adding credit to john_b for when this issue gets worked on, as they opened an issue ( ✨ allow hook_help to run on modules which are not enabled Closed: outdated ) about this idea of displaying help for uninstalled modules, which I closed as outdated, because this issue is more current in terms of the paradigm for help we are now using, e.g. help topics.

I just learned that closed issues (as in the work on the D7 backport which was not committed) now can give credit, even if no work was committed.

So adding credit for @foxtrotcharlie and @star-szr for patches and review work that they did. I hope it's not too late for the credit to be added! Thank you again for your past work on this.

We have a new system for help which is replacing hook_help and that is help topics, which is part of the core help module. There is a newer issue ( ✨ Display links to help topics provided by uninstalled modules Active ) that is framed in terms of help topics and displaying related help topics from uninstalled modules that I think is more relevant. So I'm going to close this issue as outdated and add commit credit over on that issue for when it gets worked on.

I have discussed this issue in the #bugsmash Slack channel, and @catch advised that if this issue was a pure backport issue to D7, it should be marked as closed (outdated), because Drupal 7 is End-Of-Life (EOL).

It does look like this is a pure D7 backport issue, so I am closing this issue as outdated.

Thank you to everyone who worked on this issue.

Updated issue summary with remaining task (add sponsor info), and the links to the published tutorials.

I have copy edited both tutorials and assigned to Lenny at the D.A. for official acceptance. Once she gives the thumbs-up, we'll publish. Hopefully in the next day or two!

Keeping assigned to me, as I will track the acceptance and publish.

We also need to get clarification about the term, "recipes", since that word doesn't appear to be used in the UI anymore. Are we going with "add-on"? I'm confused about this. We should reach out to @pameela -- I know there's been a lot of back-and-forth about this term, but maybe the leadership team has made a decision about it. Once we get direction on the preferred term, we'll need to update tutorials. (We can do a search for the term in our Google doc for the v1 docs to find tutorials that use "recipe".)

amber himes matz → created an issue.

smustgrave → credited amber himes matz → .

@eojthebrave or I will take care of updating the documentation in the Drupal CMS User Guide at the appropriate time. We'll check in with @pameeela about when it should be updated.

@andypost -- Are you looking for a high-level overview of the approach in #53 from a Theme API subsystem maintainer before continuing work on it? Do you want me to ping maintainers in Slack to take a look, or do you want to make any updates to the patch first?

Updated IS with link to Help Topic Standards doc.

Thank you for working on this @martin mayer.

For you, or anyone else working on this, please refer to the proposed resolution in the issue summary as well as the Help Topics Standards → doc.

For help topics, we like to split up topics into "concepts" (usually has "overview" in the title or filename) and "tasks" (step-by-step instructions on how to do a certain task). Which means, we don't want to introduce step-by-step instructions into a concept (aka "overview") topic. But rather, add a task topic with steps, and then link to it from the related concept/overview tutorial.

So for this issue, what we need is an update to the Help module's concept topic (core.config_overview.html.twig) that describes at a high level that it is also possible to install a site from existing configuration, which bypasses the need to discover a site's UUID.

And then we need a new help topic in core/modules/help/help_topics called something like core.config_install.html.twig that has step-by-step instructions on installing an existing site from configuration, including any limitations (such as those described in 🐛 Allow an install hook in profiles installing from configuration Needs work ).

Then in both core.config_overview.html.twig and the new topic, update the related topics to include links to each other.

I realize that there is limited documentation on this task, and that the best (only?) way to accomplish it is through Drush. If that is the case, in an "Additional resources" section, add a link to this User Guide page on additional tools: https://www.drupal.org/docs/user_guide/en/install-tools.html. For any Drush commands, wrap them in HTML <code> tags.

lostcarpark → credited amber himes matz → .

Adding credit for marjose who reported the issue to Drupalize.Me originally.

amber himes matz → created an issue.

eojthebrave → credited amber himes matz → .

Thanks for the update, @eojthebrave! I've reviewed it again and just have some copy edit suggestions.

Also, I just used the GitLab WebIDE to search for links to the deleted file, install-manual, but I'm not sure I trust that 100%. So just wanted to make sure that you searched and removed links to the file you deleted.

Ship it!

I agree that the manual downloading instructions should be removed in favor of using Composer.

I reviewed the MR and caught some typos and commas. After these changes are made, I think this is good to go.

Opened a merge request here: https://git.drupalcode.org/project/user_guide/-/merge_requests/61

amber himes matz → created an issue.

Here's some additional feedback/questions we (Drupalize.Me) received about this tutorial:

Do you need to delete the content type's custom fields first before deleting
the content type? In D7, I think if the custom fields were not deleted first,
they still exist in the database. Not sure if this is taken care of in D8+,
but it would be nice to make that clear regardless.

Just a couple of things. (See comments in GL.) Otherwise looks good. Thanks!

Setting to needs work for the one possible issue. See inline comment in GitLab.

Removed the section at the top of the page about the broken api.drupal.org links, since that site has been updated, and the broken links to classes issue has been resolved. See https://www.drupal.org/project/api/issues/3342815 🐛 Classes missing from Drupal 10 Fixed

larowlan → credited Amber Himes Matz → .

Also, looks like the patch needs rerolling.

Looking at this issue again at DrupalCon at the Bug Smash table.

Looks like a possible intermittent test failure. Re-adding this to the queue.

Looking at this issue again from Bug Smash. There's been no activity for over 1 year since it was marked as Postponed (maintainer needs more info), and could be potentially be closed.

I am certainly no expert on this, but I did do some hunting for other issues related to YamlFileLoader and I learned that:

Portions of this file are a direct copy of
// \Symfony\Component\DependencyInjection\Loader\YamlFileLoader"

And, it seems, looking at other issues related to YamlFileLoader that the consensus is that Drupal's YamlFileLoader should really stay as close as possible to Symfony's. So I'm wondering if this issue should be closed a "won't fix"? Or possibly rolled in as a task with another feature request related to YamlFileLoader? Like ✨ Use native Symfony YamlLoader + Config Needs work maybe?

Adding tag, because it would be helpful to know how to verify this issue.

URLs where a specific version is present as the last path segment are redirecting to a page that appends (not replaces) `11.x` as the last path segment. Which results in a 404 because there are 2 versions in the path.

For example, this URL:

https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Component%21Util...

Redirects to an 11.x search page, with the following message:

Sorry, api/drupal/core%21lib%21Drupal%21Component%21Utility%21Unicode.php/function/Unicode%3A%3Astrlen/8.5.x/11.x cannot be found.

(Notice the “8.5.x/11.x” at the end of the url in the message.)

Keeping at “needs review” to invite other reviews.

This is great! Please create a change record that will help folks update docs and tutorials.

larowlan → credited Amber Himes Matz → .

Thanks all for your participation in the Bug Smash meeting.

Added info about The One to the section, What bugs we’re looking at.

Removed redundant mention of meta issue in Contributor Guide section.

Updated the section on Help Topics with current information on its status, issues, and how to help. Updated the section on the Contributor Guide with links and as current info as I could find. Skimmed the Previous Goals section and made some annotations with regard to status, as far as I know.

Looks like this is fixed. Thanks everyone!

Another missing class: https://api.drupal.org/api/drupal/core!lib!Drupal!Core!Entity!ContentEnt...

I went through all unresolved threads and double-checked that they were resolved, and resolved them.

Updated issue summary’s remaining tasks about adding the optional deriver argument, and crossed it off to show that we’ve completed it.

Updated remaining tasks in issue summary (all tasks done).

This is ready for review.

I've converted the 2 test plugins, EmptyHelpSection and TestHelpSection to use the HelpSection attribute.

And I removed a trailing comma from the last item in the attribute HelpTopicSection. I guess we're not doing trailing commas for last items in these arrays in attributes? Yet, anyway. I think that code standards for these are still pending (that's my current understanding). Regardless, this makes everything consistent and is consistent with the Action example as well.

Thanks @quietone for the reminder! I am working on this now.

Also, I updated the IS with remaining tasks (and those already done).

There was a missing use statement for the HelpSection attribute class in HelpSectionManager.php. Adding this fixed the error on installation (because it fixed the value of the HelpSection::class parameter passed in the parent constructor, which was meaningless without the use Drupal\help\Attribute\HelpSection; statement.

I tested this on a successfully-installed 11.x-dev site and verified that HelpSection plugins displayed as expected on admin/help. Screenshot attached with HelpSection plugins provided by Help module highlighted.

I'm working on this again. When I try to install Drupal 11.x-dev with this code running, the installation is failing with a typehint error in this new code.

TypeError: Drupal\Core\Plugin\Discovery\AnnotatedClassDiscovery::__construct(): Argument #4 ($annotation_namespaces) must be of type array, string given, called in /var/www/html/core/lib/Drupal/Core/Plugin/DefaultPluginManager.php on line 305 in Drupal\Core\Plugin\Discovery\AnnotatedClassDiscovery->__construct() (line 56 of core/lib/Drupal/Core/Plugin/Discovery/AnnotatedClassDiscovery.php).

After fixing this, I will test the HelpSection in the UI to make sure it's working and upload a screenshot of that.

larowlan → credited Amber Himes Matz → .

Thanks for the review, @larowlan! I think I addressed everything, though there was 1 point of confusion about line 29 of core/modules/help/src/Plugin/HelpSection/HelpTopicSection.php, which I asked about in GitLab.

Looks like I missed some coding standards. I'll take a closer look tomorrow if I can. Happy to have help though.

I took a stab at this.

Amber Himes Matz → made their first commit to this issue’s fork.

Updated title to fix typo in "annotations" to ensure issue is discoverable in searches for "annotations".

lostcarpark → credited Amber Himes Matz → .

Adding tag per Gábor's request.

@fjgarlin Is there anything we can do to help hasten the launch of the new API site? Are there any project issues that are blocking it that we could help with? My colleagues and I would welcome opportunities to help, as we have so many API links on Drupalize.Me that are breaking, and we get weekly support messages from our members telling us about the broken URLs. It's a bit of a maintenance pain, as we try to keep the links up to date with the latest version of Drupal, and now I'm having to change some of them back to "9". It's confusing for folks.

We totally get the project priority thing, but if there is a way to help and get the new API site launched, we'd love to know about it.

Hiding patch files, as the MR contains the latest solution.

Amber Himes Matz → created an issue.

Thanks for the clarification, @andypost. This patch adds the patch from #2 (the changes to core/modules/help/tests/src/Kernel/HelpSearchPluginTest.php). Interdiff included.

Ok, I think this is ready for review!

Alright, here's a patch that adds to the one in #3, updating the URL and link text to the Help Topic Standards docs page (without the redirect).

Replaced "Drupal 8" with "Drupal" in several places.

Amber Himes Matz → created an issue.

Updated the IS. Per @andypost in #99 (and I, as co-maintainer, concur), moving some items in the IS that were in the section "Needs discussion" to "Not part of the roadmap".

1. Moved ✨ Do we need hierarchy/order for help topics? Active to the section "Not part of the roadmap".
2. Moved "
3. #3064854: Allow Twig templates to use front matter for metadata support → , and if that is done, #3085972: Replace Drupal\help_topics\FrontMatter with Drupal\Component\Utility\FrontMatter →

" to the section "Not part of the roadmap"

4. Moved 📌 Move testing of help topic rendering into child of GenericModuleTestBase Active to "Not part of the roadmap" as it's not a part of this roadmap, but a child of 🌱 Deprecate hook_help() and combine with Topics Active (per #111

Hopefully the IS now clearly reflects that there are no action items remaining.

A nice workaround could be if help topics could receive a context provided by some service, maybe defining injection in the frontmatter.

I imagine @fgm is not the only one to need this. Sounds like "Allow help topics to get context defined in frontmatter" should be opened as a child issue of this one? @fgm do you want to open the issue, or should I? In either case, I'm interested in more details as to what you are looking for, and if you could provide examples of your modules that use context in their hook_help() implementations. Thank you.

LGTM and credit has been added already, so closing as fixed. Thanks all!

Thank you @quietone for pointing out that this IS is a bit of a hard-to-understand mess. And to @xjm for pointing out the scoping problem. I have updated the title and issue summary as follows:

1. Removed statement about it being postponed, because it is not.
2. Updated title to "Fix up minor copy problems in help topics" since this issue is only focused on copy edits, not content or code errors (scope).
3. Updated issue summary. Moved the original summary down to "Original issue summary section". Organized the IS into template with clear action items and scope, and indicated what has been done.
4. Added referenced issues
5. Added Release notes snippet

Also, just to add additional context and clarification, this issue historically was a sort of meta issue to collect problems. Problems were fixed in other issues or new issues created. This issue is now scoped to minor copy edits related to word usage and consistent link text.

I hope this update makes it easier to review and commit. But feedback is always welcome on how it could be further clarified if clarification is required. Forgive us if we are a bit strained as getting help topics stable has been a long long road.