Added some clarity on what is supposed to happen when you complete the last step.
I struggled with step 5 so I made it more verbose explaining where to add the .ddev and .gitignore declarations.
@Jean-Paul Vosmeer: Thanks for the credit but it's (still) not visible on my profile: https://www.drupal.org/u/rroose →
Do I need to take any action?
How to reproduce with core:
- Make sure you are logged into Drupal as user with sufficient permissions
- Enable the 'Contact' module
- Navigate to /admin/structure/contact and 'Add contact form'
- Fill in a label and recipients (can be anything) and click 'Save'
- Click on the error next to edit below operations of the newly created form and select 'Manage Fields'
- Click 'Create new field'
- Select 'Date and time' and click 'Continue'
- Fill in the label, select 'Date' and click 'Continue'
- Leave settings as is and click 'Save settings'
- Go to 'Manage form display'
- Click on the select option 'Date and time' of the newly created date field, choose 'Select list' and click on 'Save'
- Click on view to see the date field in the Drupal front-end
I think we should. I see no valid reason or argument to put the prefix before the description, so it seems like a mistake or bug. The prefix is mostly used to indicate what value the user needs to enter, such as a currency.
@jrockowitz: Thanks again for pointing this out. I've created an issue for Drupal core: https://www.drupal.org/project/drupal/issues/3459838#comment-15672940 🐛 Prefix is shown before description Active
I'm using the Olivero theme as well. Have you set the 'Description display' to 'Before'? In your screenshot the Description is displayed after the field.
This issue is still (or again) present in 6.2.3.
Jean-Paul Vosmeer → credited rroose → .
I will report this as a Drupal Core issue then.
Thanks for pointing me in the right direction!
Thanks apaderno.
Apparently a space in one of the summaries causing the feed to not validate.
It's fixed now.
Default expected behaviour would be showing the labels above the select fields because, as you can see in the code, they are actively being hidden creating all sorts of usability problems.
My suggestion would be to adhere to the default behaviour and give users to option to hide the labels.
Everything can be changed by using custom code ;) But I think we should work towards a more accessible, user-friendly Webform module out of the box. That's why I created this issue.