I had this issue too, and none of the solutions above applied. However, assigning an SSL cert to the site seemed to do the trick.
My site installs are scripted, so I'm not sure what weird thing I might have done to cause my situation, but I'm putting this out there in case someone else sees a similar issue.
Here's the change in Symfony that necessitates this MR: https://github.com/symfony/symfony/commit/6baa3d282c04b9208ef1c2e3d58a0f...
megaphonejon → created an issue.
megaphonejon → created an issue.
MegaphoneJon → created an issue.
dww → credited MegaphoneJon → .
Here's a backtrace of this problem occurring when I try to load a particular webform. Given the block repository reference, I suspect I'm having the same (or related) issue to @Alex_web.
Commenting out the first foreach loop in Drupal\block\BlockRepository::getVisibleBlocksPerRegion() bypasses this issue.
Drupal\Core\Plugin\Context\ContextHandler->applyContextMapping (/home/jon/local/mysite/web/core/lib/Drupal/Core/Plugin/Context/ContextHandler.php:150)
Drupal\block\BlockAccessControlHandler->checkAccess (/home/jon/local/mysite/web/core/modules/block/src/BlockAccessControlHandler.php:92)
Drupal\Core\Entity\EntityAccessControlHandler->access (/home/jon/local/mysite/web/core/lib/Drupal/Core/Entity/EntityAccessControlHandler.php:105)
Drupal\Core\Entity\EntityBase->access (/home/jon/local/mysite/web/core/lib/Drupal/Core/Entity/EntityBase.php:314)
Drupal\block\BlockRepository->getVisibleBlocksPerRegion (/home/jon/local/mysite/web/core/modules/block/src/BlockRepository.php:63)
Drupal\block\Plugin\DisplayVariant\BlockPageVariant->build (/home/jon/local/mysite/web/core/modules/block/src/Plugin/DisplayVariant/BlockPageVariant.php:137)
Drupal\Core\Render\MainContent\HtmlRenderer->prepare (/home/jon/local/mysite/web/core/lib/Drupal/Core/Render/MainContent/HtmlRenderer.php:274)
Drupal\Core\Render\MainContent\HtmlRenderer->renderResponse (/home/jon/local/mysite/web/core/lib/Drupal/Core/Render/MainContent/HtmlRenderer.php:132)
Drupal\Core\EventSubscriber\MainContentViewSubscriber->onViewRenderArray (/home/jon/local/mysite/web/core/lib/Drupal/Core/EventSubscriber/MainContentViewSubscriber.php:90)
call_user_func:{/home/jon/local/mysite/web/core/lib/Drupal/Component/EventDispatcher/ContainerAwareEventDispatcher.php:142} (/home/jon/local/mysite/web/core/lib/Drupal/Component/EventDispatcher/ContainerAwareEventDispatcher.php:142)
Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch (/home/jon/local/mysite/web/core/lib/Drupal/Component/EventDispatcher/ContainerAwareEventDispatcher.php:142)
Symfony\Component\HttpKernel\HttpKernel->handleRaw (/home/jon/local/mysite/web/vendor/symfony/http-kernel/HttpKernel.php:174)
Symfony\Component\HttpKernel\HttpKernel->handle (/home/jon/local/mysite/web/vendor/symfony/http-kernel/HttpKernel.php:81)
Drupal\Core\StackMiddleware\Session->handle (/home/jon/local/mysite/web/core/lib/Drupal/Core/StackMiddleware/Session.php:58)
Drupal\Core\StackMiddleware\KernelPreHandle->handle (/home/jon/local/mysite/web/core/lib/Drupal/Core/StackMiddleware/KernelPreHandle.php:48)
Drupal\page_cache\StackMiddleware\PageCache->pass (/home/jon/local/mysite/web/core/modules/page_cache/src/StackMiddleware/PageCache.php:106)
Drupal\page_cache\StackMiddleware\PageCache->handle (/home/jon/local/mysite/web/core/modules/page_cache/src/StackMiddleware/PageCache.php:85)
Drupal\ban\BanMiddleware->handle (/home/jon/local/mysite/web/core/modules/ban/src/BanMiddleware.php:50)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle (/home/jon/local/mysite/web/core/lib/Drupal/Core/StackMiddleware/ReverseProxyMiddleware.php:48)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle (/home/jon/local/mysite/web/core/lib/Drupal/Core/StackMiddleware/NegotiationMiddleware.php:51)
Stack\StackedHttpKernel->handle (/home/jon/local/mysite/web/vendor/stack/builder/src/Stack/StackedHttpKernel.php:23)
Drupal\Core\DrupalKernel->handle (/home/jon/local/mysite/web/core/lib/Drupal/Core/DrupalKernel.php:718)
{main} (/home/jon/local/mysite/web/index.php:19)
@camhoward I found these instructions very helpful, thank you.
I can't replicate @avall-llovera's issue but I think I have the same root cause. My [webform_submission:values] token renders a state/province as its ID. This worked in 2022.
I think sure this happens because we don't dynamically update the options "the Drupal way". We're using `populateStates()` in webform_civicrm_forms.js.
This doesn't update the webform's Form API values. So without any `#options`, state/province doesn't convert the value.
I think the solution is an AJAX callback (add a `#ajax` element to the field in the Form API) to fill `#options`.
If we did that, we should also be able to remove the disabling of form validation of state/province in `prepareElementValidateCallbacks()`.
MegaphoneJon → created an issue.
Ultimately I fixed this by changing "offset" to the very-real-not-made-up "offsetted". See diff below. This also required me to change the SQL structure with ALTER TABLE block_inject_exceptions RENAME COLUMN `offset` TO offsetted. Given how few people use this module, and given that those sites are probably zombies that will never see PHP 8 (or else I wouldn't be the first to find this!), I'm not going to write a proper upgrade script. But anyone who has this problem can find the solution here.
diff --git a/sites/all/modules/contrib/block_inject/block_inject.module b/sites/all/modules/contrib/block_inject/block_inject.module
index 9a2e24aa..c986d1f0 100644
--- a/sites/all/modules/contrib/block_inject/block_inject.module
+++ b/sites/all/modules/contrib/block_inject/block_inject.module
@@ -713,7 +713,7 @@ function block_inject_insert_exception($nid, $bi_id, $exception, $offset = NULL)
$query = db_update('block_inject_exceptions')
->fields(array(
'except_injection' => $exception,
- 'offset' => $offset,
+ 'offsetted' => $offset,
))
->condition('nid', $nid)
->execute();
@@ -724,7 +724,7 @@ function block_inject_insert_exception($nid, $bi_id, $exception, $offset = NULL)
'bi_id' => $bi_id,
'nid' => $nid,
'except_injection' => $exception,
- 'offset' => $offset,
+ 'offsetted' => $offset,
))
->execute();
}
@@ -772,9 +772,9 @@ function block_inject_green_light($nid) {
*/
function block_inject_get_offset($nid) {
$result = db_select('block_inject_exceptions', 'bie')
- ->fields('bie', array('offset'))
+ ->fields('bie', array('offsetted'))
->condition('nid', $nid)
- ->isNotNull('offset')
+ ->isNotNull('offsetted')
->execute()
->fetchAssoc();
return $result;
scratch that - my fix doesn't work, the issue remains
MegaphoneJon → created an issue.
MegaphoneJon → created an issue.
MegaphoneJon → created an issue.
@robbe03 - Good question! The client I wrote it for still uses it quite heavily, but I don't handle this particular work for them anymore. Patches are welcome - either to this submodule, or as Liam says, to incorporate this into the parent module. If not, I imagine the issue will arise when my client moved to D10. It seems like that should be quite soon!
MegaphoneJon → created an issue.
MegaphoneJon → created an issue.
MegaphoneJon → created an issue.
Hi @jitendrapurohit - I just tested the PR, and it didn't change the behavior for me.
With XDebug I confirmed that your code is getting hit. I cleared cache and confirmed that the error was the same. Does this only work on submissions made after the patch, or should it work when editing submissions made before the patch was installed?
To be clear - I think the step here is to decide whether the `webform_civicrm_webform_submission_load` is necessary. I couldn't see any difference without it, so maybe other code has matured around it?
The use case: My client has chapters around the world, but the staff all use one of 3 languages. So Civi supports those 3 languages, but forms can be in any of several languages.
MegaphoneJon → created an issue.
MegaphoneJon → created an issue.
[I apparently just made a commit via a comment? Someone please remove that.]
I'm a little late to this party, but if anyone else has this issue, here's some code I wrote to remove a line item from an order. Use this with the "After saving a new commerce line item" event. I wish you could prevent it being added on presave but the requisite data isn't available at that time.
function wrltweaks_rules_action_info() {
return [
'wrltweaks_remove_line_item_from_order' => [
'label' => t('Remove item from order'),
'group' => t('Commerce Line Item'),
'parameter' => [
'commerce_line_item' => [
'type' => 'commerce_line_item',
'label' => t('Line item'),
],
'commerce_order' => [
'type' => 'commerce_order',
'label' => t('Order'),
],
],
],
];
}
function wrltweaks_remove_line_item_from_order($lineItem, $order) {
$lineItemId = $lineItem->line_item_id;
commerce_cart_order_product_line_item_delete($order, $lineItemId, TRUE);
}
MegaphoneJon → made their first commit to this issue’s fork.
@awasson I missed your message earlier that https://github.com/colemanw/webform_civicrm/pull/829 solved your issue. Are you able to provide a form that reliably has the error? I'd love to get this merged but I don't feel like I have the evidence to prove it fixes a problem.
MegaphoneJon → created an issue.
MegaphoneJon → created an issue.
MegaphoneJon → created an issue.
I still think the default may be at play. What happens if you remove the last line of that YAML? I know that may be necessary functionality but it would be good to isolate the bug.
@roblog I saw that error fairly recently, and it had to do with how the default value was set. Having anything in the "Value" box on the "General" tab when configuring the field caused this. Is that perhaps the issue?
@roblog it's tricky - there are two very closely related bugs. Could you please try applying my patch https://github.com/colemanw/webform_civicrm/pull/829 and see if it fixes the problem?
If not, does applying https://github.com/civicrm/civicrm-core/pull/23305 to your CiviCRM fix the bug?
I found that the PR Jitendra mentions doesn't fix the problem when FALSE is passed - just an empty array. I wrote a second patch https://github.com/colemanw/webform_civicrm/pull/829 but my coworker couldn't replicate the issue so we closed it. Mentioning it just in case someone finds this problem persisting after they upgrade to 5.58.
I'm sorry to comment on a closed topic - but since I may need to run this module in PHP 7 a bit longer, I just wanted to confirm.
I ran Rector on the module, and it seems the only PHP 8-ism that's not polyfillable is the use of the `mixed` type declaration in function signatures. If I were to simply remove those, is there any reason this wouldn't continue to work in PHP 7?