Thanks for the reply :) This was quite a while ago because we switched to layout builder from panels. We ended up creating static exports -1 year, -6 months, -3 months and -1 month and this seems to have worked because no complaints from users.
These are webform submissions fields in views, which it may be a webform issue. I'll try working on this display again at some point to see if anything has changed.
We are getting some page timeouts with similar logs. It seems to only happen when it is yet to be cached. Upon refresh of the url, after the "unexpected error..." message on a white page, it will load. I've not tried the patch yet.
Drupal\Core\Database\DatabaseExceptionWrapper: SQLSTATE[HY000]: General error: 3024 Query execution was interrupted, maximum statement execution time exceeded: SELECT DISTINCT "t"."nid" AS "nid" FROM "taxonomy_index" "t" WHERE "t"."nid" NOT IN (:db_condition_placeholder_0, :db_condition_placeholder_1, :db_condition_placeholder_2, :db_condition_placeholder_3, :db_condition_placeholder_4, :db_condition_placeholder_5, :db_condition_placeholder_6, :db_condition_placeholder_7, :db_condition_placeholder_8, :db_condition_placeholder_9, :db_condition_placeholder_10, :db_condition_placeholder_11, :db_condition_placeholder_12, :db_condition_placeholder_13, :db_condition_placeholder_14, :db_condition_placeholder_15, :db_condition_placeholder_16, :db_condition_placeholder_17, :db_condition_placeholder_18, :db_condition_placeholder_19, :db_condition_placeholder_20, :db_condition_placeholder_21, :db_condition_placeholder_22, :db_condition_placeholder_23, :db_condition_placeholder_24, :db_condition_placeholder_25, :db_condition_placeholder_26); Array ( [:db_condition_placeholder_0] => 7569 [:db_condition_placeholder_1] => 7570 [:db_condition_placeholder_2] => 7571 [:db_condition_placeholder_3] => 7572 [:db_condition_placeholder_4] => 7573 [:db_condition_placeholder_5] => 7574 [:db_condition_placeholder_6] => 7575 [:db_condition_placeholder_7] => 7576 [:db_condition_placeholder_8] => 7626 [:db_condition_placeholder_9] => 7976 [:db_condition_placeholder_10] => 7977 [:db_condition_placeholder_11] => 8453 [:db_condition_placeholder_12] => 8806 [:db_condition_placeholder_13] => 1645 [:db_condition_placeholder_14] => 1646 [:db_condition_placeholder_15] => 1647 [:db_condition_placeholder_16] => 1648 [:db_condition_placeholder_17] => 1649 [:db_condition_placeholder_18] => 1650 [:db_condition_placeholder_19] => 1651 [:db_condition_placeholder_20] => 1652 [:db_condition_placeholder_21] => 7577 [:db_condition_placeholder_22] => 7882 [:db_condition_placeholder_23] => 7890 [:db_condition_placeholder_24] => 8475 [:db_condition_placeholder_25] => 9211 [:db_condition_placeholder_26] => 7588 ) in Drupal\permissions_by_term\Service\AccessStorage->getUnrestrictedNids() (line 732 of /drupal/web/modules/contrib/permissions_by_term/src/Service/AccessStorage.php).
Note that the class changed for 10.3.1
.layout-region--main,
.layout-region--footer {
width: calc(100% - 2rem);
}
.layout-region--main .layout-region__content,
.layout-region--footer .layout-region__content {
max-width: 100%;
margin-right: auto;
margin-left: auto;
}We've received 500+ spam submissions today (11/22/2024) for one form that we have. We had to close the form.
Thank you for the patch so quickly, although it did not apply with composer.
Thank you for the patch. I attempted to apply the patch and it is failing. When I manually make the changes in the files it works as expected.
This should be good to go
@19, we should be able to set the default as disabled or enabled per content type
Sure thing, sounds good, thank you
Hi bspeare, thanks for your work on this. We can work around it, it's not a big issue for us.
In dev I upgraded to 10.3.4, tried https://git.drupalcode.org/issue/better_exposed_filters-3444996/-/tree/2... and getting same result as #30.
When inspecting the output, " filters" are coming before the other "
10.2.6
@block_2 is the one testing
I tested and it puts it back within the collapsible secondary. However, the order is not consistent with "Filter criteria" order. When editing BEF, the order is correct, but not when displayed. Images show testing of the Start and End Date fields, making them collapsible within secondary.
...just to make sure, for us the 7.0.x-dev version from June 11, 2024 and 10.2.6 is still an issue.
Our original issue started after 6.0.3 and after we updated Drupal core to 10.2.6. Maybe there is some core or other dependency that changed? It seems to be JS or layout related.
This example are collapsible (fields) within a collapsible area (secondary).
- Secondary options are collapsible.
- Upon checking "Make filter options collapsible" for the Start Date and End Date fields,
- they then display outside and in front of the collapsible area (secondary).
...hence the module name, External Links...sorry about that, closing. But yes, using this module to open files in new windows and that works as expected, thank you.
I'll try and help with an example. Let me know if needing something different.
This is for reporting Metrics which are displayed with the Claro theme. Claro is the admin theme, but we are using the Theme Switcher module to also use Claro for metrics displays.
There are more taxonomy fields but they are excluded in the example below.
Content Types
- Course - the base course information (body), some other long text fields, image, etc.
- Course Schedule - a time based event containing fields for schedule (date), participants (integer), select Course (entity reference), etc.
Format: Table
Header: Global results summary
Relationships: field_select_content (reverse)
Use aggregation: No
Caching: Time-based:12 hours/12 hours
Fields:
- Content: Title (Course)
- (field_select_content) Content: Title (Schedule)
- (field_select_content) Content: Actual (Participants)
- (field_select_content) Content: College Affiliation (College Affiliation)
- (field_select_content) Content: Schedule (Class Schedule)
Filter criteria:
- Content: Content type (= Course)
- Content: Title (exposed)
- (field_select_content) Content: College Affiliation (field_college_affiliation) (ef) (exposed)
- (field_select_content) Content: Schedule (exposed)
- (field_select_content) Content: Schedule:delta (= 0)
- (field_select_content) Content: Instructor(s):delta (= 0)
Exposed form:
type: bef
options:
submit_button: Apply
reset_button: true
reset_button_label: Reset
exposed_sorts_label: 'Sort by'
expose_sort_order: true
sort_asc_label: Asc
sort_desc_label: Desc
text_input_required: 'Select any filter and click on Apply to see results'
text_input_required_format: basic_html
bef:
general:
autosubmit: false
autosubmit_exclude_textfield: false
autosubmit_textfield_delay: 500
autosubmit_hide: false
input_required: false
allow_secondary: true
secondary_label: Filters
secondary_open: false
reset_button_always_show: false
filter:
title:
plugin_id: default
advanced:
placeholder_text: ''
collapsible: false
collapsible_disable_automatic_open: false
is_secondary: true
field_schedule_value:
plugin_id: bef_datepicker
advanced:
collapsible: false
collapsible_disable_automatic_open: false
is_secondary: true
field_college_affiliation_target_id_entityreference_filter:
plugin_id: default
advanced:
sort_options: false
rewrite:
filter_rewrite_values: '- Any -|All'
filter_rewrite_values_key: false
collapsible: false
collapsible_disable_automatic_open: false
is_secondary: true
I used config sync to export the BEF settings. When looking at that it seems that "Schedule" is ordered before "College Affiliation" which isn't the order of the exposed filters, but that may not have any bearing. When editing BEF settings the order is correct.
Hi, I tried 7.0.x-dev in development. Getting the same result.
We do have another View with a date exposed filter where no filters are secondary. If it is collapsible, the date filter is the first filter even though it is ordered to be the last.
When editing the View filters, it is last. When editing BEF in the View, it is last. But for the visitor it displays first. We are using Layout Builder and Claro for these displays, Drupal 10.2.6.
Unchecking collapsible puts it back in the right spot. This seems to be an issue with the date field or it maybe being a composite field.
Thank you we will try to move from 6.0.x-dev to 7.0.x this week which sounds like it will fix this issue.
Changing this to a feature request to make the number of openings displayed configurable from the UI.
---
Booking future time is separate from amount of bookings displayed. Booking future time is respected.
The amount of openings displayed on the Bookable Calendar is static located at bookable_calendar/src/Renderer.php line 105
$query->range(0, 100);
We are still using 6.0.x-dev at the moment. After an update, we are experiencing similar but only for date exposed filter that had "Make filter options collapsible" checked. The date field was collapsible within the secondary option. When unchecking "Make filter options collapsible" the date field then falls back under secondary option but it can't be collapsible.
views.view.booking_contact.yml would also need updating to My. Automated emails would make sense to stay Your.
I was finally able to get it updated. I guess it can't update the one entity with data.
- Delete all booking calendars and related data
- Then drush updb
Getting the same result.
---
Your booking was cancelled.
Booking Created: Wednesday, December 31, 1969 - 19:00 Booking Date: Wed, Dec 31 1969, 7pm
---
Ah, I think I see in the backtrace, multiple_select module is involved and it was recently added and also needed a patch.
"drupal/multiple_select": {
"Compatibility with module Field Group 8.x-3.4": "
https://www.drupal.org/files/issues/2023-06-26/multiple_select-compatibi... →
"
},
This is the issue. After uninstalling that module, webform is back to normal. Sorry for the trouble here, will close and post reference to here at multiple_select.
Thank you
#0 C:\xampp\htdocs\web\core\lib\Drupal\Core\Entity\ContentEntityBase.php(597): Drupal\Core\Entity\ContentEntityBase->getTranslatedField('default_langcod...', 'x-default')
#1 C:\xampp\htdocs\web\modules\contrib\multiple_select\multiple_select.module(51): Drupal\Core\Entity\ContentEntityBase->get('default_langcod...')
#2 C:\xampp\htdocs\web\modules\contrib\multiple_select\multiple_select.module(36): multiple_select(Array, Object(Drupal\Core\Form\FormState), 'webform_submiss...')
#3 C:\xampp\htdocs\web\core\lib\Drupal\Core\Extension\ModuleHandler.php(545): multiple_select_form_alter(Array, Object(Drupal\Core\Form\FormState), 'webform_submiss...')
#4 C:\xampp\htdocs\web\core\lib\Drupal\Core\Form\FormBuilder.php(841): Drupal\Core\Extension\ModuleHandler->alter('form', Array, Object(Drupal\Core\Form\FormState), 'webform_submiss...')
#5 C:\xampp\htdocs\web\core\lib\Drupal\Core\Form\FormBuilder.php(284): Drupal\Core\Form\FormBuilder->prepareForm('webform_submiss...', Array, Object(Drupal\Core\Form\FormState))
#6 C:\xampp\htdocs\web\core\lib\Drupal\Core\Entity\EntityFormBuilder.php(48): Drupal\Core\Form\FormBuilder->buildForm(Object(Drupal\webform\WebformSubmissionForm), Object(Drupal\Core\Form\FormState))
#7 C:\xampp\htdocs\web\modules\contrib\webform\src\Entity\Webform.php(1257): Drupal\Core\Entity\EntityFormBuilder->getForm(Object(Drupal\webform\Entity\WebformSubmission), 'add')
#8 C:\xampp\htdocs\web\modules\contrib\webform\src\Controller\WebformEntityController.php(77): Drupal\webform\Entity\Webform->getSubmissionForm()
#9 [internal function]: Drupal\webform\Controller\WebformEntityController->addForm(Object(Symfony\Component\HttpFoundation\Request), Object(Drupal\webform\Entity\Webform))
#10 C:\xampp\htdocs\web\core\lib\Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber.php(123): call_user_func_array(Array, Array)
#11 C:\xampp\htdocs\web\core\lib\Drupal\Core\Render\Renderer.php(627): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}()
#12 C:\xampp\htdocs\web\core\lib\Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber.php(124): Drupal\Core\Render\Renderer->executeInRenderContext(Object(Drupal\Core\Render\RenderContext), Object(Closure))
#13 C:\xampp\htdocs\web\core\lib\Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber.php(97): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array)
#14 C:\xampp\htdocs\vendor\symfony\http-kernel\HttpKernel.php(181): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}()
#15 C:\xampp\htdocs\vendor\symfony\http-kernel\HttpKernel.php(76): Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object(Symfony\Component\HttpFoundation\Request), 1)
#16 C:\xampp\htdocs\web\core\lib\Drupal\Core\StackMiddleware\Session.php(58): Symfony\Component\HttpKernel\HttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#17 C:\xampp\htdocs\web\core\lib\Drupal\Core\StackMiddleware\KernelPreHandle.php(48): Drupal\Core\StackMiddleware\Session->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#18 C:\xampp\htdocs\web\core\lib\Drupal\Core\StackMiddleware\ContentLength.php(28): Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#19 C:\xampp\htdocs\web\core\modules\page_cache\src\StackMiddleware\PageCache.php(106): Drupal\Core\StackMiddleware\ContentLength->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#20 C:\xampp\htdocs\web\core\modules\page_cache\src\StackMiddleware\PageCache.php(85): Drupal\page_cache\StackMiddleware\PageCache->pass(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#21 C:\xampp\htdocs\web\core\modules\ban\src\BanMiddleware.php(50): Drupal\page_cache\StackMiddleware\PageCache->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#22 C:\xampp\htdocs\web\core\lib\Drupal\Core\StackMiddleware\ReverseProxyMiddleware.php(48): Drupal\ban\BanMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#23 C:\xampp\htdocs\web\core\lib\Drupal\Core\StackMiddleware\NegotiationMiddleware.php(51): Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#24 C:\xampp\htdocs\web\core\lib\Drupal\Core\StackMiddleware\AjaxPageState.php(36): Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#25 C:\xampp\htdocs\web\core\lib\Drupal\Core\StackMiddleware\StackedHttpKernel.php(51): Drupal\Core\StackMiddleware\AjaxPageState->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#26 C:\xampp\htdocs\web\core\lib\Drupal\Core\DrupalKernel.php(704): Drupal\Core\StackMiddleware\StackedHttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#27 C:\xampp\htdocs\web\index.php(19): Drupal\Core\DrupalKernel->handle(Object(Symfony\Component\HttpFoundation\Request))
#28 {main}
"default_langcode" locations
webform.install.inc
\modules\contrib\webform\includes
content_translation.admin.inc
\core\modules\content_translation
install.core.inc
\core\includes
install.inc
\core\includes
update.fetch.inc
\core\modules\update
#4 will do today, just starting, thank you #4 and 5.
Replicated production on a clean dev. They are currently on D10.2.4 and webform 6.2.2. Installed Configuration Translation, Interface Translation, Language and Locale. Visit webform/configuration/translate
Warning message
In order to translate configuration, the website must have at least two languages.
Added a 2nd language
Visit webform/configuration/translate and seems fine
Visit webform/configuration/advanced and repair configuration
Flush cache
Visit a form, same error
Production has both drupal 10.2.4 and webfrom 6.2.2 but still broken with "invalidArgumentException: Field default_langcode is unknown"
The only difference is in development we restored a database from when it was 10.2.4 and it's working but we can't do that on production.
Downgrading to Drupal 10.2.4 and using webform 6.2.1 or 6.2.2 seems to have fixed this in development. There seems to be an introduction of requiring a default_langcode in core that causes an issue with webform.
Even after installing Configuration Translation and related modules in Drupal 10.2.5 or 10.2.6, no webforms are accessible.
It said "The website encountered an unexpected error. Try again later."
Log said
Error: Call to undefined method Drupal\Core\Entity\Sql\SqlContentEntityStorage::findMatchingRedirect() in Drupal\easy_breadcrumb\EasyBreadcrumbBuilder->getRequestForPath() (line 963 of C:\xampp\htdocs\modules\contrib\easy_breadcrumb\src\EasyBreadcrumbBuilder.php).
Example results before and after update on May 4.
This seems like the same or similar issue: https://www.drupal.org/project/webform_views/issues/3223991#comment-1558... 🐛 Problem with view filters Active
Everything was working until we did composer update over the weekend and this issue appeared.
We have a colleges exposed filter. Before when we passed the argument in the URL to the view, it would show all items for that argument. Example https://...?webform_submission_value[0]=37
Even though multiple Colleges/ID's are selected when completing the form, the view would still display any results for the college ID above.
After updating, the view only show results if only that single ID was selected while completing the form. It excludes results for the ID if multiple items are selected.
Additionally, providing a setting less than June 24, like +1 day or +3 weeks works. It seems there is a max threshold.
#7 and 2.0.x-dev updated 18 Sep 2023 at 16:45 UTC works with D10.2.6 and "field_group": "^3.x-dev"
Thank you for this module.
This may be a separate issue but seems related.
This also happens when using Print from the browser. If any color is used, including #ffffff, then the background is black. Only transparent works.
Our main problem is htaccess. We are going to need to do #145. It's better for us to review what changed rather than get the update and overwrite every time composer is used.
We have custom apps that require ssl. Composer updates/overwrites htaccess. If we don't immediately overwrite it with our custom version support requests start coming in. #132 sounds nice to be able to set common configurations to htaccess that stay in place no matter what core changes are done.
Issue still exists
InvalidArgumentException: The configuration property display.default.display_options.filters.webform_submission_value.value.575 doesn't exist. in Drupal\Core\Config\Schema\ArrayElement->get() (line 76 of C:\xampp\htdocs\d10\web\core\lib\Drupal\Core\Config\Schema\ArrayElement.php).
#9 is working for us on d10.1.8 and webform_views 8.x-5.x-dev thank you
Patch isn't applying to 10.1.8. Needing 24 hours.
$options = [60, 300, 1800, 3600, 21600, 86400, 518400];
For me, this issue was happening having a view with (1) Integer (2) Embed containing a single integer field which is aggregated and a (3) Simple Math Field to achieve a result. I simply could not modify aggregation at (2) at some point and found this issue. #14 speaks to multi-column fields which I wasn't using a display field with multi-columns, but in the (2) Embed field, there is a date filter which is related to this original issue. Aggregation is applied to filters and the display integer field at (2). I assume date is a multi-column field like image.
Patch doesn't apply to 10.1.8
When manually changing /core/modules/views/src/Plugin/views/field/EntityField.php and not changing /core/modules/views_ui/src/Form/Ajax/ConfigHandlerGroup.php then the error is gone and works normally again.
Thanks for everyone's work on this, I've been following this thread since starting work on D7 > D10 in 2021. Visibility can be controlled in other ways, should it be major? Though, it would be nice to have this for core blocks and it was the first thing I looked for when moving to layout builder. It was the way to do it in D7 with panels so it was natural to look for this functionality.
We went live with a few sites on D10 July 1, 2023 without it. For core blocks like Body, we recreated them as a View block and then we have control. There are a few blocks where we are using BVG → . I understand the need though, easier and more intuitive to have the functionality within.
Now that we aren't using or needing it, having visibility control conditions for blocks within layout builder may be something that could be disabled as a setting or that could be a separate module?
Thank you for this solution. Just moved over to aws/rds using 8.0.35 last week. Found this issue when trying to restore to local dev to do some work. Had 379 tables using utf8mb4_0900_ai_ci. Followed the steps above and it restored successfully.
Before going live, we restored from old hosting to aws with no issues. So does that mean it translates/converts from utf8mb4_general_ci to utf8mb4_0900_ai_ci with no issue, but not the opposite direction?
Thanks alphex! Installed and using.
I tried 194 on 10.1.6 core-recommended yesterday but it didn't apply. Hopefully once it passes for 11 then one for 10 will be made.
Awesome! Thank you for quick reply and fix!
I overlooked/missed the default configs at /Highcharts settings/Global options/Language
The random character issue is only happening on a production shared hosting server. D10 on dev/localhost is not displaying the random characters so this issue may be PHP version related. The shared server has a base of PHP7 but PHP8.1 is selected for use. Dev/localhost is only 8.1.
The thousands marker issue is that it still doesn't display.
The open one is marked as duplicate and there is a link chain to here after upgrading to D10 with Claro. Using vertical tabs. For D9 we overrode max-width in css. Now the thin column is back without max-width but width: min().
We use a custom block for inline css overrides for claro admin theme for ease of adjustments.
Used this in D9
<style type="text/css">
.layout-region--node-main .layout-region__content,
.layout-region--node-footer .layout-region__content {
max-width: 100%;
</style>
}It changed for D10
We can't make it 100% of the area without pushing the admin tabs off canvas. 75rem seems to be okay.
<style type="text/css">
.layout-region--node-main,
.layout-region--node-footer {
width: min(75rem, 100%);
</style>
}Before in D9 it flexed well with the admin tabs at max-width 100%;
I was able to upgrade from 9 to 10 successfully with composer "drupal/block_visibility_groups": "^1.x-dev || ^2.0.x-dev",
The deprecation messages still exist but everything is operating normally.
That works, thank you!
Thanks Ravi. When testing on browserstack.com most versions of FF and OS/OSX have whitespace. I'm not seeing it in other browsers though.
I think the inline-block element is causing this and there are some tricks to resolve it here.
Not sure if it needs to be considered for the main theme because it can be fixed with some work in the subtheme. It's mainly for UI nuances and so it's very minor.
Hi Ravi, thank you.
I have investigated this further and realized that it is a browser specific issue.
FireFox = whitespace
Chrome, Bing = no whitespace
Barrio 5.5.13 and D9.5.11.
Thank you teknocat #6. Hits the spot.
I made the changes except for --- Add to ~/.bashrc : alias drush="/usr/local/php81/bin/php-cli /home/<user>/www/<domain>/public_html/vendor/drush/drush/drush" ---
and it works properly now. Thank you
This may be the same as: https://www.drupal.org/project/views_data_export/issues/3387370#comment-... 🐛 Duplicate as Data export Needs work
The issue here is that when duplicating, some settings, fields, other, etc. gets moved over that are invalid or they do not apply/work with the export.
The solution is to build the export from scratch, then attach to a display and then all works well with filters. I think this is the same issue: https://www.drupal.org/project/views_data_export/issues/3354416 🐛 Display "Data export" uses a path but the path is undefined. Active
The "Duplicate as Data export" process needs work
Thank you! I switched from 6.2.x to 1.x-dev and applied the patch.
It seems to fix it for 3 digits or more but when 1 or 2 digits it is still hiding the first number. The image shows the top slider = 8, with the option of up to 8 sessions.
It strange that it does that but it seems that it needs a minimum of 3.5 for a single digit and 4.5 for two digits, then after that the +1.5 calculation works.
Thank you, sorry for delayed response. Using current dev and getting the same result but it's reporting line 263 now
Warning: Undefined array key "" in webform_workflows_element_element_form_after_build() (line 263 of modules\contrib\webform_workflows_element\webform_workflows_element.module).
webform_workflows_element_element_form_after_build(Array, Object)
call_user_func_array('webform_workflows_element_element_form_after_build', Array) (Line: 1083)
Drupal\Core\Form\FormBuilder->doBuildForm('webform_submission_event_request_node_7926_add_form', Array, Object) (Line: 579)
Drupal\Core\Form\FormBuilder->processForm('webform_submission_event_request_node_7926_add_form', Array, Object) (Line: 325)
Drupal\Core\Form\FormBuilder->buildForm(Object, Object) (Line: 48)
Drupal\Core\Entity\EntityFormBuilder->getForm(Object, 'add') (Line: 1257)
Drupal\webform\Entity\Webform->getSubmissionForm(Array) (Line: 112)
Drupal\webform\Element\Webform::preRenderWebformElement(Array)
call_user_func_array(Array, Array) (Line: 101)
Drupal\Core\Render\Renderer->doTrustedCallback(Array, Array, 'Render #pre_render callbacks must be methods of a class that implements \Drupal\Core\Security\TrustedCallbackInterface or be an anonymous function. The callback was %s. See https://www.drupal.org/node/2966725', 'exception', 'Drupal\Core\Render\Element\RenderCallbackInterface') (Line: 788)
Drupal\Core\Render\Renderer->doCallback('#pre_render', Array, Array) (Line: 374)
Drupal\Core\Render\Renderer->doRender(Array, ) (Line: 204)
Drupal\Core\Render\Renderer->render(Array) (Line: 479)This may be in the vendor/commerceguys/addressing library somewhere, I can't seem to locate it either. I did find that it isn't unique to address line 2. It follows the same pattern for all address lines 1 and 2 in replacement patterns in views.
#52 has fixes this for us, currently on twig 2.15.4. Reference: https://www.drupal.org/project/drupal/issues/3358534 🐛 Twig template not defined, LoaderError Closed: duplicate and https://www.drupal.org/project/permissions_by_term/issues/3354478#commen... 🐛 Regression updating to 3.1.22 for Drupal 9.x using loadTemplate from twig Fixed
Production
Production is a cloud server where we can pick to use PHP 8.1. However, composer complains about the server using PHP 7.x. This is where we have experienced the issue after updating core.
Local
There is no issue here because it is a pure PHP 8.1 environment (assumption).
Affix is not working for 5.5x-dev now with the latest update from 1-2 days ago. I've installed ^5.5 and now affix works as before.
I'm getting the same error on production as original problem/motivation. When changing roles for a user...
An AJAX HTTP error occurred.
HTTP Result Code: 200
Debugging information follows.
Path: /batch?id=317&op=do_nojs&op=do
StatusText: OK
ResponseText:
Deprecated: Optional parameter $langcode declared before required parameter $grantDelete is implicitly treated as a required parameter in /modules/contrib/permissions_by_term/src/Factory/NodeAccessRecordFactory.php on line 9
{"status":true,"percentage":"20","message":"Completed 0 of 1.","label":""}
The content access permissions have not been properly rebuilt....the role changes for a user are applied but I'm not confident all is well with permissions.
This is great. We are launching a 9.5.9 site tonight with layout builder, first time. Will need to try this module out next week. Yes #4 is what we need.
The issue we have right now, panels vs layout builder, is that when a view block is displayed on a page and there is no result, but there's actually a result in the view is some way, there is no way to hide the block with views or layout builder.
With Panels we could use visibility conditions to hide the block based on the value of a field of a node. But panels had a single item or entity where the condition could be set on the node variant. Layout builder could have a single item or entity where conditions could be set. When using "Allow each content item to have its layout customized." then it seems it wouldn't make sense for conditions to be used.
Awesome, thanks so much Ryo, that works!
Great thank you for the quick answer!
On the other side of the coin, if in fact we don't want them to have access then the notes column may should be hidden? Currently, the user that doesn't have access can see the notes button/link and when pressed there is no response.
This patch works for 9.5.9, thank you.
Just wanted to mention on the 1 site that we have on a shared hosting environment (production), even though we have manually chosen to use PHP8.1.x on the server, composer still reports PHP7.x in use. I'm not sure why this is but that seems to be what was causing the original issue.
#99 or 53 fixes the issue for 9.5.9 when applied manually
D9.5.9
Claro Admin Theme
Admin Dialogs
+ other modules
1. Completed #2, Add Custom Block always shows in off-canvas format for any setting. This is not really an issue for us though.
2. Deleted Add Custom Block to see if by chance it effects the first one in the list and it doesn't.
--
I found this module in the Drupal Newsletter. Thank you!
Getting same error. I tried the diff and it isn't honoring the entity reference relationship using title.