🇬🇷Greece @Pavel Ruban

Just saw your commit comments.

The form as a view field to add a node from a nodes list with a group selection is a good and useful which of course can be implemented and good to have but that wasn't my objective

The other scenario that is useful and which I needed and did is the ability to request some service bundle nodes membership right on the group page or groups list page , such nodes are generated on the fly upon submit with the user input context like bookings with desired dates intervals / people quantity, then a booking node appears in moderation view, admin approves / rejects it and approved bookings can be seen in a content view. So we can render booking calendar, review available seats , time slots etc. And we can configure any needed context fields on three gnode request relation entity as needed.

Other possible scenarios e.g.: buying tickets with approve, or groups can be jobs and people can make offer with some details like price and ETA they can accomplish such a job and a person who provided the job can review candidates and select the most relevant one. Still all such users can request user group membership on top of nodes membership to receive newsletter, ads about the explicit group etc.

It's a pretty generic module and my guess that it's quite an often need to do Audi a things like above and it's better to have this possibility rather than limit module usage only to explicit cases like adding nodes to groups from node full / list pages with a group selection

Hope this explanation makes it's more clear now

> I'm wondering about the form group-request-node.

In my case I use this form to render it on the group page itself, same way as you do in all other places in your module, get a node instance and create request form with the gnode relation entity programmatically. Why not to keep the form? If you try to render the form so user can request moderation of a new node membership via entity form before it threw the fatal error as the entity metadata had no such a form entry, so how it was possible to render a form at all? What was a way to actually create a moderated request?

With the form you deleted you could programmatically eg grab the node from a route context or create a new node on the fly (in my case I create booking node instance with all the fields you configure at the fieldable group content entity api, so I gather date the user wants to book a group entity for, in submit create a node, fill it's fields from the input and create moderation request).

Eg same way you could configure multiple fields on content entity field and form display settings page, and render it eg in a sidebar of a node full/teaser view modes with the possibility to request the page's node membership. Now if the form doesn't exist is it possible to use fieldable entity form to make a membership request form? What is the workflow to add nodes to the group with moderation? Why it's necessary to select a node from the nodes list on the membership request form? I guess it's more naturally to render form in context of some node. If you want to select node you can create multistep form with node selection and then reuse the same entity form with node context from the previous step.

fixed conflicts with 3.0.x due to #6

Refactored, adjusted logic a bit to properly handle plugin ids group_node & group_node_request conditions,

Please note that I found another fatal & fixed it:
https://git.drupalcode.org/project/gnode_request/-/merge_requests/2/diff...
https://git.drupalcode.org/project/gnode_request/-/merge_requests/2/diff...

request form render caused before:

Drupal\Component\Plugin\Exception\InvalidPluginDefinitionException: The "group_relationship" entity type did not specify a "group-request-node" form class. in Drupal\Core\Entity\EntityTypeManager->getFormObject() (line 212 of core/lib/Drupal/Core/Entity/EntityTypeManager.php).
Drupal\Core\Entity\EntityFormBuilder->getForm() (Line: 91)

Ah, the 'could you not use' confused me, I guess you are fine with the approach just asked to use base id callback instead of manual check, yes sure, makes sense

Hi,
Grequest code is valid as it's bound to users and plugin id behaves differently in there. Also as grequest and gnoderequest previously defined the same machine name routes for entity links if you install both modules at once one or other module will override routes depending on modules weight and when access tried to check the route result actually others module controller was called and provided false check result when it was expecting the access object interface.

Regarding the starts with, can you elaborate what is the concern about it?

In grequest you have one id for the plugin in group nodes there are no such a plugin and it has pattern gnode_request:article, gnode_request:basic_page & so on, depending on bundled enabled in the group node settings, so previous code didn't pass any access checks at all due to this, so now I check and if there is at least one plugin which starts with node request prefix I pass the check, mb group nodes interface was changed a bit and before it was the other way, it's why I mentioned it in the description.

for 3.0.0-alpha1

pavel ruban → created an issue.

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.