🇩🇰Denmark @ressa

I cracked the riddle: It's BigPipe! For some reason, hovering over "Extend" showed child menus all of a sudden, and looking at the source code, the only difference was a few BigPipe mentions. After uninstalling BigPipe everything works.

I think I understand why the hoverIntent plug-in cannot be used by default ... but it is a bit sad, since with the default settings, the menus will then fly out, when a user pass over the menu items, on the road to their destination. But perhaps that's a necessary situation? Maybe in the future, the "smooth" user experience can be made the default, somehow? I do know that some contrib modules, like Leaflet → and Collapsiblock 🐛 Update readme to reflect JS library download no longer required Fixed , simply bundle the JS library inside the module, to avoid loading external resource, and the module "just works". Is this not possible for Admin Toolbar as well?

Awesome work @keshav patel, this was exactly what I was hoping for, and it works perfectly, thanks!

I updated a few details, such as adding drupal_flush_all_caches(); as a final step, to allow template suggestions to work right away. Otherwise you have to run drush cache:rebuild for template suggestions to be shown, like these:

<!-- THEME DEBUG -->
<!-- THEME HOOK: 'html' -->
<!-- FILE NAME SUGGESTIONS:
   ▪️ html--node--1.html.twig
   ▪️ html--node--%.html.twig
   ▪️ html--node.html.twig
   ✅ html.html.twig
-->
<!-- 💡 BEGIN CUSTOM TEMPLATE OUTPUT from 'core/themes/olivero/templates/layout/html.html.twig' -->

I don't know if it would be easiest to get the code included in Drush itself, or Drupal core? I have created a Drush issue, let's see what the maintainers say: Add Drush command to toogle Twig debugging and CSS/JS aggregation #6267.

Thanks again, I am very grateful.

Add link to Custom Drush command for managing Twig debugging and CSS/JS aggregation.

Great work @keshav patel, this is simply awesome and works perfectly, thanks!

I am adding drupal_flush_all_caches(); as a final step, to allow template suggestions to work right away, did a few minor tweaks, and moving it to the other Drush doc page → .

Thanks @dydave, sounds good! Feel free to share any tips later on, how I can possibly do some simple debugging, or things to look out for -- then I can also look at this later today, since I'll also be away for now.

Thanks for explaining the thoughts and plans ahead for this in previous comments, and introducing JQuery HoverIntent (which I'll check it out later) They sound like great improvements!

I tried in Drupal 10 and Drupal 11 as well (both fresh installs) by checking out the Git branch:

git clone https://git.drupalcode.org/project/admin_toolbar
cd admin_toolbar/
git fetch "https://git.drupalcode.org/issue/admin_toolbar-3516995.git" '3516995-move-the-hoverintentfunctionality'
git checkout -b 'admin_toolbar-3516995-3516995-move-the-hoverintentfunctionality' FETCH_HEAD

... but I get the same result in both places, I tried checking and unchecking "Enable/Disable the hoverintent functionality", flushing cache, etc. but hovering does nothing. There are no errors in the Console.

It tried both Firefox and Chromium in Debian 12, if it makes any difference. But DDEV should make it irrelevant, I would think ...

You're welcome @dydave! Sounds good with the changes, a spring cleaning is sometimes needed :)

Here's what I do to set it up in Drupal 11 (Drush and Composer commands prepended with ddev via alias):

mkdir drupal && cd drupal
cd drupal
ddev config --project-type=drupal --docroot=web
composer create drupal/recommended-project
composer require drush/drush
drush site:install -y
composer require drupal/admin_toolbar:3.x-dev@dev
cd web/modules/contrib/admin_toolbar/
wget https://git.drupalcode.org/project/admin_toolbar/-/merge_requests/132.diff
patch -p1 < 132.diff 
drush install admin_toolbar admin_toolbar_tools admin_toolbar_search

Do I need to do more steps? Could it be because I am on Drupal 11?

Thanks @dydave, always a great idea to optimize the code structure :)

I have tested the patch, but the hover stops working ... I need to click (or right-click) to expand a child item. The code itself, I have not looked at.

Also, I don't know what hoverintent is about ... so perhaps this sentence could be expanded, and briefly describe what it does?

Check it if you want to enable the hoverintent feature, to ...

... similar to how sticky is described (explanation emphasized by me):

Disable Admin Toolbar's sticky behavior so it stays at the top of the page when scrolling.

You're welcome, it took me quite a bit of digging originally, dissecting the source code of different nodes, to find small clues like node-type-guide ("Guide") and node-type-documentation ("Page") to get closer to understanding the logic behind the limitations I ran into :)

Sure, I left a comment in the other issue instead.

It is still a recurring challenge that users cannot add an image to a post.

I hope it will be allowed to add images in Forum posts and comments in the new drupal.org?

I am no Organic Groups expert, but from trial and error using the Drupal.org docs system, it seems like the drupal.org doc pages are structured around two Organic Groups content types:

Organic Groups Guide

• Can have Organic Groups Pages, but also and Organic Groups Guides under them
• Body max. 500 characters limit

Organic Groups Page

• Can only be placed under a Organic Groups Guide
• Body has no upper character limit

So, the challenge in this case is that https://www.drupal.org/docs/develop/local-server-setup → is an Organic Groups Guide => so the Body field is limited to 500 chars. Does that make it clearer?

We can always revisit, when the new drupal.org is launched, and there will be no body limits for any nodes, and turn https://www.drupal.org/docs/develop/local-server-setup → into something along the lines of #48 📌 Review/archive the local server setup section Active .

ressa → created an issue.

drumm → credited ressa → .

Add Git tip about drush/drush.yml.

The logs are still getting filled up by this ... we must be talking about gigabytes, if not terabytes of wasted HDD space on a global basis :)

Thanks! Though, it's not a button, sorry.

Here is a link on how to create suggestions in GitLab. I believe everyone would benefit from knowing about it, since it can make the development process easier. And Drupal will be using GitLab going forward after all:

https://docs.gitlab.com/user/project/merge_requests/reviews/suggestions/...

If you can't be bothered that's all right, then I'll do it the other way. Just let me know.

Sorry @quietone, I actually really don't like abbreviations, since meaning can be lost as happened here, and then I used one myself ... "OG" is an abbreviation of Organic Groups → . (I'll update "OG" in my post above)

@jwilson@: I do agree that the header "DDEV" looks a bit naked now ... Perhaps we can add a little extra, to make it clearer what it is with "DDEV: The recommended dev tool" and link it up as you suggested? I went ahead and did the changes, and also removed "Get started with DDEV." --

What do you both think about that?

Updating header, linking it to DDEV install guide, and removing footer link "Get started with DDEV.".

Turn OG abbreviations into something meaningful.

Thanks for the review. It's not clear to me though, what exactly needs to happen ... Do you know about the Insert suggestion button?

I think it would be easier if you used that one for each suggested change. Then I can simply click "Apply suggestion" and your suggested code change gets implemented. I think that's easier for this refactoring, since I am not sure what needs to be done ...

You're right, thanks! I have updated the Issue Summary in the other issue.

I am also looking for this, and am adding the relevant Issue Summary from a now "closed as duplicate" issue.

It would be fantastic to be able to control subscription options by role.

Thanks for reviewing the page @quietone, it's great to hear that the page works as intended, and may help users looking for help with deploying an update.

Thanks for clearing this up, perhaps this post can help? https://www.drupal.org/forum/support/post-installation/2025-02-20/drupal... →

Thanks for feedback @quietone, I have updated these things:

• The heading is simply "DDEV"
• "Officially" is removed
• "Get Started with DDEV" got a period

"Tool" is often used about DDEV, which a search for "DDEV tool" in a search engine shows ... so perhaps we can use both "tool" and "environment" to cover people using searching with either word?

I do like the four points listing what's included, since it highlights straight away what DDEV comes with, for people new to Drupal and DDEV. Perhaps we can keep them:

Move the 4 points of what it provides to Install Drupal using DDEV for local development. It is a nice summary of why it is used. And I think it work better in the introductory paragraph on that page.

• The heading is simply "DDEV"
• Remove "Officially"
• "Get Started with DDEV" got a period

@jaypan: Yes, @apmsooner is very fast, and open for new ideas, which is awesome. Many ideas and solutions were floated in 📌 Make field form more intuitive and compact Active and I am glad to hear you like the new user interface.

And another great feature was added here, thanks to both of you :)

Adding Composer and Mailpit as included in DDEV.

Awesome job getting the message across much more efficiently, while working within the confines of the OG Guide, thanks @jwilson3.

I agree @jwilson3, the current structure is not optimal. It's probably due to OG limitations -- that an OG Page, which has no upper character limit, can only be placed under a guide, and an OG Guide Body field has a maximum of 500 characters. If the limit for an OG Guide Body field could be removed (or set to 10,000 characters) it would be liberating.

Also, the OG Guide Body limits will be removed anyway (I assume) in the new version of drupal.org:

For the modern version of the site, we are not using OG for this. Instead just a straightforward entity reference to the parent guide, and building customization around that.

And I do like the suggestion by GPT, we could tweak and use it in my opinion. If it's possible, perhaps we can turn the node under "Local server setup" https://www.drupal.org/docs/develop/local-server-setup → into an OG Page, and move the pages below somehow? This may not be possible ... If the upper character limit for Guide Body fields could be increased or removed, that would be of course be easiest.

Perfect, it's always nice to do a spring cleaning :)

This is a Drupal forum.

ressa → created an issue.

Cannot "Drupal Core migration instructions" then be removed completely, if the instructions were updated to something like this, to make the process clearer for the users?

After all, veteran Ludwig users are most familiar with Ludwig as a tool at this point, and not Composer.

Preparation

Using Ludwig, update Drupal core and Drupal contrib modules to their latest official releases. Remember to run database updates, either by visiting /update.php or running drush updatedb. Make sure everything works well before proceeding.

By getting everything ready first, and only then switching over from Ludwig to Composer, there ought to be no database or configuration changes, and you should only need to delete the contrib module folders, and download them with Composer.

Module migration instructions

Now we can migrate individual Ludwig managed modules, for example, the "Address" module.

1. Delete the "Address" module folder.
2. Use command composer require drupal/address

Repeat these 2 steps for all the modules you need to migrate from Ludwig to Composer. [...]

@core: Does it make it clearer what needs to happen?

I agree, the decimal field does look tall. But like you, I also think that it is probably not that common, and also that in most cases, there will be less than six sub-fields, so they will usually all be in a single row anyway.

Another reason for my proposal was also to get better separation between elements, since it looked like the "Remove" button could belong to the element above, and having sub-fields in columns definitely fixes that.

So I do think it's a clear improvement, in that it makes the form a lot shorter, and improves separation of elements. Thanks for being open to my suggestion, and ready to try out different solutions, and persevering.

Ah yes, of course.

I re-read the instructions, and they don't mention that the user should update everything to the latest version, before switching from Ludwig to Composer. So following the current instructions, the version of for example Address could get updated from 2.0.0 (Ludwig) to latest 2.0.3 when switching to Composer, and require visiting /update.php or running drush updatedb.

Actually, I would argue that updating everything to the latest version and run /update.php -- both for core and contrib modules -- within Ludwig, and get everything ready first, and only then switch from Ludwig to Composer, would be a better approach, since there ought to be no changes, except to delete contrib module folders, and download them with Composer.

With this method, step three should not be necessary, and the process look less daunting.

I am not sure what the "Run the update.php script." does ... maybe a Ludwig maintainer can clarify?

But other than that, yes -- it's the best approach to make any changes locally, and then repeat on the web server.

So, first install DDEV → on your own computer for local development, restore a copy of your web site in DDEV, and then:

1. For each module, like Address, delete the module folder in web/contrib/modules
2. Add the Address module AND its libraries with composer require drupal/address
3. Run update.php

ressa → created an issue.

@andypost and @znerol, you were correct. It could be solved in Drush, and pretty easily in fact (solution found in Github PR), simply by adding a drush/drush.yml file in each project with this:

options:
  uri: 'https://example.org'

The crucial point is, that this solution works well, even if the user has multiple Drupal installations on the same server, for example on a managed web hotel.

Sure, I have created a "Code examples" page, but it does look like you are admin of Flag, and should be able to create it.
https://www.drupal.org/docs/extending-drupal/contributed-modules/contrib... →

Since you are a Flag docs administrator, you should be able to add it to the menu, I believe.

Adding a base URL solution via drush/drush.yml.

Yes, to respect privacy, serving locally as default with CDN as fallback is the recommended method:

Note that it is in general not a good idea to load libraries from a CDN; avoid this if possible. It introduces more points of failure both performance- and security-wise, requires more TCP/IP connections to be set up, and usually is not in the browser cache anyway.
[...]
To search for libraries in a specific order, starting with local files, and if not found using for example a CDN as fallback, see Support for third party libraries in site specific and install profile specific libraries folders → , and JS Cookie or Tagify for examples on how to do this.

From Adding assets (CSS, JS) to a Drupal module via *.libraries.yml > From CDN / externally hosted libraries → .

@dave reid:

I'm not sure we need the logic to assume local by default, then CDN, rather than the other way around, since they're functionally the same?

I believe that is how it currently works, and that's great. I am not sure if the new code added changes anything? I only focused on the documenting part ...

* Structure
Could arranging the sub-fields in rows work? (see image below)

* Help text under each sub-field (#1)
Instead of repeating the identical help text under all of "Machine name" fields, we could instead show once, as an info text, right under the "Add sub-field" button, with some context added?

"Machine name: A unique name, made of only letters, numbers, or underscores. Will be transformed into human readable form automatically, and used as field name."

* Machine name (#2)
"Machine name" is a well known Drupal concept, and would work well, in my opinion (#1 in image)
https://www.drupal.org/docs/develop/user-interface-standards/machine-name →

* "Add sub-field"
Good to see this got added, thanks!

* Styling (#3)
I am not a fan of the red for "Remove", I think it draws too much attention.

About your thoughts, it's difficult for me to visualize ... perhaps you can make a rough sketch in GIMP, or some other way?

Thanks for sharing @murz, that's really interesting. The reason for replacing Nightwatch with Playwright is stated as:

Nightwatch testing is extremely unreliable and the cause of many random pipeline test failures.

So just to make sure, this has improved in 3.x, and there are less random failures, and it is more reliable?

It would be really interesting, if someone ran version 2.x of a Nightwatch test suite, as well as the same tests updated to version 3.x against a code base 50 times, and checked performance and test fail stats :)

Thanks @drumm. I know the other issue is older, but wouldn't it be better to continue in this issue and mark the other as duplicate, since this issue includes valuable information such as:

• A recent incident
• Feedback from a maintainer
• Feedback from a regular user
• Documentation

The recommended Drupal local development environment for Linux, macOS, and Windows is DDEV. Follow the instructions to install Drupal using DDEV for local development → .

From Local server setup → .

This looks great, thanks for creating an MR so quickly.

* Column name
I think I prefer each sub-field header to use "Machine name" (not "Column name"), since most users will probably understand that concept from elsewhere in Drupal.

* Help text under each sub-field
About the help text below the machine name field, what do you think about this?
"Unique name, made of only letters, numbers, or underscores. Will be transformed into human readable form automatically, and used as field name."

* Add another
Great suggestion about placing the "Add another" button at the top, above the sub-fields, since that will make it immediately clearer what to do as a user, and separate it from the "Allowed number of values" below.

Maybe we can incorporate the word "sub-field", like it is used on the project page?

"A single Custom Field can have many sub-fields [...]"

Those are also the words I use -- like "field" for the "parent" ("Journal") and "sub-field" for the items under that parent ("Journal name", "Journal comment", etc.).

To make it clear what the button does, and at the same time teach the user what different things are called, it could be named "Add sub-field"?

* Styling

About styling, I also initially thought about colouring the "Remove" button with a "danger" colour, but maybe it gets too busy? The user already needs to focus on selecting the correct "Type", so maybe the current grey colour is fine?

I also thought perhaps the "Add sub-field" button could be green, to make it pop, and also signal something positive, creating new things ... but maybe this would also get too busy, and the current grey colour is all right?

Looking forward to hear your thoughts, thanks for your efforts so far, I really appreciate it.

And if this MR went in, and you never added aliases, then they'd never get indexed at all.

True, but really, how often does this scenario happen -- a web site without aliases, yet with an urgent need for indexing? It seems to me highly theoretical.

Not having node/100 pages indexed would be fine in most cases, and probably preferred. It was a case of premature indexing in my case, and I did not want pages with node/100 indexed. Also, how does Drupal CMS shipping with robotstxt module affect this change? As I still see it, in the majority of cases, you do not want node/110 pages indexed -- As I wrote about this earlier:

And if that's true, we should make the preferred behaviour the default, non?

I still see this change as largely beneficial in the grand picture, for the majority of use cases. Conversely, if someone REALLY wants node/100 pages indexed, they can easily install the robotstxt module, and correct this.

That's pretty cool @fkelly, I wasn't aware that there is a terminal available straight in the browser in cPanel, it looks like since 2018.

• https://news.cpanel.com/cpanel-whm-version-72-now-in-release/
• https://www.knownhost.com/kb/how-to-use-terminal-in-cpanel/

• How to Enable Terminal in cPanel for SSH Access

Sounds great, thanks. Though, before spending any time on "Order of elements", we should make sure we are on the same page, and what you see after a fresh install. Please compare the two images -- do you see my suggestion in the Issue Summary, or the image in comment #8?

I based it on this sentence, straight from the top of the project description:

Defines a new Custom Field field type that lets you create simple inline multiple-value fields without having to use referenced entities.

I did consider re-wording it, and not including some of those comments, since they may de-rail the main point of this issue, which seemed to have happened ... In reality, whether it is "Unlimited" or not is a minor detail in this issue, and more of a side note, and I have updated the Issue Summary.

That aside, I left comments about the main point (re-structuring the elements) and I hope you have time to look at them, later.

Fantastic news, thanks @anybody!

Thanks for a fast reply as always! And it's so great that the machine name streamlining was fixed in the other issue, thanks for that.

Order of elements

About the order of elements, that's not what I see in a fresh installation. The "General settings" are sandwiched in between "Custom field items (machine+name/type) and "Form element|Settings|Check Empty" Or do you see something else?

Fresh install:

Unlimited by default

Please don't get overly focused on the wording, when I write "Always", replace with "95%". This module is for multivalue fields after all, right? I would even take it a step further, and set the default to "Unlimited" and LOCK it at that :)

From my perspective, if you are not using it for multiple values, you're using it wrong. Sort of like the saying "if all you have is a hammer, everything looks like a nail".

We should set sane defaults, accommodating the majority of use cases, and since in the majority use cases, the user wants "Unlimited" we should respect that, and make it easier for them by making that the default, so they don't need to tediously revisit the form, just to update this setting, because they forgot it.

I am curious though, what you mean with this, and if it is in the form or display ... maybe you can share an image, or visualize it some other way?
".... a single item custom field makes sense to store like fields together in a single row."

Display sub-fields inline, side-by-side

Since the elements are inline-block's they will align themselves and break into a new line automatically after five elements, and not require scrolling, I think that looks pretty good, and would be more user friendly.

"Technical Stuff"

About the other solutions you mention, I know too little about PHP, Ajax, and JavaScript for any meaningful input, like moving storage settings back into its own configuration management page, sadly ... I do trust that it's not easy :) (Could HTMX → be used?)

Ideally, the top "Custom fields item" section and bottom "Form element|Settings|Check empty" section were combined in a single configuration item. But probably -- as you write -- a more fundamental refactoring moving storage to its own config page is needed ...

I hope you find more co-maintainers. You could consider creating a "Looking for co-maintainers" issue, and specify the required proficiency and plans and hopes for the module?

Beautiful work @apmsooner, I no longer get the li wrappers at the sub-field level, but item/field-level, as expected:

<ol>
  <li>name | link | description</li> item #1
  <li>name | link | description</li> item #2
</ol>

Thank you so much :)

Perfect @apmsooner, this is so much better, killing three birds with a single stone. It works perfectly, thanks!

On a related note (this issue was a spin off of 📌 False warnings about security updates Active ) I am not sure if the module maintenance GUI got updated, and a warning about the potential consequences of removing "Supported" check mark was added, see #686918: Add help text to project release admin page to warn about marking branches unsupported and the impact on update status → .

But the current set up can sometimes results in false alarms, where a very small update gets released in a new version, and a seemingly innocent change in the UI by the maintainer (remove "Supported" check mark) results in security alerts emails to all the end users. So we should make sure that maintainers are aware of the potential result of this change.

Sounds great, thanks. @lavanyatalwar: I am unassigning you, since @apmsooner will take a deeper look at this ... or perhaps you want to take a closer look as well?

Thanks for clarifying, do you think it can be hidden with CSS, if from the perspective as a user, it is never relevant anyway?

ressa → created an issue.

ressa → created an issue.

I just tried replicating this with Custom Field 3.1.5 in a Drupal 11 installation (original issue in D10), also with DDEV PHP 8.3, and get the same warnings. Empty field or not makes no difference, like you write - it's a config thing.

These are the two config files:

field.field.node.article.field_journal.yml

uuid: 5a41cd90-8fe4-4554-bb9c-b2a14a45aa5a
langcode: en
status: true
dependencies:
  config:
    - field.storage.node.field_journal
    - node.type.article
  module:
    - custom_field
id: node.article.field_journal
field_name: field_journal
entity_type: node
bundle: article
label: Journal
description: ''
required: false
translatable: false
default_value: {  }
default_value_callback: ''
settings:
  add_more_label: ''
  field_settings:
    value:
      type: text
      weight: 0
      check_empty: false
      widget_settings:
        label: Name
        translatable: false
        settings:
          description: ''
          description_display: after
          size: 60
          placeholder: ''
          maxlength: 255
          maxlength_js: false
          prefix: ''
          suffix: ''
          required: false
    journal_comment:
      type: text
      weight: 0
      check_empty: false
      widget_settings:
        label: 'Journal comment'
        translatable: false
        settings:
          description: ''
          description_display: after
          size: 60
          placeholder: ''
          maxlength: 255
          maxlength_js: false
          prefix: ''
          suffix: ''
          required: false
    journal_link:
      type: url
      weight: 0
      check_empty: false
      widget_settings:
        label: 'Journal link'
        translatable: false
        settings:
          description: ''
          description_display: after
          size: 60
          placeholder: ''
          required: false
          link_type: 17
          field_prefix: default
          field_prefix_custom: ''
field_type: custom

field.storage.node.field_journal.yml

uuid: c6c261fe-853e-4f69-aba3-77311c275992
langcode: en
status: true
dependencies:
  module:
    - custom_field
    - node
id: node.field_journal
field_name: field_journal
entity_type: node
type: custom
settings:
  columns:
    value:
      name: value
      type: string
      max_length: '255'
      unsigned: 0
      precision: '10'
      scale: '2'
      size: normal
      datetime_type: datetime
    journal_comment:
      name: journal_comment
      type: string
      max_length: '255'
      unsigned: 0
      precision: '10'
      scale: '2'
      size: normal
      datetime_type: datetime
    journal_link:
      name: journal_link
      type: uri
      max_length: '255'
      unsigned: 0
      precision: '10'
      scale: '2'
      size: normal
      datetime_type: datetime
module: custom_field
locked: false
cardinality: 1
translatable: true
indexes: {  }
persist_with_no_fields: false
custom_storage: false

Strange, but awesome that it got fixed so fast, I really appreciate it!

Could it be because it's a migration, and the fields are not set as NULL in the database? The fields are Text (long), URI and Integer, though it's hard to find a pattern ...

Anyway, the patch works perfectly, and I no longer get the warnings. Thanks!

Cool, thanks! I forgot to add an important bit: "[...] if a field is empty", since it doesn't happen if all fields have values. (I added it in the Issue Summary)

ressa → created an issue.

Sounds good, thanks! I felt like we were talking past each other, and great we got to the bottom of this.

Thanks for elaborating. Actually, it's all right how it is, I can use the current format.

I mostly created an issue, since it seemed to me like the levels were one off. And you're probably correct that it is performing as expected, and outputting the correct format, it just seems off by one level to me. Or maybe you don't agree?

But out of curiosity, I'd just like to make sure we are talking about the same thing, with a simplified example. Because as I see it, tr and li are not on the same level, but they ought to be. Also, other users may also expect that the grouping element for "HTML list" is the field, not sub-fields?

Say, you have a custom field "Journal" with three sub-fields, this is what you get with "Table" display (all td's, div's etc. not included):

<table>
  <tr>name | link | description</tr> item #1
  <tr>name | link | description</tr> item #2
</table>

Currently with "HTML list":

<ol>
<li>name</li>        item #1
<li>link</li>        item #1
<li>description</li> item #1
</ol>
<ol>
<li>name</li>        item #2
<li>link</li>        item #2
<li>description</li> item #2
</ol>

Structure I would expect:

<ol>
  <li>name | link | description</li> item #1
  <li>name | link | description</li> item #2
</ol>

And yes, documentation is always nice -- having the steps outlined in the documentation how to achieve the structure in the last example would be great :)

Thanks again for a fast response. I would just think, that if we were to approach this "semantically" -- that since "Tables" are using rows for fields, and each sub-field is a cell, that a "HTML List" should behave the same way, and treat each field as a field item (<li>) and maybe even treat the sub-field content as a list. This current state seems inconsistent to me ... But let's maybe see if anyone else has an opinion about this?

Thanks for a fast response! I found the reason for this behaviour: The data is from a migration, and I had a closer look. I tried creating an extra entry manually, and after saving the node, all is well, and all empty field labels are now skipped ...

Taking a close look at the source, I realized that there were some dirty data, with lingering \n's, like this "journal_comment": "\n". I suppose the saving of the node got rid of this lingering character, cleaning up the field. After removing it, all is well, sorry for the noise. I guess the lesson I take home is to make sure the foundation (the data) is as clean as can be. Have a great day, and thanks for creating an awesome module.

It looks like https://www.drupal.org/project/field_updater → may be a match for copying content from one field to another:

The easiest and fastest way to update fields in Drupal. Provides a batch processing service to copy values from one or more field sources to a target field.

ressa → created an issue.

ressa → created an issue.

ressa → created an issue.

Add example on creating a term while inserting values into a multi-value field at the same time.

Miscellaneous updates.

I never tried those hosting provider one-click installs features, but often see people run into trouble later on, if they started with one of those.

@kentr: I agree about the overlap. I do like that this page has a more "quick-start" feel to it ...

I have started with moving the sections below from this page to Using Composer to Install Drupal and Manage Dependencies → (I believe originally added by me):

• Check for available versions
• Install latest release of Drupal 11
• Version control with Git

Moving the sections below to this page, from Starting a Site Using Drupal Composer Project Templates → :

• Check for available versions
• Install latest release of Drupal 11
• Version control with Git

Thanks for testing and reporting back @rajmataj! Great that you got it working. Maybe it's Drupal 11? I use it in Drupal 10 with PHP 8.3.17 as well.

I have added a tip, based on your report. Thanks!

ressa → created an issue.

Clarify that caching can be disabled.

I since remembered that I was also seeing caching, and ended up using https://www.drupal.org/project/cacheexclude → to skip certain paths from getting cached. I added a CacheExclude tip to the Search API doc page, maybe it can help in your case as well?

Add https://www.drupal.org/project/cacheexclude → tip to skip certain paths from getting cached.

I used Nominatim today with PHP 8.3 ... I don't see anything on their blog: https://nominatim.org/blog/

Have you experienced a problem with PHP 8.3 using Nominatim, or another provider?

Thanks @catch and @quietone -- I was alerted to the email page after the edit at 12.00, and was working on the "DDEV includes Mailpit" info-box when the suggestion to add it was posted here :)

Add link to Mailpit in DDEV.

Thanks for cleaning up @quietone :)

Add tip that DDEV includes Mailpit.