🇬🇧United Kingdom @SirClickALot

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?

Thanks again!

For consistency in my composer.json, am I able to use an npm-asset-style line as above in my question.

Notwithstanding any individual's work, I would rather use a reference to the node asset library if possible and if so, might it simply be...

"npm-asset/chosen": "^3.0" ?

Hi @wouters_f → ,

Yes, we are extremely interested in helping develop such a feature.

We would be able to allocate significant time to helping with trialling/ testing since one of has a lot of time our hands!

Why?...

Well, the background to all this is that we have been building a community education site for Computer Science learning.

The site is aimed at help both students and teachers by providing a single port of call for an entire free course for teaching and learning Computer Science.

Very important to point out that the intention is to build a community of teachers who contribute to, and of course, then use the site as the core content of their teaching. Hence our insistence on doing it in Drupal.

While we are quite happy with the instant feedback with of our 'quick self-test' material using H5P, but there is a very clear need to enable students with instant feedback on free text that write by matching it up with 'Model answers' and commenting back to help them improve on anything they are missed or got not quite right.

We have put an extraordinarily large amount of time and effort into developing this Drupal-based education suite because we think it will make a huge difference to young folk trying to get into Computer Science and school level but who don't have the luxury of access to high quality teaching.

It's here if you are interested in have a quick look…
Bit-by-Bit.org

We also have a short Ladybird-book-style 5-minute read on the project for busy educators to give them an idea of the vision…
The Bit-by-Bit project

Actually, we don't see this as necessarily an education-specific either, more generically, some sub-module that enables the site-builder to identify one field (maybe even cross-content-type) as 'FOR critique', another as the 'critique context' and a final one as 'critical comments' in which to stuff the results.

That generic approach would leave the door open to all of use-case-specific 'bells and whistles' such as (for example) a designated field of 'keywords' to focus in when writing the critique.

Just ideas at this point but very keen to get a dialogue going ;-)

Thank you.

Hi nagy.balint,

Thanks for your guidance here but can you please be more specific about precisely which version I should be using?

In the past (for some reason?) I have been manually downloading and adding the Chosen JS library but once I am clear about the precise version, is it OK for me to add it into my sites' composer.json using similar lines these I use for some other libraries...

"npm-asset/lazysizes": "^5.3",
"npm-asset/select2": "^4.0",
"npm-asset/superfish": "^1.7",

Thanks a lot.

I can confirm that with the dev branch 4.2.x this is all now working exactly as we think it should.

Another very fruitful dialogue with the maintenance team to help move on this excellent module.

Thank you.

Absolutely working as it should.
Brilliant...

Hi @vinayakmk47,

I'm afraid I don't understand what you mean here by "...check the changes I made..."

What exactly do you want me to check?

Hi @mably → ,

When I apply the patch from the MR in #9, I see the follow pre-flight...

I then get a series of 'complaints' along these lines...

A few clicks later down the line and my IDE says that "...patch applied but with errors..." or something like that.

The upshot of all this is that some of the functionality is certainly there but I don't think everything is working. For example, I am able to configure a desired setting and this does seem to persist after saving the configuration...

However, when I try it out in the front end, while it is undoubtedly different to before, the dialog appears to be adopting a default height which is much too high for the enclosed content and a width set at 500px (I get from the Inspector)...

I'm not sure my visual evidence here is particularly useful given that the patch didn't apply cleanly at all but I hope it helps in some way.

Should apply the associate patch (23.patch) to my current ^4.2@alpha version?

Me too!

sirclickalot → created an issue.

Hi @mably → ,

This is great, a vast improvement if you ask me — which you did!

It means that we can pop-up a shortened version with the potential to one or more links to the 'full' version and extra 'learning-related' deeper-dive content. It is EXACTLY what we'd hoped for.

One thing...

It would be very useful to have an option — perhaps even per vocabulary choice — to be able two set the width of the JQuery pop-up window.

In the example illustrated below, the slightly wider version (based on 33% of the overall windows width) looks nicer - I might agree that this is only subtle example but the descriptions are a lot longer, the default (narrow) width makes that whole user experience much less appealing.

Default width...

Tweaked to illustrate the value of being able to set the width...

Great work, we will certainly be pushing this live once 4.2x goes into release.

As a further bit of feedback -we can close https://www.drupal.org/project/term_glossary/issues/3486637 🐛 Partial words are being matched Active now since I was unable to determine why we were having the issue with the pop-up not appearing for certain roles but we don't care anymore because 4.2x doesn't seem to to give us the same problem.

sirclickalot → created an issue.

I will do very soon, I'm still struggling with https://www.drupal.org/project/term_glossary/issues/3486637 🐛 Partial words are being matched Active right now :-(

sirclickalot → created an issue.

They certainly do otherwise you wouldn't be able to see all these goodies...
https://bit-by-bit.org/tutorials/primitive-logic-gates

OK, a bit more feedback but I accept that the lack of a pop-ups at all for UID:1 and the endless AJAX for the Anonymous user is probably not the fault of this module.

The URL I provided was merely to show that the Anonymous does indeed have access to the Glossary taxonomy terms.

We are only testing the module locally so we're afraid we can't supply a real live test URL for you but all this should help to make things clearer...

UID:1 user

No pop-up at all.

When clicking the anchor in the text and inspecting the Network tab we a see...

When we visit the same URL directly in the browser we see...

// Status 200 (dns:0ms,tcp:0ms,req:1155.7000000029802ms,res:0.6999999955296516ms)
{
  "name": "Data",
  "tid": "4379",
  "description": "\u003Cp\u003E\u003Cstrong\u003EData \u003C\/strong\u003Econsists of \u003Cstrong\u003Eraw\u003C\/strong\u003E, \u003Cstrong\u003Eunprocessed \u003C\/strong\u003Efacts, while information is data that has been organized and given meaning.\u003C\/p\u003E"
}

Which all seems in order.

Anonymous user

As in the previous posts, when the Anonymous user clicks an anchor, they get a pop-up but they see a continuous AJAX throbber and the Network Inspector tab shows...

Something is trying to redirect access to that ULR?

This is then followed by...

I'm not sure quite what creates that URL - core or something else? But whatever, the Anonymous user cannot get there and seems to be being redirected - very odd since that can easily visit the 'normal' /taxonomy/term/4376 URL.

As far as we are aware, we do not have modules that perform redirects on 403 - we DID but they've all long gone in this testing and we've cleared every conceivable cache culprit.

Anyway, I thought this might all be useful to someone even if it doesn't necessarily point to any bug in this module.

No JavaScript error in the Console, that was the place we looked.

Taxonomy definitely open to the Anonymous users: https://bit-by-bit.org/glossary

Hi @mably,

We have tried the update module and yes, this seems to have fixed both the partial-word blocking feature request and the once-only one.

Nic work.

We have however noticed some other behaviour...

Anonymous and UID:1

For both the Anonymous user and UID:1 there is NO POPUP at all when clicking a highlighted anchor...

We thought at first that this might be something to do with Taxonomy permissions — we also use Taxonomy Access Fix to enable all roles to view Vocabulary names — but it does not appear to be to do with that.

Logged in users

For a logged in (less powerful) user, we do get one, and it all seems to work (albeit after a fairly long delay) to populate the pop-up...

sirclickalot → created an issue.

Hi miguelpamferreira → ,

Thank you for coming back to me.

Yes, you are quite correct, it is indeed a simple image field but I don't want it to be copied by default and I'm sure that other will probably want that kind of control too since, at the end of the day, while it's truly a reference field it 'kind of' is.

Thanks

sirclickalot → created an issue.

Hi @doxigo → ,

Thank you for coming back to me on this.

I'm afraid I'm not backend savvy enough to produce an MR so I'll have to wait for your magic to kick in.

I have tried many other 'floating' TABS modules and none of them come close to yours. In fact most of don't even seem work very robustly at all.

Now that I know your intentions, I have also raised another issue 💬 Trouble theming some menu items. Active relating to theming other menu items — this is something that has been driving us mad for ages so I thought now was the time to raise it.

Thanks again, great work.

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 module maintenance team,

Could you possible give some guidance/reaction here please.

I have checked and double-checked this and I pretty sure it's a major oversight.

For that reason I'm going to up the status.

Thank you

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,

The problem with the Memory Game H5P turned out to be the fact that for some odd reason, it's not implemented in an <iframe> like all the others and so the CCS injected by my custom module did apply to it EVER.

The solution for me was simple and that was to include the CCS overrides for that particular question type in my actual site instead.

Here's what mine looks like (obviously, you won't be able to reference the variables such as $theme_color_1 etc.

/********************
* Memory game START *
*********************/
dl.h5p-status {
  display: none;
}
.h5p-memory-game {
  overflow: unset !important;
  ul {
    padding-left: 0 !important;
    margin-left: 0 !important;
    li {
      .h5p-memory-card {
        margin-left: 0;
      }
    }
  }
  .h5p-memory-card {
    margin-top: 0;
    margin-bottom: 0;
    .h5p-front {
      border: none;
      border-radius: 6px;
      background-color: $theme_color_1 !important;
      span {
        &:before {
          font-family: "Roboto Condensed", sans-serif;
          color: $theme_color_paper_color;
        }
      }
      &:after {
        display: none;
      }
    }
    .h5p-back {
      border: 1px solid $theme_color_4;
      border-radius: 6px;
      background-color: $theme_color_paper_color !important;
    }
  }
  .h5p-memory-reset {
    display: none;
  }
  .h5p-feedback {
    &.h5p-show {
      display: none;
    }
  }
}

/******************
* Memory game END *
*******************/

Here it is in action for real...
https://bit-by-bit.org/tutorials/primitive-logic-gates#toc-logic-snap

sirclickalot → created an issue.

sirclickalot → created an issue.

It turned out to be rogue remnants in the key_value table...

That would explain the other five offending modules too!