🇳🇴Norway @hansfn

Approving / adding to menu since I suspect the AI maintainer won't be notified.

This page is already planned (batch) deleted as part of #3442307: Decide what to do with 'Tutorials and site recipes' → .

I could starting deleting single pages, but ...

PS! And on top of this we have #2762837: Migrate documentation into the new system → .

Approving / adding to menu.

Moving to correct guide and approving / adding to menu.

Deleted.

Approve / add to menu. Add link to project page.

Yeah, I missed canonical. It seems to explain the decent search results for Symfony.

The bad search results are more serious when moving between versions is hard.

No, we should list older versions and redirecting isn't very user-friendly if you need to read the old docs.

We need to fix the issue with bad search results in another way. We probably need to use "current" or something.

By the way, this is the docs list from our friends at Symfony:

Could we ask them what they have done? It doesn't seem to be robots-related - neither robots.txt or robots header explains this:

Google search: intitle:"The HttpKernel+Component" site:symfony.com

But anyway, would you say it's almost certainly a mime mail problem?

No, not necessarily, it could also be that Views Sends is trying to set another sender. But Mime Mail is old ...

We just sent Drupal password reset mail from this system/domain and that got a 10/10

Switch the system mails to ‘Mime Mail’ via the ‘mailsystem’ and see if you still get 10/10.

Sorry for putting all the testing on you, but currently I don't use the module in production myself. I only test it using DDEV (and mailhog).

Thanks for the report. I'm familiar with SPF and DKIM. Which mailing sending module do you use?

This module doesn't really handle the mail sending part - it's left for the mail sending module that your site is using. Have you checked that normal Drupal messages works (with the same mailing sending module)? If so, I'm happy to investigate if the misconfiguration is in Views Send.

Trying to add to menu.

apaderno → credited hansfn → .

Reading your experience with migrating the Organic Groups documentation, I remember that I had the same experience long time ago (when we started migrating stuff). It is too much work for us to handle. I suggest:

1. For guides that cover modules with D7 release, we create a critical issue (in the corresponding project issue queue) saying something like:
   1. To preserve existing module documentation in the the old site building guide, you (the maintainer) have to migrate the content within [a date or a duration]. If the documentation isn't migrated withing the deadline, it will be deleted to enable migrating drupal.org off D7.
   2. Then in the issue description, tips for migration could be inserted - like creating the D7 docs guide first, so you have some where to migrate the content. It makes sense that the maintainer creates the new doc guide, so the ownership is correct.
   3. Finally, we could ask for an update of the documentation URL on the project page. (To get a name instead of an URL displayed, you need to select a doc guide from the new system.)
2. For guides that cover modules without a D7 release, we mass delete - please, drumm

Removed redirect and readded as 404 redirect

Added redirect from node/2971258

Automated message: (to be deleted) guide deleted. Moving its content one level up in the documentation hierarchy.

Hi, jacobdgm! The only thing that is needed is some kind soul to verify your account which I just did. Please feel free to fix the issues you discovered.

Yes, making the command shorter is nice. Since the checkout command also reports which branch it switches to, no information is lost.

Putting the link into the text.

Automated message: temporarily deleted guide deleted. Moving its content one level up in the documentation hierarchy.

Automated message: temporarily deleted guide deleted. Moving its content one level up in the documentation hierarchy.

Thanks for the commit. It does solve the reported problem since there are more than 100 modules with documentation. However, this will look ugly for themes for a long time. I think I would have preferred a smaller number :D

Anyway, I can create a new general issue for large generated TOCs. The very long scroll for contributed themes isn't very user-friendly or nice on the desktop either.

LGTM :-)

Yes, .node-type-guide .top-right-content #contributed-module-documentation should do, but it breaks if the parent guide changes name from "Contributed module documentation" to say "Contributed modules" (following the IA for themes → ).

Trying to improve headers (so automatic TOC displays nicely).

Thank you for the interest (and first MR). I don't think this is sufficient since you break the placements of TOCs.
Random example:

https://fjgarlin-drupal.dev.devdrupal.org/community/contributor-guide
https://www.drupal.org/community/contributor-guide →

If we want to move it, we probably have to do it only for the module documentation.

I think a better and more robust solution is to make the TOC for module documentation a (searchable) dropdown. Even if you get it at the bottom (as you did) it is useless for navigation ...

Another simpler solution is just to hide / remove the TOC when you are on the start page for the top level doc guide for a module. If you want to see all modules you can use the bread crumbs to move one level up where all doc guides are listed anyway.

Just adding duplicate issue as related.

This has annoyed me for a long time. Duplicate of 📌 Display of module documentation on mobile Fixed .

PS! Your "movie" is of course better than my text only issue.

Then the obvious question is: Why isn't it listed on the Drush page? Do you automatically get all this info if migrating / upgrade with Drush? If not, ...

Regarding "human readable language for severity". 1) The error from Drush is rather clear. You are able to modify the command. Using just a number like 4 requires that you explain what 4 means. 2) That Drush doesn't handle English (source code language) in addition to to the language of the site, is IMO a bug. We shouldn't discuss this further here, but maybe you have time to file a bug report? 

The main harm is duplicating information. Couldn't you just link to the relevant section of the Drush page? (I'm just assuming it's already listed on the Drush page?) In addition, I think we should try to keep the pages focused ;-)

Regarding, the command: Isn't it better to use --severity-min=Warning and so on instead of numbers? And "To include warnings, use --severity-min=4" sounds wrong - aren't you excluding Notice and lower?

To me it feels strange to include Drush commands here. There is a separate page for doing this with Drush, and if you have chosen to use the browser upgrade approach info about Drush is just distracting - IMO.

Yes, I'm observing the same. Basic comments:

• As long as the announcement link to the release notes and not back, we are basically already saying that the release notes are most important.
• If we want an X.Y announcement to be listed before X.Y.0 to X.Y.N release notes, we need the release notes to link to the X.Y announcement.

Not sure we can do that much SEO - headings seems to be a propriate at least. And the pages are just different - short versus a wall of text.

A side note: Should we create an URL alias https://www.drupal.org/blog/drupal-latest → that always links to the announcement for the latest release? Just like we have https://www.drupal.org/latest-release → / https://www.drupal.org/download-latest/zip →

I think "Drupal 7: The Essentials" goes deeper than the user guide in some topics - part B and C which covers Views and Rules (and more). I just loved the work that Johan Falk did which makes it hard for me to just "throw" this out. However, you are right, it will never be maintained. Then again there is probably plenty of low quality D7 docs that are already migrated. I end up wanting to migrate this even if it just an archive.

A big resounding yes from me. Testing the project browser on D10 and getting a lot of old D7 stuff from the project pages is a problem. Maybe a mini initiative to update using the template would help? In particular when the project pages only can be edited by the project owner - they are not a wiki.

PS! We also have the "new" feature that enables copying the readme ... It's not easy getting all of this right.
 

Removed useless tags and some formatting and link improvements.

Some link tweaking in issue summary.

Some random comments to jwilson3 above:

1. "Update the Node title and URL alias to something even shorter. E.g. /docs/develop/ddev-local".
   Yes, short and nice URL aliases would be perfect, but I have been told that we should leave automatic URL aliases on - multiple times. Then the URLs tend to become very long ... Anyway, I think the use of URL aliases might need a separate issue
2. I think we should avoid repeating information that is maintained upstream. If we can focus on what is truly Drupal specific, that helps. (The DDEV people documents installing DDEV quite nicely.)
3. Removal and clean-up is nice, but we have to remember that this is a Wiki. People can create pages about the tools they use. This is how we ended up where we are. I don't mind being strict, but putting everything under "Other" doesn't help. We have to dare to remove stuff
4. And finally, a rant: Installing DDEV isn't easy on Windows. That is why we get guides like this → - great work, but repeats too much infomation for my liking.

So, how do we proceed? Consensus by discussing like this takes long time. Maybe just edit the IS and discuss when we disagree ...

it looks like the redirect for /node/27882 got flushed out as well

Not under my control. You can readd the redirect under the settings for the page you created.

Yes, you lack permission. I don't, but got

You tried to migrate over 30 child nodes. Usually a guide consists of a smaller number of pages. To prevent possible mistakes, please select a smaller sub-set of book pages for migration at a time.

In addition OG was missing a D7 guide to migrate to, but I have created that now → and added you as maintainer. You should be able to migrate (in multiple steps). Or maybe delete the D6 stuff first gets you under the 30 child node limit.

Editing link display in IS.

• I deleted 27882.
• I can migrate directly into any module documentation guide, but not the general docs. It would help if drumm relaxed the conditions now to get the pages faster migrated.

Readding two missing anchors used by core. All other previous anchors match automatic anchors and they shouldn't change since the header is the module name.

Sorry, I was afraid I broke some important anchors. The simple way to avoid breakage in the future is to never insert anchors manually, but just use headers (and don't change the text of the headers).

Fixed title too

Fixing menu title

Remove "module" from menu link

Remove "module" from menu link

Remove "module" from menu and use automatic URL alias as all other modules.

I have reviewed / skimmed Videos and slides → and it's filled with dead links. In addition, if a video is a good resource for say a module, it's much better if it is listed directly in that documentation. Strong delete from me..

I have reviewed and cleaned up Tutorials → . Even if some of the content is still relevant - and even for (early) D8 - I think it's just too random. We should focus on creating new tutorials for D10 in stead. Strong delete from me..

Using h3 instead of list items to get TOC and automatic anchors.

Adding to menu (and using automatic URLs as all other modules)

Adding to menu (and using automatic URLs as all other modules)

Adding to menu

Any reason we aren't using h4 to get automatic TOC *and* anchors for the module headings that we now are settings as bold ...

hansfn → created an issue.

@drumm, could you mass delete Zen for Drupal 5 and 6 → . Several of the other "big" themes like Fusion and Omega still use these guides and should be migrated - if we still care about D7 ...

hansfn → created an issue.

I get overwhelmed when I start looking at this. So much nice stuff contributed over the years, but auto-migrating it will probably just create a maintenance nightmare.

Anyway, @drumm could you delete all sections named something with D5 / D6 Migration archive → ? Maybe all of it is D5 / D6, but quicker to review when the obvious stuff is gone.

Differentiate between “officially maintained” and “community maintained” docs in order to limit scope

Yes, that was the starting point for curated / official guides → too. Using a better tool (e.g. ReadTheDocs) for the job helps, but the though problem is exactly how to differentiate and how to handle "community maintained". There is so much stuff I would like to delete, but people have invested so much time that it is hard to do without any guide lines. I think we need to discuss this properly.

PS! We have struggled with this for a while → ...

My plan / wish is to remove as much as possible because we 1) don't have the resources to update them and / or 2) IMO we add too much non-Drupal specific docs. That doesn't mean that these pages aren't useful ...

In general, to repeat myself, the problem is what to do with D7 specific stuff. We have migrated a lot already that we maybe would deleted now.

Deleted "Complete Open Source Dev Stack".

Rant: I really dislike these "mega" guides that covers everything. We recently got a new one for Windows / WSL: Installing Drupal with DDEV in WSL2 on Windows →

Deleted "Using Drupal 7 with Rackspace CloudFiles CDN" and "Optimizing Drupal on Rackspace Cloud Sites".

I think we might need a meta issue to discuss how to treat D7 specific documentation. That there is a doc page for D8+ doesn't mean that we should delete the D7 version - if we want to support D7.

Deleted "Quick Install Guide (Ubuntu)", "Database schema", "Basic tools for OS X based Drupal Contributors", "Including the community in design processes" and "How to use Selenium - PHPUnit for automating functional tests".

I think "Mix public and private files with Organic Groups and File (Field) Paths" is useful - if we still support D7 in the docs ...

And "Core Theme Candidate Requirements" could be preserved as a documentation for what is required for the next core theme. I read the 15 (+) year old issue ...

I'm fine with deleting the two last also, but just opening for discussion.

Let's say that we work on this for X weeks. Maybe two? I was just trying to avoid creating multiple issues.

I think we should preserve "Book: Drupal 7 – the Essentials" as the version on drupal.org is the source, it seems - read Book "Drupal 7 – the Essentials" being added to the community wiki.

"Drupal 7 - How to use Drupal's i18n and Organic Groups modules to create an international website" is about site-building, true, but the content isn't covered in the current "Multilingual guide". If we delete this, it's because it's D7 and D7 is soon EOL. Which is completely fine with me, but then we can delete a lot of already migrated pages too - for example Cookbook: Build a non-English D7 website → in the "Multilingual guide".

"Site building: beginner, intermediate, advanced" can be deleted IMO. It's better to recreate if someone finds it useful. We are very short on resource so updating it is really not an option.

D7 documentation is located under docs/7 - for example  https://www.drupal.org/docs/7/api →  So this is for D8+.

Agree - deleted.

I agree with apaderno - we should minimize the effort used to clean-up.

If quietone and ressa create issues with suggested deletions, I'm happy to review (and delete). Then we are only 3 people "wasting" our time.

It helps with "task" issues like https://www.drupal.org/project/documentation/issues/3441968 →

@drumm: Yes, go ahead and delete PHP block snippets, PHP block visibility settings, PHP page snippets

Agreed. Section (with sub pages) deleted.

Page deleted.

Dreditor is decommissioned - see https://github.com/unicorn-fail/dreditor

I very much like that you create a list of pages / guides to be deleted. However, I think problem / motivation should be in the same list:

1. Quick Install Guide (Ubuntu) →
   Reason: This is a single page that is sparse and outdated
2. [...]

And when we delete pages, just strike them out:

1. 
   Reason:
2. [...]

And when we find new pages in the same guide, just add them to the list.

Rackspace is very much alive (it seems) and we can fix the links. However, to me the reason for removal is that we should not document how to setup up a website on every cloud service out there. (The .htaccess is outdated, of course.)

Deleted now.

PS! I think it's better to create issues with multiple pages that should be deleted (like you did for "Delete several top level pages at TO BE MIGRATED").

Thanks for the contribution.

I have reviewed the MR:

1. Many unrelated (array) changes. In general that should be avoided, and it seems you are breaking coding standards → .
2. I'm sure there are more \Drupal usages, but maybe not in classes. Have you checked?

I have skimmed through all those except "Migration archive" and did not find anything that I thought need to be moved to the new documentation system. I think this is also supported by no one else has come along and moved pages either.

I think that is a too broad statement. Firstly, there is a lot of content under these guides. I skimmed too and found a lot that is useful, but needs updating. Secondly, people are finding the pages using search and are happy with that. The don't care which system the pages are in.

Anyway, we aren't interested in moving this mostly D7 stuff to the new system. We don't have the resource to do it properly. So either we delete or we make a static archive of the pages. (A minor clean-up before archiving is necessary.)

Trying to clarify that this is about block plugins.

Just a quick background: I'm not a core developer or an active module maintainer. However, I have been on the documentation team (if that still exists) for a long time, and for some years now I have monitored all new doc guides / pages added (to our Wiki). I really, really welcome this effort, but I hardly know where to start talking about this ... I have added two random related issues / efforts.

1. Should we setup some meetings to discuss this instead of writing page up and down? This topic is important enough to try some real-time discussion too.
2. Versioned documentation is great. Why shouldn't we be able to do it when Symfony does it? (Symfony setup docs for 6.4, 7.0 and so on.)
3. We need to clearly define the different docs we have and how we want to manage it. I don't think everything should be managed as part of code (but we still should versioning as much of it as we can).
4. What about curation? I like that using GitLab automatically adds a review step. I think it will make our docs much better, but it of course raises the bar a little bit ... At the same time, there is no review on Wikipedia. But the Wikipedia policing is quite strict. I prefer up front policing ;-)
5. We need a clear plan for module documentation too.
6. And should we also support those who write big guides covering all between heaven → and earth → ...
7. And so on ...

Adding to menu. Switching back to "Needs work" as both language and clarity should be improved. It's not important who wrote what and where ;-) 

Yes, the vandalism → could be an accident. I'm fine with the issue being closed for now.

PS! While thinking about it, I remember looking at the "Unilevel MLM eCommerce Plan" project earlier as it seemed spammy. I came to the same conclusion as you - the project seems genuine, but very unfinished.

hansfn → created an issue.

hansfn → made their first commit to this issue’s fork.

Dummy edit to update URL alias. (URL alias setting for doc guide / parent, needed to be fixed first.)

Dummy edit to update URL alias.

Dummy edit to update URL alias.

Trying to add to correct "Core modules" ;-)

Removed notice about not being part of core.

Adding "module" to title to be consistent with all other modules.

Adding "module" to title to be consistent with all other modules.

Adding to menu / approving.

Adding to menu. Seems like useful information. Sorry that the page lived in the dark for a year or so.

Adding to menu / approving.

it's easy enough to define a new workflow, I don't really see why this has to be part of Commerce core.

But since some workflows actually are included in core, they should cover the most common uses case - including refund.

However I think the crux of the issue is that workflows can't be defined from the UI. The skillset needed to define a custom workflow is way bigger than what's needed to administer a commerce site.

This is a very good observation.

Consistent headers / formatting.

Is there any reason you don't update INSTALL.txt as part of this issue? I find it confusing when the wiki is updated (like quietone just did - great), but the source code isn't. I normally like to point to INSTALL.txt if there is a discussion about requirements.

Also the evaluator guide → needs to rewritten since it uses the tar-ball for quick setup.

To me this sounds very useful. Before defining the roles, we probably should agree upon the usefulness.

@drumm Any technical barriers?

Yes, moving any stuff that isn't specific for Windows to a more general page is nice. And maybe you could extend the Configuring Visual Studio Code page → too.

I could strip it out for d.o. and post the whole start-to-finish thing as a more opinionated tutorial offsite.

As you already have guessed, I think that is good solution. (Adding a link to that offsite tutorial would be OK in my view.)

An attempt of clarification. I decided to use "Bare metal". And I moved the AMP stuff at the beginning as both environment contains an AMP stack. 

Agreed that "speak" might be too informal- using "terminology". And removing "8+". Drupal means the moderns Drupal.