🇹🇭Thailand @Nick Hope

@quiteone To be frank, I thought it was fine as I had written it, but I do understand the wish to defer to a single source of documentation where possible to avoid redundancy/obsolescence. However, IMO, deferring to the documentation on ddev.readthedocs.io leads to a rather convoluted experience.

I think part of the problem is that I wrote Installing Drupal with DDEV in WSL2 on Windows → (the parent of this document) as a complete, 'hand-holding' tutorial, reflecting exactly what I went through myself to get everything set up nicely, because there is no comprehensive guide out there and it was really tough for me, but I guess Drupal Documentation isn't really for such tutorials. I need to find a home for this tutorial elsewhere (perhaps YouTube, when I next undertake the whole process on a new computer).

If the consensus is that the detail is superfluous and should be removed, I'll go along with it.

Add space after comma.

Add space after comma.

Add space after comma.

Add space after comma.

Add space after comma.

Add space after comma.

Add space before comma.

Correct spelling of "environments".

@quietone Unfortunately the result of removing those details is that it is now more difficult for the user to understand exactly what is required to get DDEV, Docker & Drupal installed in WLS2. By simply linking to the top-level, cross-platform "Install Drupal using DDEV" page, they are thrown into a chain of documentation that contains lots of information that is redundant in this case, and is quite complicated to navigate, with every chance they will either fail to reach https://ddev.readthedocs.io/en/stable/users/install/ddev-installation/#w... (which is where they need to get to), or to mess things up with unnecessary steps along the way. The now-removed detail guided the user concisely through the process and included useful explanation and tips that are now gone.

@aolvera Which version of SHS did you apply patch #12 to and how did it fail? It is probably better to open a new issue, rather than change this closed feature request into a bug report.

#18 works for me. PHP 8.3.2 (DDEV). Drupal 10.2.6. Facets 3.0.0-beta1.

Good spot @ericgsmith. It does indeed seem to be an incompatibility with the Editor Advanced Link module → . If I uninstall that, then this patch works correctly. Apologies for that oversight.

Editor Advanced Link is quite a widely adopted module (109k sites), so this incompatibility should probably be addressed before (if) this feature is added to Linkit. Not sure which side it would need addressing from.

There are also important views and discussion on the related issues ( example ✨ Show entity title after autocomplete selection instead of internal route (e.g., /node/123) Needs work ) that should be considered.

@klidifia Thanks for testing it.

I'm testing with Drupal 10.2.6, Linkit 7.0.0-alpha1 with a patch downloaded from your last MR. I've tried on an old Drupal D10 project and a near-vanilla D10 project. Tried articles, basic pages, basic HTML, full HTML, default Linkit profile, new "Taxonomy Terms" Linkit profile.

I'm finding that the link window will close correctly for the first link I create in an article, but today I'm getting the route before the term name in the anchor text (reverse of yesterday), like this:

<a href="/taxonomy/term/9" data-entity-type="taxonomy_term" data-entity-uuid="2c20c5cb-dee2-4af4-9408-2394309a3c19" data-entity-substitution="canonical" data-entity-title="Thailand">/taxonomy/term/9Thailand</a>

When I try to create a 2nd link in the same article, I get this console error in Chrome (I'm afraid I'm not much use at interpreting it):

ckeditor5-dll.js?v=40.2.0:5 Uncaught TypeError: Cannot read properties of undefined (reading 'attributes')
    at Ar.getChanges (ckeditor5-dll.js?v=40.2.0:5:376656)
    at html-support.js?v=40.2.0:5:44080
    at $r._callPostFixers (ckeditor5-dll.js?v=40.2.0:5:390254)
    at $r._handleChangeBlock (ckeditor5-dll.js?v=40.2.0:5:389512)
    at Cn._runPendingChanges (ckeditor5-dll.js?v=40.2.0:5:424836)
    at Cn.change (ckeditor5-dll.js?v=40.2.0:5:421831)
    at r.on.priority (editorAdvancedLink.js?v=10.2.6:1:7035)
    at oe.fire (ckeditor5-dll.js?v=40.2.0:5:604093)
    at <computed> [as execute] (ckeditor5-dll.js?v=40.2.0:5:607777)
    at f.execute (ckeditor5-dll.js?v=40.2.0:5:112967)
rethrowUnexpectedError @ ckeditor5-dll.js?v=40.2.0:5
change @ ckeditor5-dll.js?v=40.2.0:5
r.on.priority @ editorAdvancedLink.js?v=10.2.6:1
fire @ ckeditor5-dll.js?v=40.2.0:5
<computed> @ ckeditor5-dll.js?v=40.2.0:5
execute @ ckeditor5-dll.js?v=40.2.0:5
execute @ ckeditor5-dll.js?v=40.2.0:5
(anonymous) @ link.js?v=40.2.0:5
fire @ ckeditor5-dll.js?v=40.2.0:5
e.listenTo.useCapture @ ckeditor5-dll.js?v=40.2.0:5
fire @ ckeditor5-dll.js?v=40.2.0:5
t @ ckeditor5-dll.js?v=40.2.0:5

I could do a screen recording with a completely fresh D10 project if that would help, so we can see if/where our steps differ.

@klidifia Thanks for the heads-up on the related issue → .

I made a patch out of #10 and patched 7.0.0-alpha1 with it.

In my testing (linking to taxonomy terms only, which is my use case), if a link to a taxonomy term is inserted in an article without first selecting text, the small link window does not dismiss when the green arrow is clicked. I can dismiss that window by clicking outside it, in the body of the article. Then the link is just shown as a vertical bar (like a pipe symbol). When I save the article, the taxonomy term name is shown, but followed by the term route. e.g. Thailand/taxonomy/term/683, where "Thailand" is the term name.

@Andriy Khomych But the problem of missing term_merge is not resolved.

As far as I can tell, one of @arx-e's suggestions in #8 should be done. If you plan not to do either of those, then there should at least be clear instructions in the module description and Readme file that term_merge must be installed and enabled separately.

By the way, the module description still refers to 7.x only with regard to merge: "merging of terms (using the Term merge module in 7.x)".

Personally, I prefer not to have to manually install a separate module to achieve the merge functionality. So I would tend towards the option of adding the dependencies of the submodule in the main module's composer file. But will that cause problems with minimum stability level because term_merge and term_reference_change are both still in beta, and taxonomy_manager is not? (I don't have the experience to know)

Another option might be to make a 2.0.12 that reverts to 2.0.9 (removing merge functionality and dependencies), and also make a 2.1.0-beta1 that includes merge. But care would be needed not to leave users with more config issues. I guess the consensus might be that it is now too late for that approach.

@Andriy Khomych This doesn't seem to be due to config leftovers. The issue happens on a fresh install of Taxonomy Manager on a test site. 'term_merge (missing)' is shown If I expand 'Taxonomy Manager Merge' at /admin/modules. It can be resolved by installing term_merge manually:

composer require 'drupal/term_merge:^2.0@beta'
drush en term_merge

p.s. Thank you for your efforts in improving Taxonomy Manager.

I don't know why composer is not installing term_merge. It is required in taxonomy_manager_merge/composer.json.

Follow-up issue for 'missing module' problems after updating to 2.0.11: https://www.drupal.org/project/taxonomy_manager/issues/3445744 🐛 Missing modules after updating from 2.0.10 to 2.0.11 RTBC

I had the same issue after the troublesome update to 2.0.10 and then 2.0.11, as described in https://www.drupal.org/project/taxonomy_manager/issues/3444071 🐛 Version 2.0.10 breaks existing installations Needs work .

After trying many things without success, I uninstalled and removed Taxonomy Manager completely:

drush pmu taxonomy_manager
drush pmu term_merge
drush pmu term_reference_change

Removed taxonomy_manager from (`composer remove taxonomy_manager` didn't work. I don't know why)
Removed taxonomy_manager patch 🐛 Version 2.0.10 breaks existing installations Needs work from composer.json

composer update
drush updb
drush cr

Then I installed taxonomy_manager 2.0.11 again:

composer require 'drupal/taxonomy_manager:^2.0'
drush en taxonomy_manager

Now I have a new but related issue. If I expand 'Taxonomy Manager Merge' at /admin/modules it says 'term_merge is missing'. I am not sure why that is, because term_merge is required in /taxonomy_manager/modules/taxonomy_manager_merge/composer.json.

Happy to open this as a separate issue if necessary.

Patch #12 works for me.

This was my experience coming from 2.0.9 in Drupal 10.2:

1. Updated 2.0.9 to 2.0.10 via `composer update`.
2. term_merge and term_reference_change modules got installed with 2.0.10.
3. Ran `drush updb` and got the error "Error: Class "Drupal\term_merge\Form\MergeTerms" not found in include() (line 21 of /var/www/html/web/modules/contrib/taxonomy_manager/src/Form/MergeTermsForm.php) #0 /var/www/html/vendor/composer/ClassLoader.php(576): include()"
4. Applied patch #12 in Composer with cweagans/composer-patches => `composer update`.
5. `drush updb` => 'yes' at the prompt.
6. `drush cex` => 'yes' at the prompt.
7. `drush cr`

All seems OK.

On a 2nd site, I added the patch before updating and it went smoothly.

Probable duplicate of https://www.drupal.org/project/media_entity_remote_image/issues/3331639 🐛 Alt field ALWAYS required with Multiple Field remote image url Active . The title and description of that issue should be simplified to the most simple case in which this problem occurs (or expanded to include the case in this issue, if different) and then this issue should be closed.

Thanks for the feedback @figarlin and @ptmkenny. As these are instructions for someone contributing code changes, rather than for someone looking for a patch, I rephrased the section closer to my original phrasing, but emphasized "in addition", and linked to 2 different ways of generating a patch. I think the important word is "consider", so it is only a suggestion rather than a recommendation.

Rephrased section about considering uploading a patch file in addition to making a merge request.

@figarlin Could you please add some rationale for deleting the suggestion about creating a patch file as well? I added that note when I overhauled this page, and still find patches easier to install via Composer.

Nick Hope → created an issue.

Add nano as an editor in Default Browser section.

Removed superfluous introductory paragraph. Numerous grammar, spelling, and other minor corrections. Changed warning text and marked this page as deprecated because it duplicates Windows development environment → but is not as complete or up-to-date. The effort should be on keeping those guides up to date.

This page should probably be deleted at some point but there may be a few fragments of useful information here that could be included in those other guides first.

Remove --create-docroot as no longer needed.

Changed Windows Terminal from (optional) to (recommended).

Same here. I updated DDEV and it gave me PHP 8.3.2 and now the warning has gone.

Thanks for the feedback. I'm planning to tackle this next week.

Grammar, phrasing, add links to supported web server and database server software.

We should really call it a bare-metal versus a virtual environment.

But if you need to distinguish between a) Docker-based environments, and b) all the other alternatives on Installing Drupal on Windows for local usage → , is AMP-based development environments the best term?

@hansfn Don't feel bad. I'm also fundamentally in agreement and the work I did on that guide won't go to waste.

I'm ready to crack on with moving some content from Installing Docker, DDEV & Drupal in WSL2 to Local Development Guide. I'm talking about, for example, the Extending DDEV → section, which I think has value.

If the consensus is that some of the new material is too much repetition of DDEV documentation (e.g. the DDEV Commands → section), or too peripheral for drupal.org (e.g. the BrowserSync → section), I could strip it out for d.o. and post the whole start-to-finish thing as a more opinionated tutorial offsite.

If Local Development Guide gets too long, it looks like I could make a guide of it (rather than a page) myself and the existing page could be removed.

Will hang on a bit to see if others have input first.

By the way, there was some feedback on the guide from @rfay (the DDEV guy) on the DDEV Discord at https://discord.com/channels/664580571770388500/1068592266752573440/1200... Haven't followed up his points yet.

Re #30, I agree that much of what I've put in the Windows guide about the DDEV & Drupal installation should probably be put into documentation that applies to all platforms.

In practice, that would mean removing much of Installing Docker, DDEV & Drupal in WSL2 → (after the WSL2-specific stuff at the top) and integrating it into Local Development Guide → .

That's quite a lot of detail to add, and some of it is a little opinionated. Is that OK? It would be a pity to lose that detail completely because I think it helps Windows users to have a step-by-step guide from start to finish so they don't get overwhelmed.

In fact, with that much detail added, Local Development Guide may be better as a multi-page guide rather than just a page. Then, for example, the Drupal best practice settings → page I wrote could also be appropriately edited and moved into it (and further modified if need be).

Re #31, probably not, actually. I think the Windows DDEV guide was much more important than for Mac OS / Linux because of the WSL2 factor and specific considerations that introduced (like simply how best to edit text files).

Also, I think the new recommendation that @eojthebrave has added on the Mac OS page should probably also be added to the Linux page, to focus the recommendation on DDEV.

Remove extraneous "the". Change "set ups" to "setups".

Add links to sources of DDEV add-ons.

Italicize DDEV Drupal Contrib heading for uniformity

Add section about DDEV Drupal Contrib.

Lower case words in title for uniformity

Lower case words in title for uniformity

My aforementioned guide is here: Installing Drupal with DDEV in WSL2 on Windows → . It is written from the perspective of a Windows-using site builder with no Linux experience and limited development experience.

It goes quite deep, sometimes into quite peripheral areas (e.g. Zsh), but as DDEV is now the recommended Drupal development environment, there is no escaping the fact that this environment requires some Linux command line skills, which can be daunting. It's not Dev Desktop! So I hope Windows users will appreciate the hand-holding, detail, and effort to make their experience as least intimidating as possible. This is the guide I wish I had when I undertook the process of transitioning from AMP-stack environment to DDEV myself, a process that I found quite complex and time consuming.

Feedback welcome here or in the docs' 'Discuss' threads.

I and others have also spent quite some time signposting various 'development environment' guides back to the DDEV-related pages, initially with warnings, but more recently with 'note-tips'.

Guides to installing Drupal with DDEV on Mac OS and Linux are still needed within the Mac OS guide → and the Linux guide → . They would not need to go into the detail that my DDEV-on-Windows guide does. One-pagers would probably be enough, and this page from my guide → could be a useful reference to start with. It might be quite a straightforward job for Mac/Linux users to do that, or at least get something in place that can be fleshed out.

Add introductory link to the parent guide. Add "Summary & next steps" section.

Put final sentence into "Next steps" section.

Put final sentence into "Next steps" section.

Put final sentence into "Next steps" section.

Add "Next steps" section and some text near to top to link this page with the previous and next pages in the guide.

Adding sentences near the start and at the end to link to the previous and next pages in the guide.

Add final sentence to link into the next page in the guide.

Adding sentences near the start and at the end to link this page with the previous and next pages in the guide.

Remove "Finally,". Change headings to h2.

Remove Contents section (duplication). Many minor corrections. General polish.

Remove Contents section (duplication). Many corrections. General polish.

Remove Contents section (duplication). Remove personalisation ("I/me/mine"). Reshuffle. Many corrections. General polish.

Or perhaps we could move just some of the content from this page into an introduction in the "Windows development environment" parent guide, then turn this page into an "AMP-based development environment" parent guide (within this guide) and put the XAMPP and Bitnami guides within it. Is that even possible? That would push the XAMPP sub-pages down a level, which might not be a bad thing.

I'm also wondering if we should refer to "VM-based" environments somewhere. What exactly differentiates a "VM-based" environment from an "AMP-based" environment anyway? For example, is Bitnami package for Drupal a VM-based environment or an AMP-based environment or both? Maybe there's no need to refer to "VM" at all. I see DrupalVM is deprecated.

Link DDEV in the warning to Installing Drupal with DDEV in WSL2 on Windows → .

Add link in the warning to DDEV-on-Windows guide. Potentially the warning could be "softened" to a note-tip to match the other guides at this level.

I don't know why the menu in the 5 sub-guides of this guide (e.g.  Installing Drupal on Windows for local usage → ) are still showing a link to "Installing Drupal in DDEV in WSL2" on Windows at the top. I can't see a way to remove that. Is it just a caching issue?

Potentially the information on this page could be included in the parent Windows development environment → and this page deleted. That might make more sense.

Overhaul page to reflect current practices. Rephrase and remove unnecessary content to make it much more concise. Correct names of software applications. Change menu link weight to move this back to the top.

Change the warning to a note-tip, rephrase and link to new DDEV-on-Windows guide.

Add warning that Bitnami Drupal Stack has been discontinued in favour of Bitnami package for Drupal which requires hypervisor software such as VMware Player or VirtualBox.

Change status to "Deprecated", as this workflow is no longer possible. The status could potentially be changed to "Needs work" and the page could be overhauled to describe the current workflow using Bitnami package for Drupal (or perhaps deleted).

Change the warning to a note-tip. Rephrase and link to new DDEV-on-Windows guide.

Full stop for consistency.

Add link to Installing Drupal with DDEV in WSL2 on Windows.

Change "...in DDEV..." to "...with DDEV..." in title and summary.

Remove the warning, now that we have a DDEV-on-Windows guide.

Change menu link weight

Change menu link weight

Change menu link weight

Change menu link weight

I have written and posted Installing Drupal in DDEV in WSL2 on Windows → . It's long and deep, but, having gone through the process and found it tough and intimidating, I think many Windows-using site builders will benefit from the hand-holding and detail. As a guide about the current recommended Drupal development environment on Windows, I hope it can be approved and added at the top of the menu. I've also offered to be a maintainer 🌱 Recruiting guide maintainers for documentation Active for this, its parent.

Having just written and uploaded Installing Drupal in DDEV in WSL2 on Windows → , I would be happy to be a maintainer of Windows development environment → (of which it is a part).

Expand WSL2 in summary

Add Docker tag

Minor

Minor

Change menu link weight

I am writing a new guide to installing Drupal in DDEV with the Docker CE engine in WSL2, having been through the process recently and taken extensive notes. The intention is that it will be the first guide in https://www.drupal.org/docs/develop/local-server-setup/windows-developme... → .

I'll include some steps on DDEV-Drupal configuration, but I expect/hope that info could be in a separate "Drupal in DDEV" guide linked from https://www.drupal.org/docs/develop/local-server-setup/docker-based-deve... → , that applies to DDEV on any platform.

Thank you very much @solideogloria. Your explanation and links help me a lot. As an independent site builder, I don't actually use Git in my local development, relying instead on regularly backing up my codebase and exporting my database. But I probably should!

Marking this as Closed (works as designed), since the discussion is beyond the scope of Allowed Formats.

These issues are also fixed in https://www.drupal.org/project/block_title_link/issues/3285695 🐛 Deprecated function: parse_url(): RTBC , which primarily fixes a deprecated function error. So I'm closing this issue in favor of that one.

MR !3 (#4) also works for me. Setting to RTBC and adding a corresponding patch file for those who need it.

Note that this MR/patch also fixes the issues reported by phpcs 📌 Fix the issues reported by phpcs Needs review .

So I did this in Drush by running drush cex but, as I understand it from the documentation → , I don't think I really needed to do anything at all while my site is only in local development. My sync directory had no yaml files in it. A clarification of that in the "What you need to do" section on the module description would be helpful.

This happened to me when I ran database updates while upgrading 8.x-2.x-dev to 3.0.0-alpha3 (while upgrading D9 to D10).

#25/#26 worked for me. Thank you. I made a new folder 'computed_field_php_formatter' in my modules/custom folder, and put the 2 files from #26 in it. Then I could run drush updb without errors.

Part of the problem for me is that it's a complex development site that I'm returning to and I can't remember if/where I've used Computed Field. Once I've found that code, if there is any, I'll try and move it to version 4.

Changing to "Needs review" until there's consensus on whether "Set the class to final as well" should be deleted. Personally I don't know. Maybe the original author, @mglaman has a view?

I agree that the page should be deleted. The content is outdated and it duplicates other pages. In the meantime I added the warning to match other outdated pages such as https://www.drupal.org/docs/develop/local-server-setup → and https://www.drupal.org/docs/develop/local-server-setup/windows-developme... →

Guidance on enabling and configuring settings.local.php for a local environment is needed. I could not find documentation on that anywhere. It would be around the " Status Check → " point in this guide, but doesn't really belong in that page itself. Perhaps it could be part of a larger guide on configuring settings.php.

Guidance on enabling and configuring settings.local.php for a local environment is needed. I could not find documentation on that anywhere. It would be around the " Status Check → " point in this guide, but doesn't really belong in that page itself. Perhaps it could be part of a larger guide on configuring settings.php.

1. Linked 'sync directory' text to https://www.drupal.org/node/2431247/ → .
2. '...export directory (called "sync" by default)...' contradicted https://www.drupal.org/node/2431247/ → . I changed it to 'sync directory'.

I feel this document should contain a reference to settings.local.php, but such a reference would need to link to documentation about the use of settings.local.php, and I couldn't find such a document on D.O.. Maybe we should add one.

1. Moved "Failure to have a sync directory..." paragraph to the bottom of that section, so it doesn't interrupt the flow of "how to move the sync directory".
2. Moved the caveat about DDEV from the bottom of the page into a note in the main section where it is more difficult to miss. I missed it, and others would too, and it's important since DDEV is now recommended.
3. Changed the DDEV link to D.O.'s "parent" DDEV reference, rather than DDEV's site (with the expectation that that section on D.O. will be expanded at some point to link to documentation on how to set DDEV up specifically for Drupal).
4. Other minor rephrasing.

I've done further testing. Sites are both D10.2.1 with PHP 8.3.0. These were the steps. Unexpected results are in bold...

On near-vanilla test site:

1. composer require 'drupal/custom_add_another:^2.1@beta'
2. drush en custom_add_another
3. drush updb
4. drush cr
5. Add new plain text field to basic page content type.
6. Set to unlimited.
7. Set custom add button text "Add another thing".
8. Set custom remove button "Remove thing".
9. Save
10. Edit
11. Add button displays custom text "Add another thing".
12. Remove button displays standard text "Remove".
13. Edit the field in the basic page content type.
14. Both custom button fields still contain the custom text.

On a complex development site (with very long history):

1. Delete module
2. "drupal/custom_add_another": "^2.1@beta",
3. drush cr
4. Clear all caches in browser too (Admin Toolbar).
5. Add new plain text field to basic page content type.
6. Set to unlimited.
7. Set custom add button text "Add another thing".
8. Set custom remove button "Remove thing".
9. Save
10. Edit
11. Add button displays standard text "Add another item".
12. Remove button displays standard text "Remove".
13. Edit the field in the basic page content type.
14. Both custom button fields are empty.
15. Repeat steps, adding unlimited plain text field to audio file media type. Same result.
16. Added custom remove text to a taxonomy term field that already had custom add text (from a long time ago). After saving, both the custom add text and custom remove text in that field config were empty.

I'll try and do more testing with older versions of PHP / Drupal / CAA to try and narrow down the problem. Maybe I'll also see if values stick if I manually edit the database.