Thank you enormously @crzdev
I can can confirm that 2.1.0.-beta-1 all works as expected; it UNblocks the Field Group update to 4.x and I have updated #3498382 💬 Drupal 11 release for this? Active to say so.
Thank you for all the efforts over the last 24 hour folks.
I can can confirm that 2.1.0.-beta-1 all works as expected and UNblocks the Field Group update to 4.x
Ah OK, thanks for that @tunic
I think I get that; so when do an actual composer require <next release> it'll work.
Thanks again - it's such a useful module.
Thanks @tunic,
I have applied the patches from #3498382: Drupal 11 release and the following files have been adjusted and all look correct to me.
Apologies if I am being a bit dim here but I still cannot seem to get Field Group itself up to 4.x.
My site composer.json reads (actual versions loaded in brackets)...
...
"drupal/popup_field_group": "^1.9" (1.9.0)
"drupal/field_group_label": "^2.0" (2.0.0)
"drupal/field_group": "^3.4.0" (3.6.0)
...
But when then go to update using ...
composer require 'drupal/field_group:^4.0'
I am still getting the same response...
Problem 1
- Root composer.json requires drupal/field_group ^4.0, found drupal/field_group[dev-4.x, 4.0.0-alpha1, 4.0.0, 4.x-dev] but these were not loaded, likely because it conflicts with another require.
Problem 2
- drupal/field_group_label is locked to version 2.0.0 and an update of this package was not requested.
- drupal/field_group_label 2.0.0 requires drupal/field_group ^3.4 -> found drupal/field_group[dev-3.x, 3.4.0, 3.5.0, 3.6.0, 3.x-dev (alias of dev-3.x)] but it conflicts with your root composer.json require (^4.0).
Problem 3
- drupal/popup_field_group is locked to version 1.9.0 and an update of this package was not requested.
- drupal/popup_field_group 1.9.0 requires drupal/field_group * -> found drupal/field_group[dev-1.x, dev-3.x, dev-4.x, 1.0.0-rc3, ..., 1.x-dev (alias of dev-1.x), 3.0.0-beta1, ..., 3.x-dev (alias of dev-3.x), 4.0.0-alpha1, 4.0.0, 4.x-dev] but these were not loaded, likely because it conflicts with another require.
Use the option --with-all-dependencies (-W) to allow upgrades, downgrades and removals for packages currently locked to specific versions.
I am never very confident with composer when this type of thing happens but I think your update in from f9fc36cf really should have done it for me.
@tunic,
I have patched my local version and flushed all caches and done a database updated just in case.
All working as before :-)
However, when I go to (dry run) and re-try an update to the Field Group module itself using...
composer require 'drupal/field_group:^4.0' composer update "drupal/core-*" --with-all-dependencies --dry-run
I am still seeing the 'Problems' ...
Problem 1
- Root composer.json requires drupal/field_group ^4.0, found drupal/field_group[dev-4.x, 4.0.0-alpha1, 4.0.0, 4.x-dev] but these were not loaded, likely because it conflicts with another require.
Problem 2
- drupal/field_group_label is locked to version 2.0.0 and an update of this package was not requested.
- drupal/field_group_label 2.0.0 requires drupal/field_group ^3.4 -> found drupal/field_group[dev-3.x, 3.4.0, 3.5.0, 3.6.0, 3.x-dev (alias of dev-3.x)] but it conflicts with your root composer.json require (^4.0).
Problem 3
- drupal/popup_field_group is locked to version 1.9.0 and an update of this package was not requested.
- drupal/popup_field_group 1.9.0 requires drupal/field_group * -> found drupal/field_group[dev-1.x, dev-3.x, dev-4.x, 1.0.0-rc3, ..., 1.x-dev (alias of dev-1.x), 3.0.0-beta1, ..., 3.x-dev (alias of dev-3.x), 4.0.0-alpha1, 4.0.0, 4.x-dev] but these were not loaded, likely because it conflicts with another require.
Another community member has assured me that the Field Group Popup module (Problem 3 ) is a red-herring here.
What am I missing?
Thanks
Magic, thanks @tunic → !
Happy to test out anything you come up.
I see the discussion has gone back and forth a bit and there are two threads althoigh I am not clear about the distinction.
To be clear from my perspective as a someone with a bit of experience training content-editors, I think ...
- The button should need to placed explicitly in the backend Text format configuration for the 'bubble' to popup at all
- It is not really contextual in the strictest sense because it pops up anyway on a highlight and therefore the original naming as 'bubble' should stand.
- Getting caught up in the configuration of a 'right-click' (truly contextual) will open a whole can of worms because most users demand a context menu as defined by their own browser and it's whatever other widgets they have installed suxh as Lorem ipsum generators and they won't thank you for overriding.
I hope that is useful.
sirclickalot → created an issue.
sirclickalot → created an issue.
sirclickalot → created an issue.
Thankyou @mengi, I had not spotted that.
How does one go about requesting that a module (in this case) Field Group Label → gets updated if activity seems to have gone stagnant on the module page.
I have contacted the module maintainers again and I hope tog et some response but if not?
Short of simply cloning it into our own version, we're a bit stuck.
Grateful for your help here.
Having been using this a lot more over the last day or so because of the new 'Title override' feature, I have become aware of how it could be even more useful still if we could use tokens in the overriding titles…
What do you think, is that doable?
Nope, definitely no sign of any dump anywhere at all?
Like I said, I am not even seeing my DEBUG message suggesting that the whole ECA is not kicking in for some reason.
What else should I try?
I have installed the DEV version and set up a Form Dumper using !!form ...
But I do not 'see' any form dump anywhere - nothing in the Watchdog log?
Plus, my ECA never gets to show the DEBUG message but I cannot see any other notices or errors in the Watchdog either.
Where should I expect to see it?
Thanks
sirclickalot → created an issue.
sirclickalot → created an issue.
sirclickalot → created an issue.
@minnur
Outstanding! ...
sirclickalot → created an issue.
That would be absolutely spot on!
Brilliant, thank you @zipme_hkt,
I thought as much as I was easily able to target it with a simple form_alter() hook but was keen to do it using ECA for site-builder maintenance.
Might be worth giving out some simple, easy guidance for site-builders as how they could most easily identify and target form elements. Indeed, even better than guidance, might be to somehow add something to the ECA UI for this action to help them - maybe the 'current form'
sirclickalot → created an issue.
sirclickalot → created an issue.
sirclickalot → created an issue.
Hi @mably,
Yes, I can confirm that updating to 3.2.0-rc2 and applying 40.patch from merge_requests/40 fixe the issue for me.
sirclickalot → created an issue.
sirclickalot → created an issue.
Thank you @aaron.ferris, that is very clear.
Absolutely!
I have read and understood the Token section of the guide many moons a go and been using it for years now too not mixing up [token] with token.
That's not the issue here that is the finally stumbling point, thanks to your last response, it is now now clear the Automator needs an entity not an id but the problem we are hitting is LOADing that entity in in order to be able to pass it forward.
To clarify, the illustration above in #4 is the Entity: load dialogue and if we load it via a hard-coded id (8797) it all work perfectly and that confirms your advice about passing on an entity that we have successfully loaded.
The problem is we simply cannot seems to get the right combination to load it!
Thankyou @jurgenhaas,
That has really helped, it was driving us mad.
We still really struggle to recognise when an entity is needed over and entity_id.
HOWEVER, attempts to do an Entity: load on the 'targeted_id' token fail miserably whatever we try!
HARD CODING the actual (known) ID as step (4) works a treat and calls the AI Automator, does the job, and returns back with a confirmation all beautifully via AJAX, exactly as we want, but is of course useless to us ;-)
We just don't get it and believe me, we have put the time in experimenting with all manner of combinations of:
- Current scope
- Type and ID (see below)
- Type and properties (see below)
- Defined by token
Is there most-commonly-used recommendation?
Almost there!
sirclickalot → created an issue.
sirclickalot → created an issue.
sirclickalot → created an issue.
I take it all back.
The block for the mobile version of the menu was a separate one and we had not added the revised setting for: 'Scroll offset' to one based on CSS variable - Doh!
However, we have pushed everything live anyway as there is actually another connected issue that we might somehow be able to improve on through further dialogue.
Here is the page: https://bit-by-bit.org/tutorials/boolean-logic-introduction
To witness this 'extra', ...
- Refresh the page and ensure that you are at the top.
- Switch to (say) 900px
- Click LEARN - all good.
- Click LEARN again
As you will see, the subsequent click doesn't give quite the desired results because the ToC.js block itself is 'Sticky' controlled via the Sticky module → .
I suspect that there may not be anything we can do about as the block and JS controlling are separate concerns but we thought we might just flag it up.
sirclickalot → created an issue.
Thanks danarod,
Yes, very keen to see it in action so please do.
You've marked as Fixed but the documentation page link is still broken as before?
sirclickalot → created an issue.
sirclickalot → created an issue.
@jurgenhaas,
UPDATE!
After much experimenting, I seem to have made some progress here and I think I now see what you meant by...
...you also have to have a second event to control the access on that endpoint.
...
Although what I have added is an Action not and Event, no?
At first I thought it seemed implicit that I would need access that if I wanted to respond to that path but I guess in another scenario, I want to BLOCK access and that's why either way, I do need to add the Set access result action?
So, unless anyone tells me that I've got it a all wrong and that, while it works, what I have done is a fudge, I think I'm all good but maybe we should leave this open for anyone else who may be wrangling with the scenario.
Having got over this hurdle, I then immediately hit another but I will document that elsewhere.
Thank you for your support in this.
Thanks again @jurgenhaas, I had tried to follow your advice but I'm just not quite getting it right.
I do apologise for being a bit thick here but I'm getting there.
Please note that the screenshot here is simply to aid my explanation, I have exported the ECA with as few dependencies as possible.
I have created a simple model which:
- Responds to the URL path of :
/node/automark - Picks off a NID from the query string
- Outputs a simple Drupal message essentially simply to verify that it's responded
The actual exported model is attached below.
Using view on my usual site-builder-preferred way, I've created a good old block which spurts out...
<a href="/eca/node/automark?nid={{ raw_arguments.nid }}" class="use-ajax btn btn-sm btn-outline-secondary">
AI-assisted assessment
</a>That gives me a useful little button...
So far so good, it all works as expected but I when click the rendered link, I get the expect AJAX throbber for a second then...
The Console detailing...
POST http://bit-by-bit.local/eca/node/automark?nid=8786&_wrapper_format=drupal_ajax 404 (Not Found)
send @ jquery.min.js?v=3.7.1:2
ajax @ jquery.min.js?v=3.7.1:2
Drupal.Ajax.eventResponse @ ajax.js?v=10.4.6:799
(anonymous) @ ajax.js?v=10.4.6:646
dispatch @ jquery.min.js?v=3.7.1:2
v.handle @ jquery.min.js?v=3.7.1:2
ajax.js?v=10.4.6:196 Uncaught Drupal.AjaxError {message: '\nAn AJAX HTTP error occurred.\nHTTP Result Code:
40…tatusText: Not Found\nResponseText: {"message":""}', name: 'AjaxError', stack: 'Error\n at
http://bit-by-bit.local/core/misc/aja…it-by-bit.local/core/misc/ajax.js?v=10.4.6:1935:3'}
(anonymous) @ ajax.js?v=10.4.6:196
(anonymous) @ ajax.js?v=10.4.6:1935
On refreshing the browser page, I do get the see the Drupal message originating from the ECA to I can confirm that it is responding to the path but I don't understand what the 404 error is referring to!
I know I'm missing a trick here and I understand that it's probably something to do with me not returning a valid AJAX response - I tried adding an EVA AJAX Response message but to no avail.
If you are able to see what I'm missing I would be most grateful because I've search far and wide for a actual step-by-step example of what I'm trying to do and the likes of the various LLMs out there just seem make up a load of rubbish ;-(
Ideally, where I want to end up is...
Having called another ECA from within this one (which actually performs the assessment and is all built and working fine),
I would simply like the current page to refresh revealing the newly-populated field.
Thanks
Hi @bruno,
Yes, I think that sorts it.
Hi bruno,
Applying the patch from MR:114 (https://git.drupalcode.org/project/frontend_editing/-/merge_requests/114) does the job nicely.
It now looks much better to me on my Windows 11 machine.
Thank you!
Hi @bruno,
Mmmm, good question, where is that class coming from.
I do not overwrite any FEE templates.
However, what is worth pointing out is that my particular problem relates to editing a Paragraph (3) within a Paragraph (2) withing the FEE sidebar (1) like this...
So maybe that's where the small buttons click in and you had not noticed?
I doubt it but I thought it might help to have the extra clarification as I am definitely seeing the class attached.
That doesn't seem to add any value to me because you have target the encompassing <ul> rather what I was pointing to which was the input..button.button--small which has been given (I believe) two attributes that serve no purpose.
I'm not sure exactly how you 'tested' this before issuing the MR ???
As I said in the original, I believe that both attributes shown below, set as they are, have no value and that simply doing this....
...solves the problem completely - at least for me using Gin...
Thanks
sirclickalot → created an issue. See original summary → .
Got it, thanks @jurgenhaas, that's very helpful.
We were floundering around with the Controller found to handle request event and going around in circles.
I think I get what you are saying here and we'll give that good go later, thanks again.
Moving things forward, and from the point of view of the school of 'empowering site builders', would it be possible (valuable?) in the future to provide a built-in core event that could wire this altogether for on one hit much like the old Rule Link module years ago - that was such an easy win for those who don't want to get their hands dirty a the route/entity level?
sirclickalot → created an issue.
Thanks @mrdalesmith → , exactly what I thought but they are not.
I understand correctly then they should being interpreted but they are definitely not being.
All the Node entity-related are being interpreted as you would expect.
On the face of it, all of this testing is being done by UID:1 since I am logged so permissions ought not to be related however, to give more detail here, I will add that I am triggering the Automator through an ECA using the feature provided by ECA Integration module so I suspect that might well be the issue.
I can look into that further by using the ECA Switch User feature inside the ECA.
sirclickalot → created an issue.
sirclickalot → created an issue.
sirclickalot → created an issue.
In my case, simply click the Front End Editing module's Add Paragraph (+) and I see (as illustrated) a list of the optional Paragraphs types appear.
sirclickalot → created an issue.
Ah, I think I have found what I am after here: https://ecaguide.org/library/simple/route_test
So Closing now.
sirclickalot → created an issue.
Thanks, @mrdalesmith → that's great advice and I suppose it make perfect sense that the Base Mode is just that.
As I eluded to, the Advanced Mode (Token) mode works well but it has limitations and I will try to be specific about them and write them up in separate issues.
sirclickalot → created an issue.
OK, very interesting
...Doing a save in a form build and then redirecting sounds terrible.
... is exactly what we after because it was either nifty and smart idea or the not as it seems!
It was the voice of experience we were looking for ;-)
We did have an initial go with the Prepare content entity form but were no sure if that was the right approach, but now we'll venture forth.
Strangely, and timely, it has disappeared since the release of BPMN.io 2.08.
There is a long delay (seconds) after AJAX throbber disappears and the Token browser pops open but it does so reliably now and we're back in business.
I don't know if this is 'right' and I'd like to keep this issue open for advise from others bit in the meantime, we have been able to use a neat 'trick' to populate a node edit form with Long text (CKEDitor) the fields.
We fire up a node edit form and pick up URL query string using a token: [current-page:query:original_question_id]
For example, firing up a new node form linked to an original...
/node/add/long_answer_response?original_question_id=8724
We process query string using an ECA Build form event.
We also use an ECA Insert content entity event to copy various field's contents from the original to the target node.
The real trick is in the steps labelled (1) and (2) where we force a node save in the Build form event which then triggers the second event to populate the fields and then we do a sneaky redirection back to the node form and everything is magically all there in place.
Here is an illustration of the logic if helps anyone else out...
sirclickalot → created an issue.
sirclickalot → created an issue.
sirclickalot → created an issue.
sirclickalot → created an issue.
sirclickalot → created an issue.
sirclickalot → created an issue.
Hi @marcus →
Thanks for your feedback.
We finally got around to investigating this today and you are spot on, were able to build a first example 'long-form' examination question that is entirely and instantly assessed by Drupal CMS / GPT4o...
Notice how the student DID NOT get a mark for their first statement...
"Analog means not digital."
...because we explicitly instruct AI Automator with...
"Do not award marks for vague, circular, or purely negative definitions. A point should only earn a mark if it demonstrates positive understanding — that is, it explains what something is, how it works, or why it matters, not just what it is not."
We will be building quite a range of questions over the next few weeks and very happy to share the experience in any forums / meetups if that's of any use in helping push forward this great module suite.
All of this done without even the need for the Custom field module.
sirclickalot → created an issue.
sirclickalot → created an issue.
sirclickalot → created an issue.
sirclickalot → created an issue.
A great, thank you @helena zajika - I was beginning to doubt myself!
I do not understand; I certainly applaud the use REST (core) to load data but REST UI is a UI module for managing REST endpoints so why have it as a dependency here?
Clearly, we are always seeking to minimise the number modules in play and it seems unnecessary to add this in?
Unless of course, I have missed something obvious here — I often do!
Thanks
sirclickalot → created an issue.
@_shy, yes agreed, it's definitely in relation to using the (latest) Gin theme but it only started when I updated to 1.1.5 so is it possible to narrow down to any changes that occurred then with either the mark-up or default CSS?
sirclickalot → created an issue.
sirclickalot → created an issue.
sirclickalot → created an issue.
sirclickalot → created an issue.
Thank you @a.dmitriiev,
This turned out to be a simple problem of us mis-configuring the Simple Search Form block.
Closing now.
sirclickalot → created an issue.
sirclickalot → created an issue.
@marcoscano,
Yes, I can confirm that after performing a composer update to 2.0.0-beta20 I was still seeing the same error but that a subsequent database update via a drush updatedb fixes the issue.
sirclickalot → created an issue.
sirclickalot → created an issue.
I can confirm that the Mr sorts the issue nicely.
Thank you.
@a.dmitriiev
Great stuff, I'm glad it's not just me!
I may not have been quite clear enough in my description about quite how important this so...
I'll just point out explicitly that the current behaviour means that the ability to snap our FEE pane to full is completely wiped out and pointless because all that happens is we reveal that unwanted sidebar ;-)