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 ;-)
Please forgive me if I have completely misunderstood all this but surely it's really wrong to assume the everyone is using the core Search feature.
Personally, I moved to using Search API years and years and have never looked back.
If I'm not talking nonsense here then surely any kind of mass re-indexing using Core Search should be under the purview of a sub-module?
I for one would never want to see a single menu item that purports to reindex all of my Search API indexes - that would be madness ;-)
Hi @ ordermind → ,
Finally, an answer - brilliant, thank you!
Would you be able share that little snippet of hook code here please then I'll be able to confirm its effectiveness too.
sirclickalot → created an issue.
Yep, same here.
Broken after update to 3.5.2
@mably,
Brilliant!
Not only only does it address the issue, the Taxonomy Terms Glossary and Synonyms modules appear to working in perfect harmony ;-)
Experimentation continues...
No other PHP error logs except the one I mention above.
However, I have tried uninstalling the module and starting from scratch re-installing the DEV from the UI.
It seems to install OK and the modules page refreshed afterwards confirming the install.
But after a cache clear, I am seeing something new and different to before...
[15-Feb-2025 11:08:04 UTC] Uncaught PHP Exception Drupal\Component\Plugin\Exception\PluginNotFoundException: "The "" plugin does not exist. Valid plugin IDs for Drupal\term_glossary\TermGlossaryHandlerPluginManager are: custom_js, default" at C:\Users\nick\Sites\bit-by-bit.org\public_html\core\lib\Drupal\Component\Plugin\Discovery\DiscoveryTrait.php line 53
@mably,
Everything present and correct in both Service PHP code and the associated YAML file.
But hang on, if I'm reading this right, it's not the the service itself that the complaint is about, it's whatever is instantiating it that is at fault because it is supplying only 7 arguments when the code in the constructor for TermGlossaryHandlerPluginManager
is clearly requiring 8?
[15-Feb-2025 10:32:22 UTC] Uncaught PHP Exception ArgumentCountError: "Too few arguments to function Drupal\term_glossary\Service\TermGlossaryManager::__construct(), 7 passed in C:\Users\nick\Sites\bit-by-bit.org\public_html\core\lib\Drupal\Component\DependencyInjection\Container.php on line 261 and exactly 8 expected" at C:\Users\nick\Sites\bit-by-bit.org\public_html\modules\contrib\term_glossary\src\Service\TermGlossaryManager.php line 72
Also for clarity, I am not using Docker - I've always found it to be too sluggish so I simply use the good old native WAMP PRO for Windows.
@mably,
I updated to the DEV branch using composer but to avail - same issue as before - WSD and...
[15-Feb-2025 09:40:18 UTC] Uncaught PHP Exception ArgumentCountError: "Too few arguments to function Drupal\term_glossary\Service\TermGlossaryManager::__construct(), 7 passed in C:\Users\nick\Sites\bit-by-bit.org\public_html\core\lib\Drupal\Component\DependencyInjection\Container.php on line 261 and exactly 8 expected" at C:\Users\nick\Sites\bit-by-bit.org\public_html\modules\contrib\term_glossary\src\Service\TermGlossaryManager.php line 72
On both occasions I have done multiple cache clears before reporting.
I don't think this is PHP dependency/discovery relate is it, I think it might be a PHP 3.x+ issuse or do you suspect that my local site is still 'seeing' an older version of the service provided by TermGlossaryManager.php
?
BTW, I am not uninstalling and re-installing the module, could it somehow be related to new configuration that is only taking effect on reinstall?
Thanks @laurielim
Seems to work for me too.
I'm still a little confused as to why the documentation points us to the GitHub DEV version but maybe it just needs updating.
Hi, we have updated to 4.04
but despite multiple cache clears at various levels, the 'Show show row weights' button is still not clickable.
@mably - thanks for that.
After patching with MR: #3506501 I am hitting a WSD with...
[15-Feb-2025 05:31:11 UTC] Uncaught PHP Exception ArgumentCountError: "Too few arguments to function Drupal\term_glossary\Service\TermGlossaryManager::__construct(), 7 passed in C:\Users\nick\Sites\bit-by-bit.org\public_html\core\lib\Drupal\Component\DependencyInjection\Container.php on line 261 and exactly 8 expected" at C:\Users\nick\Sites\bit-by-bit.org\public_html\modules\contrib\term_glossary\src\Service\TermGlossaryManager.php line 72
I suspect this might be PHP version related as we are on 8.3.7 but rolling that back to 8.2 and even below seems to cause other ill effects for us with other modules so not an option.
Rolling back to 4.2.0-alpha6 for now.
@mably,
OK, I get that and I agree the it is actually sound idea too.
However, in our case matching only the first is the polar opposite of what we need because we have a whole lot of terminology splattered around the place, all of which actually means the same thing and it's really confusing the novices.
Thinking on my feet here possibly the most commonly encountered one is...
You can do this quickly and easily in the console.
You can do this quickly and easily in the shell.
You can do this quickly and easily in the CLI.
You can do this quickly and easily in the terminal.
You can do this quickly and easily in the command prompt.
You can do this quickly and easily in the REPL.
You can do this quickly and easily in the TTY.
If we set aside splitting hairs about true definitions, all of those sentences are 'saying' exactly the same thing so one can see quite why we want to link all of those synonyms to a unifying description that covers all bases.
And that's just the start of it in the computing tutorial world!
So in summary yes, we agree wholeheartedly that, if using a synonym mechanism (such as the Synonyms module), there should be an option to check a box to say Target all synonyms for 'glossification' or not, depending on your use case.
Everybody's catered for, everybody's happy.
PS,
I like the POTUS example, it is especially in the zeitgeist.
Perhaps POTUSageddon is fitting.
sirclickalot → created an issue.
Yep, that appears to have fixed the problem as far I we can see.
Thanks!
I can't be absolutely certain but I think it was either alpha 4 or alpha 5.
No, the quotes do not necessarily need to be in Terms in fact I don't think any of them are. We don't use the quotes in actual terms.
Nor do we think it's quote that happen to be either side of or just nearby the targeted terms, it seems they can be anywhere in fields that module target via its Display widget.
sirclickalot → created an issue.
@mably,
Yes, sure.
Maybe if possible limit it is to plain-text fields or at least field types from which it can extract plaint text.
@mably,
Very definitely good to test yes because to be able to power the pop-ups using synonyms on our site would be a great step forward.
Just to clarify, would be providing the opportunity to pick which field to use as in my mock-up above?
Hi @mably,
OK, so the Synonyms module → allows deep integration of terms that are marked synonyms of other terms and as such it is really powerful addition to sites.
It's configuration is remarkably simple in that it simply ask you—per Tax vocabulary type—to specific which field is the 'Source of' synonyms - these fields are simply plain-text fields.
Thus, we have long ago gone ahead and targeted a field names Synonyms (plural) and so we have a multi-value plaint text field populated all over.
It's just bad luck that we dis not call is Synonym (singular) ;-(
We wonder whether it would be more standard—a vastly more flexible—if Taxonomy Term Glossary enabled the site builder to choose which particular plaint-text field they wish to use as the source of Synonyms too.
Configuring the Taxonomy Term Glossary module (mock-up)
Consider integration with the Synonyms module?
sirclickalot → created an issue.
Thanks @jonsimonsen → ,
We will wait to see the next release and give the 2.x a go when the time comes that it is designated as D11 compliant.
Still fumbling about with theming as described in another issue 💬 Trouble theming some menu items. Active but we're adamant that this module is the one we want to go with moving forward so we'll sit tight and see what happens.
sirclickalot → created an issue.
sirclickalot → created an issue.
Yes definitely.
I must honest, I'm not now sure that I was 100% correct when I said "...no other detrimental effects..." because we were simulating the breakpoints using Chrome which we all understand to less than 100% reliable and while out and about today testing our site on a very slow smartphone connection we saw some more interesting behaviour...
One minute see this...
And the next we see...
So fixing at auto
with a covering min-height
set in configuration would indeed seem very sensible.
sirclickalot → created an issue.
What a weird thing!
I copied the plain text from a plaintext version of the email alert from the DO site, screenshot below...
Ghostly.
Or is it a touché ?
Anyway, all sorted so thanks, this is a really useful addition because now us tweakers can do whatever we like.
Thanks again.
Hi @mably,
This is intriguing...
I have patched my local 4.2.0-alpha2
version and patch applied without issue.
I can clearly see the hook implementation in the term_glossary.api.php
along with the other source code alterations (GUI Git client screenshot)...
I have implemented the hook in my trusty (and very minimal) overrides module (custom_drupal_overrides)...
function custom_drupal_overrides_term_glossary_term_alter(&$term_tag, &$term_id, &$term_value) {
// Alter the term button HTML render array.
$term_tag['#attributes']['data-bs-toggle'] = 'tooltip';
$term_tag['#attributes']['data-bs-placement'] = 'bottom';
$term_tag['#attributes']['fallbackplacements'] = '["top", "left", "right"]';
$term_tag['#attributes']['data-bs-delay'] = '{"show":1000, "hide":100}';
$term_tag['#attributes']['data-bs-html'] = 'true';
$term_tag['#attributes']['data-bs-title'] = 'Pop up an exam-ready-worded definition of this term.';
}
I have cleared every conceivable cache over and over.
BUT no splicing in of the goods?
Very odd, especially since you very helpfully sent me a screenshot of it working locally.
What could we have missed here?
sirclickalot → created an issue.
sirclickalot → created an issue.
Could it be, should it be?