We are experiencing this issue as well. I applied the patch to 3.0.1 successfully. However, as others have noted, the block content was no longer displayed. I tried completely uninstalling, deleting all blocks and config, removed the module and code completely from my code base, and then reinstalling, applying the patch, and re-configuring, but the languages still were not displayed. We reverted everything and applied a modified block preprocess function (see: https://www.drupal.org/project/gtranslate/issues/3396734#comment-15402378 🐛 Doesn't work correctly when 2 gtranslate blocks are enabled Active ) to remove the duplicate block content being generated.
We are experiencing this issue as well. We used a modified version of the preprocessor function in #8 🐛 Doesn't work correctly when 2 gtranslate blocks are enabled Active to address. This fixed the problem for us.
If I enabled Ignore Case in Search API Processors, the value was displayed. If I disabled Ignore Case, the Label was displayed as expected.
I am running into the same issues as documented in comment #302 🐛 Entity view/form mode formatter/widget settings have no translation UI Needs review
Should add that this occurred on Drupal 10.3.2.
Patch attached.
sassafrass → created an issue.
Having a similar issue after updating from D10.3 from D10.2. Error: InvalidArgumentException: "0" is an invalid render array key. Value should be an array but got a string. in Drupal\Core\Render\Element::children() (line 97 of /var/www/html/web/core/lib/Drupal/Core/Render/Element.php).
Stack trace:
#0 /var/www/html/web/core/lib/Drupal/Core/Field/FormatterBase.php(103): Drupal\Core\Render\Element::children(Array)
#1 /var/www/html/web/core/lib/Drupal/Core/Entity/Entity/EntityViewDisplay.php(268): Drupal\Core\Field\FormatterBase->view(Object(Drupal\smart_date\Plugin\Field\FieldType\SmartDateFieldItemList), 'en')
#2 /var/www/html/web/core/lib/Drupal/Core/Entity/EntityViewBuilder.php(340): Drupal\Core\Entity\Entity\EntityViewDisplay->buildMultiple(Array)
#3 /var/www/html/web/core/modules/node/src/NodeViewBuilder.php(24): Drupal\Core\Entity\EntityViewBuilder->buildComponents(Array, Array, Array, 'full')
#4 /var/www/html/web/core/lib/Drupal/Core/Entity/EntityViewBuilder.php(282): Drupal\node\NodeViewBuilder->buildComponents(Array, Array, Array, 'full')
#5 /var/www/html/web/core/lib/Drupal/Core/Entity/EntityViewBuilder.php(239): Drupal\Core\Entity\EntityViewBuilder->buildMultiple(Array)
#6 [internal function]: Drupal\Core\Entity\EntityViewBuilder->build(Array)
#7 /var/www/html/web/core/lib/Drupal/Core/Security/DoTrustedCallbackTrait.php(113): call_user_func_array(Array, Array)
#8 /var/www/html/web/core/lib/Drupal/Core/Render/Renderer.php(870): Drupal\Core\Render\Renderer->doTrustedCallback(Array, Array, 'Render #pre_ren...', 'exception', 'Drupal\\Core\\Ren...')
#9 /var/www/html/web/core/lib/Drupal/Core/Render/Renderer.php(432): Drupal\Core\Render\Renderer->doCallback('#pre_render', Array, Array)
#10 /var/www/html/web/core/lib/Drupal/Core/Render/Renderer.php(248): Drupal\Core\Render\Renderer->doRender(Array, false)
#11 /var/www/html/web/core/lib/Drupal/Core/Render/MainContent/HtmlRenderer.php(238): Drupal\Core\Render\Renderer->render(Array, false)
#12 /var/www/html/web/core/lib/Drupal/Core/Render/Renderer.php(638): Drupal\Core\Render\MainContent\HtmlRenderer->Drupal\Core\Render\MainContent\{closure}()
#13 /var/www/html/web/core/lib/Drupal/Core/Render/MainContent/HtmlRenderer.php(239): Drupal\Core\Render\Renderer->executeInRenderContext(Object(Drupal\Core\Render\RenderContext), Object(Closure))
#14 /var/www/html/web/core/lib/Drupal/Core/Render/MainContent/HtmlRenderer.php(128): Drupal\Core\Render\MainContent\HtmlRenderer->prepare(Array, Object(Symfony\Component\HttpFoundation\Request), Object(Drupal\Core\Routing\CurrentRouteMatch))
#15 /var/www/html/web/core/lib/Drupal/Core/EventSubscriber/MainContentViewSubscriber.php(90): Drupal\Core\Render\MainContent\HtmlRenderer->renderResponse(Array, Object(Symfony\Component\HttpFoundation\Request), Object(Drupal\Core\Routing\CurrentRouteMatch))
#16 [internal function]: Drupal\Core\EventSubscriber\MainContentViewSubscriber->onViewRenderArray(Object(Symfony\Component\HttpKernel\Event\ViewEvent), 'kernel.view', Object(Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher))
#17 /var/www/html/web/core/lib/Drupal/Component/EventDispatcher/ContainerAwareEventDispatcher.php(111): call_user_func(Array, Object(Symfony\Component\HttpKernel\Event\ViewEvent), 'kernel.view', Object(Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher))
#18 /var/www/html/vendor/symfony/http-kernel/HttpKernel.php(186): Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch(Object(Symfony\Component\HttpKernel\Event\ViewEvent), 'kernel.view')
#19 /var/www/html/vendor/symfony/http-kernel/HttpKernel.php(76): Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object(Symfony\Component\HttpFoundation\Request), 1)
#20 /var/www/html/web/core/lib/Drupal/Core/StackMiddleware/Session.php(53): Symfony\Component\HttpKernel\HttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#21 /var/www/html/web/core/lib/Drupal/Core/StackMiddleware/KernelPreHandle.php(48): Drupal\Core\StackMiddleware\Session->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#22 /var/www/html/web/core/lib/Drupal/Core/StackMiddleware/ContentLength.php(28): Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#23 /var/www/html/web/core/modules/big_pipe/src/StackMiddleware/ContentLength.php(32): Drupal\Core\StackMiddleware\ContentLength->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#24 /var/www/html/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(191): Drupal\big_pipe\StackMiddleware\ContentLength->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#25 /var/www/html/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(128): Drupal\page_cache\StackMiddleware\PageCache->fetch(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#26 /var/www/html/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(82): Drupal\page_cache\StackMiddleware\PageCache->lookup(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#27 /var/www/html/web/core/lib/Drupal/Core/StackMiddleware/ReverseProxyMiddleware.php(48): Drupal\page_cache\StackMiddleware\PageCache->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#28 /var/www/html/web/core/lib/Drupal/Core/StackMiddleware/NegotiationMiddleware.php(51): Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#29 /var/www/html/web/core/lib/Drupal/Core/StackMiddleware/AjaxPageState.php(36): Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#30 /var/www/html/web/core/lib/Drupal/Core/StackMiddleware/StackedHttpKernel.php(51): Drupal\Core\StackMiddleware\AjaxPageState->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#31 /var/www/html/web/core/lib/Drupal/Core/DrupalKernel.php(741): Drupal\Core\StackMiddleware\StackedHttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#32 /var/www/html/web/index.php(19): Drupal\Core\DrupalKernel->handle(Object(Symfony\Component\HttpFoundation\Request))
#33 {main}
I created a patch off of the 2.x branch that allows direct publishing that I am successfully using on my local. I've added an option to the entity form to "Allow direct publishing". If it is checked and the user Publishes content that has been scheduled for a date in the future, the content is directly published. If this is something that the module owners want to include, I'm happy to continue working on this as they see fit.
I have tried to add a hook_form_alter to the content_moderation_entity_moderation_form to add a custom validator that includes the PublishStateConstraintValidator from Drupal\scheduler_content_moderation_integration\Plugin\Validation\Constraint. Unfortunately, the PublishStateConstraintValidator expects the $value to come from the entity as opposed to the form. As a result, it is getting the current moderation_state from the node entity, rather than the new_state from the content_moderation_entity_moderation_form.
Without knowing what direction this module is planning on taking with respect to direct publishing of content, I don't know how best to contribute at this point.
I believe I have narrowed this down. The use case is specific to directly Publishing a scheduled piece of content. If the Moderation transition from Published to Published is not allowed, you get an error preventing you from directly publishing from the Node edit form. Nothing is changed. However, under the following scenario, content can be put in an unexpected state.
If you use the Node Revision Form and the Moderation transition from Published to Published IS NOT allowed by your workflow, the user is not prevented from selecting the Publish state. It appears successful except:
- The Content Overview page shows the content as Unpublished.
- The Node edit form shows the content as Published and hides the Publish on fields even though they are still set.
- The Content Moderation page no longer displays the content.
- The Scheduled Content page shows the content as still Scheduled.
- Cron runs continually fail.
If the Moderation transition from Published to Published IS allowed by your workflow, the user is not prevented from selecting the Publish state. It appears successful except:
- The Content Overview page shows the content as Unpublished.
- The Node edit form shows the content as Published and hides the Publish on fields even though they are still set.
- The Content Moderation page no longer displays the content.
- The Scheduled Content page shows the content as still Scheduled.
- Cron runs fail until the original content Scheduled time.
I believe some of the errors I was experiencing have to do with somehow being able to not set the Published state and still schedule the content...which results in a cron error. I'm still investigating with my client.
Yeah… wasn’t sure where to post and I have already posted it there. Thanks!!
Changing title and priority.
Actually... this may be even more significant than i initially thought. It seems that any Scheduled content cannot change its moderation state from the Latest Revision Form page. The state can only be changed from the node edit page.
Note: The cryptic message in step 2. says, "'The scheduled publishing state of Publish is not a valid transition from the current moderation state of Publish for this content.';" which is generated by the Drupal\scheduler_content_moderation_integration\Plugin\Validation\Constraint\ PublishStateConstraint class.
sassafrass → created an issue.
sassafrass → created an issue.
I believe there is a use case that is not completely addressed. If I have a piece of content scheduled for the future and I navigate to the "Latest Revision" tab from the node edit page, I am not prevented from selecting a Publish state. A success message is displayed saying,
Node Title is scheduled to be published June 30, 2024 - 4:40pm.
The moderation state has been updated.
No error is displayed. No actual change is made either. The user may think that they have directly published the content, when in fact it is still in an Unpublished state. Is this something that can/should be addressed in this module or in the Scheduler module?
I am encountering a related issue. Given the following scenario: A user creates a piece of content that gets reviewed and placed in an Approved State immediately prior to being Published. Content must be an Approved State in order to be Scheduled for Publishing. On the Node Edit page, if the user tries to directly publish while there is still a Scheduled Date/Time, an error is displayed as expected: "The scheduled publishing state of published is not a valid transition from the current moderation state of published for this content." However, if I go to the Latest Revision page, I am allowed to set the node to a Published state without an error, the node remains unpublished, and previous versions become inaccessible.
Suggested behaviors: Either allow instant Publishing in both use cases (preferred), or prevent saving and display an error in both cases indicating that the Schedule Date needs to be removed to Publish instantly.
Applied the latest patch and it hides a single Display as expected. However, I was wondering if it also makes sense to hide the View selection if there is only one View as well? Or to give users the option to hide those fields?
Confirming that the latest patch fixed the issue for me.
Using: drupal/migrate_tools": "6.0.x-dev@dev"
Cannot apply patch
https://www.drupal.org/files/issues/2024-03-11/3378047-21.patch →
Cannot apply patch
https://www.drupal.org/files/issues/2024-03-11/3378047-21.patch →
This is working as expected using a the /print/pdf/webform_submission/... path rather than the /webform/webform_id/submissions/ path. This can be closed.
I can get to this to work using the access token from webform submission. This can be closed.
I have the same issue.
Patch https://www.drupal.org/files/issues/2024-03-20/2902164-166.patch → applied cleanly for me on: Drupal core 10.2.4 and Conditional Fields 4.x-dev@dev. Thanks!
I also experience the error reported in #188. In addition, I am unable to create any new filter text formats because I am unable to select CKEditor5 as the text editor. I get an error indicating that I must select and configure it when I try to save. I removed the patch to create the new filter, but am now experiencing the original plugin error reported.
I applied the patch in MR!177 and am still getting the same error.
I first tried the patch: 2881776-packaged-45.patch to the latest stable version Field Permissions: 8.x-1.3 and it applied cleanly. However, I get the following error when trying to save a new field permission:
The website encountered an unexpected error. Try again later.
RuntimeException: Adding non-existent permissions to a role is not allowed. The incorrect permissions are "create field_sidebar_sections", "edit own field_sidebar_sections", "view own field_sidebar_sections". in Drupal\user\Entity\Role->calculateDependencies() (line 207 of core/modules/user/src/Entity/Role.php).
Drupal\Core\Config\Entity\ConfigEntityBase->preSave(Object) (Line: 179)
Drupal\user\Entity\Role->preSave(Object) (Line: 528)
Drupal\Core\Entity\EntityStorageBase->doPreSave(Object) (Line: 483)
Drupal\Core\Entity\EntityStorageBase->save(Object) (Line: 257)
Drupal\Core\Config\Entity\ConfigEntityStorage->save(Object) (Line: 352)
Drupal\Core\Entity\EntityBase->save() (Line: 609)
Drupal\Core\Config\Entity\ConfigEntityBase->save() (Line: 96)
Drupal\field_permissions\Plugin\FieldPermissionType\CustomAccess->submitAdminForm(Array, Object, Object) (Line: 154)
field_permission_field_config_edit_form_submit(Array, Object)
call_user_func_array('field_permission_field_config_edit_form_submit', Array) (Line: 129)
Drupal\Core\Form\FormSubmitter->executeSubmitHandlers(Array, Object) (Line: 67)
Drupal\Core\Form\FormSubmitter->doSubmitForm(Array, Object) (Line: 597)
Drupal\Core\Form\FormBuilder->processForm('field_config_edit_form', Array, Object) (Line: 325)
Drupal\Core\Form\FormBuilder->buildForm(Object, Object) (Line: 73)
Drupal\Core\Controller\FormController->getContentResult(Object, Object)
call_user_func_array(Array, Array) (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 627)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 124)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array) (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 181)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 76)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 58)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 28)
Drupal\Core\StackMiddleware\ContentLength->handle(Object, 1, 1) (Line: 32)
Drupal\big_pipe\StackMiddleware\ContentLength->handle(Object, 1, 1) (Line: 106)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 85)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 36)
Drupal\Core\StackMiddleware\AjaxPageState->handle(Object, 1, 1) (Line: 51)
Drupal\Core\StackMiddleware\StackedHttpKernel->handle(Object, 1, 1) (Line: 704)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)
I then installed the 8.x-2.x-dev module version and tried to apply the patch: 2881776-packaged-45.patch. It couldn't apply.
I'm still experiencing this issue. Using Drupal 10.2
The website encountered an unexpected error. Try again later.
Symfony\Component\Routing\Exception\InvalidParameterException: Parameter "bundle" for route "content_entity_clone.bundle.field_settings" must match "[a-z0-9_-]+" ("~1" given) to generate a corresponding URL. in Drupal\Core\Routing\UrlGenerator->doGenerate() (line 209 of core/lib/Drupal/Core/Routing/UrlGenerator.php).
I have the same issue.
In the file: webform_clientside_validation.ife.js, if I comment this code out, this works as expected.
/**
* Fix date/time min, max, and step validation issues.
*
* @type {Drupal~behavior}
*
* @see https://github.com/jquery-validation/jquery-validation/pull/2119/commits
*/
/*Drupal.behaviors.webformClientSideValidationDateTimeFix = {
attach: function (context) {
$(context).find(':input[type="date"], :input[type="time"], :input[type="datetime"]')
.removeAttr('step')
.removeAttr('min')
.removeAttr('max');
}
};*/
sassafrass → created an issue.
sassafrass → created an issue.
Hi. Thanks for creating the patch. I applied the patch successfully and although the Image to select is now at the top of the pane and scrolling is no longer needed, I now can no longer see the SELECT button to Select the image.
I believe this might be related: https://www.drupal.org/project/webform/issues/3419954 💬 'Attachment URL' element with tokens gives 'Connection refused for URI' error Active
Using:
"drupal/core-recommended": "^10.2"
"drupal/ckeditor_liststyle": "1.x-dev@dev"
Also getting the error in #14:
Drupal\Component\Plugin\Exception\InvalidPluginDefinitionException: The "ckeditor5_list" CKEditor 5 plugin definition is configurable, but its default configuration does not match its config schema. The following errors were found: [properties] missing schema, [multiBlock] missing schema. in Drupal\ckeditor5\Plugin\CKEditor5PluginDefinition->validateDrupalAspects() (line 190 of core/modules/ckeditor5/src/Plugin/CKEditor5PluginDefinition.php).
sassafrass → created an issue.
sassafrass → created an issue.
sassafrass → created an issue.
Thanks for such a thoughtful and thorough explanation!!
sassafrass → created an issue.
Although patch: " https://www.drupal.org/files/issues/2022-11-28/3308143-date-range-offset... → " applies correctly, it looks like the default timezone is being changed to UTC, despite it being set as New York in my Drupal setup.
I can see that when I inspect the webform submission using Xdebug and by looking in Drupal's file system that what you say is true for any files uploaded to the webform by the submitter. However, fields of type attachment that generate a pdf of the submitted form (please see the example form and screenshot), are generated AFTER the form is submitted and does not seem to be available in the file system. I can only access them via the url generated by Webform after the file is generated.
I have a client requirement to upload that attachment to their BOX client via an API.
Actually this is because of how I've configured the date formats. That being said I've configured it this way to get around the issue reported here: https://www.drupal.org/project/smart_date/issues/3389649 🐛 Can't get rid of space between Date and Date/time join character Active which is still happening on 4.1.x-dev@dev.
Thank-you for your patience. :-)
I want to programmatically download a Webform attachment without having to open up the permissions to access the Webform attachment to anonymous users.
I am writing a custom module with a custom Web Handler on a Drupal site.
Actually I just tried curl again, and for some reason that worked this time. I don't know what's different.
The "programatically" aspect of this ticket is key to me. :-) I have tried the following to access the attachment link from a custom Webform Handler:
$account = User::load(1);
$this->accountSwitcher->switchTo($account);
// Save and get the submission results. This is all successful except when trying to download the attachment with:
file_put_contents($destination, file_get_contents($attachment_url)); // Works if Anonymous users have "Administer webforms" permission. Doesn't work otherwise.
$this->httpClient->get($source, $this->configuration['guzzle_options']); // Denied access unless Anonymous users have "Administer webforms" permission.
curl url/to/attachment/path // Administrator has access to download but the file is malformed (the file has been damaged (for example, it was sent as an email attachment and wasn't correctly decoded).
$this->fileSystem->saveData($attachment_url, $destination, FileSystemInterface::EXISTS_REPLACE); // Administrator has access to download but the file is malformed (the file has been damaged (for example, it was sent as an email attachment and wasn't correctly decoded).
sassafrass → created an issue.
I have updated my environment to the following:
Drupal core 10.1.6
Webform 6.2.0
I have imported the attached webform and tested a submission. Submission works as expected. Attachment is generated as expected and can be accessed via the submission ui. However, it is not automatically downloaded as expected according to the config (see screenshot).
It was on 6.1, but I'll update to 6.2 and re-test.
I still have not been able to resolve this. Could someone perhaps guide me on how I could fix this? I am willing to try to write a patch or a custom module, but I'm not sure where to begin.
Patch: 3308143-date-range-offset-3.patch worked for me. Thanks!
Thank-you! Patch worked for me!
Thanks for the patch. I found it very confusing to not have the value 1 save. It wasn't intuitive to me that it was the default; I thought it was broken.
sassafrass → created an issue.
sassafrass → created an issue.
@Carlitus - This is fantastic! Is it possible to get a re-roll of your patch for 8.x-2.0?
I have applied the patch #11 , working as expected now the required(*) symbol in showing on the radio field . Thanks!
Okay. Thanks. I was looking for a way to reset the time or select the --:--:--. I didn't realize you selected the time and clicked delete. Closing and marking as works as expected.
sassafrass → created an issue.
I agree that this is functioning as expected and it's just the asterisk that is not displaying. I've changed the issue title to reflect that. The asterisk does display as expected for field types other than radio buttons so I think it's specific to that field type. That being said, this patch un-does important functionality in that it removes the required functionality from hidden fields that are required, if they remain hidden (not used) when the form is submitted. I don't think we want to remove that functionality. We just want the asterisk to display on the radio buttons like it does for the other fields.
sassafrass → created an issue.
sassafrass → created an issue.
sassafrass → created an issue.
Awesome! That worked! Thank-you so much!
sassafrass → created an issue.
sassafrass → created an issue.
sassafrass → created an issue.
Same
sassafrass → created an issue.
Successfully using latest merge request in production. Thanks!
Also trying to figure out how to migrate a reusable, paragraph_library_item.
sassafrass → created an issue.
sassafrass → created an issue.
I agree - In my use case only the Administrator Role can use this feature but it appears in the modal for other roles as well when selecting Media from the Media Library in the modal.
I am testing using the latest patch. In my yaml, I am using the paginator type because the urls provided in the JSON endpoints are not valid for my use case.
urls:
- http://services.baltimorecountymd.gov/api/hub/pets/pets?status=Adoptable
- http://services.baltimorecountymd.gov/api/hub/pets/pets?status=Lost
pager:
type: paginator
selector: /metaData/
paginator_type: page_number
default_num_items: 10
page_key: page
size_key: recordsPerPage
The paginated urls are generated as expected. However, it never stops generating urls. Urls being generated are valid but have no records. For example see: https://services.baltimorecountymd.gov/api/hub/pets/pets?status=Adoptabl....
My particular use case has non-scalar $selector_data but the JSON is not in format expected by this segment of code, which always evaluates to true.
else {
// If we have an array of rows
if (count($selector_data) > 0) {
$next_urls[] = Url::fromUri($path['path'], [
'query' => $path['query'],
'fragment' => $path['fragment'],
])->toString();
}
}
}
I would like to use this feature and was wondering what the latest status was?
Confirmed patch #54 works for me on 10.1
So this was due to the fact that I had a space after my url in my environment variable. Removing the space resolved the issue.
sassafrass → created an issue.
So this came down to an edge case where our custom theme is trying to load fonts into a WYSWIG, which fails when that WYSIWYG is in a modal. Closing - Works as designed. Thanks!
Thanks for the quick response. I think you are right and this may be due to a core issue given your comment and the fact that I see the following issues in the console:
webform:1 Refused to execute script from 'https://fonts.googleapis.com/css?family=Crimson+Text:400,400i,600,600i%7CMontserrat:300,400,600,700&display=swap' because its MIME type ('text/css') is not executable, and strict MIME type checking is enabled.
ajax.js?v=10.1.0:1118 An error occurred during the execution of the Ajax response: The following files could not be loaded: //fonts.googleapis.com/css?family=Crimson+Text:400,400i,600,600i|Montserrat:300,400,600,700&display=swap1
(anonymous) @ ajax.js?v=10.1.0:1118
sassafrass → created an issue.
sassafrass → created an issue.
This doesn't work for me either in D10. In D9, I used file_import rather than image_import and that worked.
sassafrass → created an issue.
I think this is working as intended. If I understand correctly, the Group roles are only selectable if they are not set to synchronize with the Global roles...they are only selectable if they are configured for Individual scope. Please close.
This is my error. Additional Group Roles don't show up unless their are Global Drupal roles other than Anonymous, Authenticated, and Admin. Close.