Added latest fix so email is sent to the temporary address
pavel ruban → created an issue.
The warning message you refer to is happening in node field plugin which we don't use at all. I believe you can apply mentioned by you patch on top if needed to fix the warning as it's the separate issue not linked with the context of this thread - entity field condition plugin.
We mainly use field value plugin which allows to use node field as well but with field widgets.
If patch doesn't apply you may reroll it on top of these patches.
Restore Op's initial logic to exclude height if its auto + keep check plain bug fix
fix same as in #13 for 6.0.x
pavel ruban → made their first commit to this issue’s fork.
pavel ruban → changed the visibility of the branch 3512941-allow-load-group to hidden.
pavel ruban → created an issue.
Allow other modules to alter mapbox_block settings as theme preprocess doesn't let to adjust #attached, subscriber or attachments alter has issues with cache for anonym sessions.
Fix anon users js fatal as debounce lib wasn't required
pavel ruban → created an issue.
pavel ruban → created an issue.
Also your resolution even for block case is faulty, if you add 2 cookie plugins or more you basically apply only one context and ignore all the rest
Hello,
This module is not about blocks, it's about condition plugin, it's used way wider than just a plain visibility rules, having the patch for blocks users only is fine as long as they don't use conditions in other contexts which will break cache logic.
There idea is valid that it is preferable to add context only where it's needed, but the resolution breaks other logic.
I don't recall from the top of my head how contexts work if cache context value doesn't change. I mean whether when you visit a page without cookie condition the context key generates several variants of the data or it adds 1 variant as context cookie value always null. If it doesn't overflow the data yes it's still undesired to have a lot of cache context keys but at gets less critical but still good to have a fix.
Regarding the other places which may use this, e.g. we use it for conditioned layouts https://www.drupal.org/project/layout_library/issues/3089493 ✨ Library Layouts Auto Selection & Selection Rules Like It Was In Panels (D7) for Page Variants Needs work , as it's a plugin you may basically instansiniate a plugin and use it as bool condition in custom logic. I guess the more correct way is to rely on plugin invocation and add context whenever it's invoked despite of the invocation context, whether it's blocks, layout library, custom code or any other logic.
this is correct patch for 10.4.3, please ignore above
Tested with core 10.4.3 & 8.x-1.4
* If you use layout builder visibility rules you need to apply this patch
https://www.drupal.org/files/issues/2025-02-27/2916876-3091898-10.4.3-26... →
* If you use ctools, e.g. for this #3089493 you need to apply this patch
https://www.drupal.org/files/issues/2025-02-27/ctools-condition-form-aja... →
* Plus this 3091898-3225480-8.x-1.4-52.patch main patch #52 or feel free to use https://git.drupalcode.org/project/entity_field_condition/-/merge_reques...
Patch notes:
* Issue #3091898: Enhance layout builder integration, allow ajax context mapping which now automatically rebuilds field selection widget, fix uuid issues on submit, complex widgets like address and media library previously didn’t populate default values due to missing widget dependent items values processing, fix fatals when not fieldable context entity was used by context mapping.
* Issue #2916876-3091898: Sometimes we can have a conditional plugin which uses ajax dynamical form elements, current layout builder visibility rules ecosystem doesn’t allow this. It’s not possible to use ajax subform of a conditional plugin. There was a similar issue in context of ctools framework, it was solved here #3230847, in our case we have this entity field value condition plugin #3091898 which allows you select an entity field and then form rebuilds with generated field widget to set visibility rule in a user friendly manner. The idea is to proxy all request context data to sub form via symphony http sub request to the plugin configure form route, imitate ajax request and then grab sub response on the host block visibility form and proxy back as ajax command response, allowing different conditional plugins have different form elements which will trigger automatically appropriate ajax callbacks by form API.
* Issue #3230847: On any complex widgets like media library which use sub dialog modal was the error which leaded to initial dialogue overwrite & complete data loss following by dialogue close, prevent this by render initial widget form in off canvas sidebar which allows to use secondary dialog modal.
Tested with 10.4.3
@see https://www.drupal.org/project/entity_field_condition/issues/3091898#com... ✨ Generic Entity Field Value Plugin Needs review
patch for 4.1.0 with additional fix: https://git.drupalcode.org/project/ctools/-/merge_requests/79/diffs?comm...
* Issue #3230847: On any complex widgets like media library which use sub dialog modal was the error which leaded to initial dialogue overwrite & complete data loss following by dialogue close, prevent this by render initial widget form in off canvas sidebar which allows to use secondary dialog modal.
pavel ruban → made their first commit to this issue’s fork.
Added to release 2.0.0
pavel ruban → made their first commit to this issue’s fork.
reroll for beta5, also fixed issue after ctools update that added new abstract method in the class we used in this patch
I may assume that something wasn't configured correctly in regard to server settings / Drupal cookies settings, https, so Drupal / Symphony just stripped those cokkies on your end, as no one else reported the issue & I couldn't reproduce it myself I closing it for now, feel free to reopen the task if it's considered as a bug for you.
I've provided co-maintainer access to https://www.drupal.org/u/welly →
added to 8.x-1.8 release
added to 8.x-1.8 release
Just to elaborate on post above how the oath service was got into cache deps for user registry form:
I have redirect subscriber that uses third party oauth logic in redirects flow:
myaccount.event_subscriber:
class: 'Drupal\myaccount\EventSubscriber\EventSubscriber'
arguments:
- '@current_user'
- '@?crm_api.client'
- '@entity_type.manager'
- '@cache.data'
- '@state'
- '@messenger'
- '@path.current'
tags:
- {name: event_subscriber}
I believe if you add a subscriber with request or url generator dep & page is cached, on cache get contrib logic will result in fatal
Just for debug purposes:
core 9.5.3, PHP 8.1
It seems the issue happens in different contexts. In my case I have standard themed Drupal registry form without popups, first time page opens fine after it gets caches in anon session every next request results in this error:
The website encountered an unexpected error. Please try again later.
TypeError: Drupal\Core\Routing\RequestContext::fromRequest(): Argument #1 ($request) must be of type Symfony\Component\HttpFoundation\Request, null given, called in /projects/matchtech/docroot/core/lib/Drupal/Core/Routing/RequestContext.php on line 28 in Drupal\Core\Routing\RequestContext->fromRequest() (line 34 of core/lib/Drupal/Core/Routing/RequestContext.php).
Drupal\Core\Routing\RequestContext->fromRequest() (Line: 28)
Drupal\Core\Routing\RequestContext->fromRequestStack()
call_user_func_array() (Line: 276)
Drupal\Component\DependencyInjection\Container->createService() (Line: 177)
Drupal\Component\DependencyInjection\Container->get() (Line: 434)
Drupal\Component\DependencyInjection\Container->resolveServicesAndParameters() (Line: 273)
Drupal\Component\DependencyInjection\Container->createService() (Line: 449)
Drupal\Component\DependencyInjection\Container->resolveServicesAndParameters() (Line: 237)
Drupal\Component\DependencyInjection\Container->createService() (Line: 177)
Drupal\Component\DependencyInjection\Container->get() (Line: 434)
Drupal\Component\DependencyInjection\Container->resolveServicesAndParameters() (Line: 237)
Drupal\Component\DependencyInjection\Container->createService() (Line: 177)
Drupal\Component\DependencyInjection\Container->get() (Line: 434)
Drupal\Component\DependencyInjection\Container->resolveServicesAndParameters() (Line: 237)
Drupal\Component\DependencyInjection\Container->createService() (Line: 177)
Drupal\Component\DependencyInjection\Container->get() (Line: 89)
Drupal\Core\Plugin\PluginBase->__wakeup()
unserialize() (Line: 167)
Drupal\Core\Cache\DatabaseBackend->prepareItem() (Line: 122)
Drupal\Core\Cache\DatabaseBackend->getMultiple() (Line: 92)
Drupal\Core\Cache\DatabaseBackend->get() (Line: 306)
Drupal\page_cache\StackMiddleware\PageCache->get() (Line: 124)
Drupal\page_cache\StackMiddleware\PageCache->lookup() (Line: 82)
Drupal\page_cache\StackMiddleware\PageCache->handle() (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle() (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle() (Line: 23)
Stack\StackedHttpKernel->handle() (Line: 713)
Drupal\Core\DrupalKernel->handle() (Line: 19)On sixth backtrace line `Drupal\Component\DependencyInjection\Container->resolveServicesAndParameters() (Line: 273)` it tries to get erroring request method by solving deps for `Drupal\Core\Routing\UrlGenerator`
In my case the base service in backtrace has this service - `oauth2ClientService`.
So just an assumption to conclude - if on the cached page with form you have a service that depends on the op service after cache get & wakeup it will lead to fatal
@rpayanm, I don't think so, atm it works, but if branch will be updated on gitlab side (added commit etc) it might break project composer & people working on it eg FE guys will be blocked for a while. We had it many times with gitlab based links, so it's just a snapshot of a piece of code that was verified & applied to our project internally, sorry for noise.
Pavel Ruban → created an issue. See original summary → .
convert MR's commit to static file patch for those who need.
Pavel Ruban → created an issue.