I just wanted to mention that the solution of #20 by @yannickoo → works fine when still receiving 404-errors after updating Webform to 6.2.8 :
FYI after applying the patch it was needed to run composer update jquery/icheck so that the new URL of the libraries is changed in composer.lock file as well ✨
Applying the change locally on a Drupal 10 install works fine. After applying the change, the 'Drupal Upgrade Status' reports the module being compatible with Drupal 11 (also after manually scanning the module). Because the change only appends version 11 to the `core_version_requirement` , together with the Drupal Upgrade Status report I feel safe to say that this is good to go.
I think I am experiencing a very similar issue, except that I don't have any problems with nodes but with pages from views that should be added to the sitemap. The individual nodes are all correctly added to the sitemap (only the non-english version, using the correct canonical url), but the pages from a view that has been added to the sitemap (using "Simple XML Sitemap (Views)") are included both in the English and non-english language, even tough the view and all the nodes in the view are all configured to use the non-english language.
How about just having a visible handle for the honeypot field in the form editor that allows to control its position (and the underlying weight) on the form? Similar to how https://www.drupal.org/project/manage_display → would allow you to manage the position of a node’s title on the ‘Manage Display’ tab of the node configuration, I can imagine this could work pretty well for the honeypot field as well. It would need some logic to ensure this is only visible on forms that have the honeypot field enabled, but that sounds doable. This would be more convenient than having to input a specific weight, especially as the weights might change when adding or removing fields on the form.
D'OH!
After submitting this issue, I had another look and I found the culprit:
I had earlier applied a patch for D10 / PHP 8.2 compatibility provided by issue #3328670, patch in #2 📌 PHP 8.2 compatibility Fixed . Apparently that patch still applied without issues agains release 1.12, that does also include the final fix for that issue and should not require the patch any more. After removing the patch, re-installing the module using composer and clearing the cache everything works great again!
I'll close the issue, hoping that my findings might still help someone one day :)
I also tried enabling the new experimental menu setting after updating Gin to 8.x-3.0-rc7 and Gin_Toolbar to 1.0.0-rc4 . However, the logs show a different error :
Error: Class "Drupal\block_content\Entity\BlockContentType" not found in Drupal\gin\GinNavigation->getNavigationCreateMenuItems() (line 88 of /var/www/html/web/themes/contrib/gin/src/GinNavigation.php).
I'm not sure if this is a Gin or Gin_Toolbar problem...
I hadn’t thought about that, seems to be a fair point (although I’m not sure if I would go as low as 30%, but that’s a concern for later).
While my suggestion from #19 is not yet what I would call ‘out of the box’, it would be much easier to configure for a large amount of image sizes/ratios. Of course, it would be possible to supply some (optional) default configuration, that e.g. provides the 4/3 ratio by default with some common used widths (320px … 1200px … 2500px?) in 1x and 2x multipliers, in WebP?
How about an interface where instead of generating image styles, you can define aspect ratios to use (e.g. 1/1, 4/3, 16/9, etc). Then, for each aspect ratio, you can (manually) define the widths for which to generate image styles (e.g. 120px, 320px, 640px, 1200px, etc). Additionally, you could enter / select a range of multipliers (1x, 1.5x, 2x, 3x, 4x) to use. All that combined will result in a matrix that can generate all required image styles beforehand without the need for Javascript during runtime. Added benefit is that because the aspect ratio is the same, the image styles for the larger breakpoints can also be injected into the smaller breakpoint (e.g 2x 640x480 can also be used as 1x 1280x960).
This does allow the freedom to decide which breakpoints and image sizes to generate.
As noted by @cilefen, I've created a Core issue as suggested: #3378038 - Anonymous and Authenticated roles are deletable 🐛 Anonymous and Authenticated roles are deletable Active .
After a day of thinking and researching, I can confirm that it happens to be exactly the same case as reported initially by @hockey2112 : On my environment, the 'authenticated' role was missing. After restoring the authenticated role from git history, creating or editing webforms works again as expected.
I understand that this is an edge-case that won't occur on all installations, but I still believe it is a valid bug that should be fixed.
The question why the authenticated role is not present on all installations, is something outside of the scope of the webform module's responsibility. In @hockey2112's case it might have been a different module's uninstall hook, in my case it was 'simple' developer malfunction (Apparently I had deleted the user.role.authenticated.yml file and imported the configuration afterwards, resulting in deleting the authenticated role).
However, the bug that remains is that if the authenticated user role is missing, newly added or edited webform fields won't appear in the view or test tab when logged in as root/admin/super-user/uid:1 (very likely to happen for all logged-in users, but I only tested/confirmed this for the Administrator role). There is no visible error, no validation that fails and nothing in the logs when this occurs, making it a very difficult problem to debug.
Possible solutions might include logging an error in the logs (e.g. when the form and/or element is saved), preventing the form from being saved by adding some validation that fails when the authenticated role is not present, adding checks in the module code to verify the existence of the authenticated role before it is being checked, or instead of querying the authenticated role adding fallbacks to check if the current user has permissions to create new form submissions, even if the user does not have the 'authenticated' role.
(I didn't change the original issue summary, but feel free to do so based on the new findings. I did try to make the issue title reflect the actual bug more)
I would like to re-open this issue, as I am experiencing the same issue as reported by @hockey2112. Hopefully I am able to provide some more context and steps to reproduce the issue.
Environment
I am using Drupal 10.1.1, PHP 8.2.5 and Webform 6.2@beta6 . The site (work in progress) currently does not have any custom module-code apart from a single unrelated block plugin. There is a custom theme, but that does not contain any logic and only supplies override templates and libraries with custom css/js. Theme debug shows the webform fields being rendered with the templates from the stable9 theme from D10 core. I have only enabled the webform and webform_ui (sub)modules. No patches have been applied to the webform module, and only a limited number of other contrib modules (unrelated to webform functionality) is present.
Steps to reproduce
- Start with a minimal Drupal installation using the version numbers described above.
- Log in as an Administrator user and perform all steps below as admin.
- Install and enable the Webform 6.2-beta6 module and the webform_ui module
- Navigate to admin/structure/webform , there should be a 'Contact' webform created by default
- View (or 'Test') the Contact webform, and confirm the 'Your Name', 'Your Email', 'Subject' and 'Message' fields are present, as well as the 'send message' button.
- Go to the 'Export' tab, and confirm the configuration for the 'name' field element looks as follows:
elements: |
name:
'#title': 'Your Name'
'#type': textfield
'#required': true
'#default_value': '[current-user:display-name]'
- Go to the 'Build' tab, and edit the 'Your name' field
- Change the title to something else (e.g. 'My name'), save the element and then save the form.
- Go to the 'View' or 'Test' tab, and notice the changed field is missing.
- Go to the 'Export' tab, and notice the configuration for the field includes more changes than the ones made above:
elements: |-
name:
'#type': textfield
'#title': 'My Name'
'#required': true
'#default_value': '[current-user:display-name]'
'#format_items': comma
'#access_create_roles':
- anonymous
'#access_update_roles':
- anonymous
'#access_view_roles':
- anonymous@seanB, @GaëlG :
> To do this in Drupal, I have to use the webp contrib module (or some other contrib/custom module).
> - @GaëlG
> Output WebP for image by default
> This is currently done using the WebP module or ImageAPI Optimize WebP. I agree, it would be nice if core would just do this.
> - @seanB
As of Drupal 9.2 according to @heddn in #3 above, Core is able to provide WebP support out-of-the-box for images styles. It is hidden away out of sight, so I do agree it is hard to find. To enable it, you have to add the 'Convert' action to an image style, and you will be able to select WebP as the desired format. I think that the fallback issue should still be solved in Core, but for now it seems that the https://www.drupal.org/project/wpf → (WebP Fallback Image) module is able to handle that in a nice way without the need for additional configuration or setup. What I like about this approach is that the site will be serving WebP images by default, and will only need to do additional processing for the fallback images that are required.
I do agree that it is pretty time-consuming nowadays to setup high-performance using Core. With more and more different images sizes, pixel-densities (2x is considered 'default' by now, 3x is already being used by modern iDevices but not often implemented, and its just a matter of time before the 4X multiplier will be introduced...) . If you would want to support all that for a full-width hero-image (which is a common use-case), also providing efficient images for use on mobile, you will already need quite some configuration and setup. Having something that makes this easier (e.g. the module mentioned/created by @seanB) would be much appreciated.
Interesting, having the same issue. Digging slightly further, I found that composer sources the linkit versions/packages from https://packages.drupal.org/files/packages/8/p2/drupal/linkit.json and https://packages.drupal.org/files/packages/8/p2/drupal/linkit~dev.json , where the 6.1.0-rc2 version is nowhere to be found. According to https://www.drupal.org/docs/develop/using-composer/using-packagesdrupalorg → , the solution would be for @mark_fullmer to file an issue here: https://www.drupal.org/project/issues/project_composer → . A new release might also possibly fix this.
I had the same problem as @jrochate's reported.
After some trial and error, I think I found out what the problem is:
- linkit 6.0@RC requires Drupal-core version to be with 10.0.X range
- linkit 6.1@RC requires Drupal-core version to be within 10.1.X range
What happens is that when running composer update "drupal/core-*" --with-all-dependencies (as instructed on
the release 10.1 page →
), it won't actually update core-recommended to 10.1 as that wouldn't match the constraints allowed by linkit 6.0@rc (so having linkit 6.0 as a dependency prevents upgrading to Drupal 10.1). However, the other way around also won't work: You can't update linkit to 6.1@rc if your Drupal/core(-recommended) is still on 10.0, as that wouldn't match the version constraints provided by linkit 6.1 (which requires Drupal 10.1 to already be installed).
The workaround I ended up using is to update both dependencies in one go:
composer update drupal/core-* drupal/linkit:^6.1@RC --with-all-dependencies (which will work given that Drupal 10.0 and linkit 6.0 were already required in the project earlier and their versions are not constant in the composer.json file).
I hope this might save some of you some time!