🇬🇷Greece @vensires

vensires → created an issue.

Thank you both for your feedback. I am sure I wasn't clear enough but my question was actually focused on this issue's context.

💬 Support to use the datetime-local element Active was focused on the DateTime Element type as used in a render array. On the other hand, this exact issue was created in order to address . An example code came from Webform's created/completed/changed columns as displayed in https://git.drupalcode.org/project/webform/-/blob/6.3.x/src/WebformSubmissionListBuilder.php?ref_type=heads#L887.

If what @vortexcentrum says is true, I would like to find the exact commit this was fixed in. I couldn't find any recent changes to the same files the patches here proposed.
Maybe the fix happening in Drupal v11.2 is related to one of the following issues but I might be completely off: 📌 [11.x] php 8.3 follow up for enum in Datetime range formatter Active , 🐛 Date based template_preprocess BC code is incorrect Active , 💬 Support to use the datetime-local element Active

Finding the exact commit that fixed the issue might also help generate a future-compatible patch for still supported earlier versions.

vensires → created an issue.

I also agree we could use the submodule ckeditor5_plugin_pack_font from the "CKEditor 5 Plugin Pack" module for this functionality.

I am trying to identify what should be done and in which module...
I scanned pathauto's code and it seems the only thing actually needed is the following code:

\Drupal::service('pathauto.generator')->updateEntityAlias($entity, 'update');

So, we could directly invoke this call with a proper if pathauto module exists then condition. The question already rose in #2872697-23: Stop saving an entity when it gets added to or removed from a group → by @berdir but it's not yet clear what should be done exactly since this might affect other custom or contrib modules we're not currently aware of.

I currently vote for a submodule for the pathauto implementation. It could event get installed by default as part of an upgrade if the module is enabled in the installation. This submodule could also work as a best-practice example for any other module to solve the same problem in its own context.

vensires → created an issue.

Hm... Back to Needs work then...

Thank you for your work on this. Merged!

@axioteo I checked your code and seems to be correct. We already only support Drupal versions greater than 10.2 though, so we don't actually need the compatibility layer. I have done the required change in MR. Uploading patch too.

Please validate it's working as expected and I will gladly generate a new release immediately afterwards.

vensires → made their first commit to this issue’s fork.

vensires → created an issue.

For a website of ours, I use this fulltext facet filter to search for keywords. The client asked that whether user searches for "foo bar" or "bar foo" the returned result should be the same. I tried playing around tampering the query using proper Search API Events but instead fell back on changing the original patch from this issue's MR (attached) so that the 'LIKE' operator uses multiple conditions instead using AND.

I'm sharing this here too in case we would like a different approach for this or propose a different operator... Maybe...

if ($operator === 'LIKE') {
  $or_condition_group = $this->query->createConditionGroup('AND');
  $tokens = preg_split('/\s+/', trim($this->fulltext->getSearch()), -1, PREG_SPLIT_NO_EMPTY);
  foreach ($tokens as $token) {
    $or_condition_group->addCondition($this->facet->getFieldIdentifier(), $token);
   }
   $this->query->addConditionGroup($or_condition_group);
}

vensires → created an issue.

poker10 → credited vensires → .

poker10 → credited vensires → .

vensires → created an issue.

vensires → created an issue.

vensires → created an issue.

vensires → created an issue. See original summary → .

vensires → created an issue. See original summary → .

Thank you @danrod! I see you haven't added the following line of code in the MR though. Is it intentional?

\Drupal::service('page_cache_kill_switch')->trigger();

Since you provided the patch, I set it as Needs Review for someone else to approve this and set it as RTBC.
Can you also update the MR with the changes?

Based on the previous two comments, I would take the chance to set it as RTBC but... Has anyone else experienced the I had to click on "Save configuration" twice for some reason issue described previously by @danrod?

The tricky part here is that the dl isn't a button in the editor; so no one actually knows it's there, unless you use the plaintext editor. I also checked other documentation pages like Access Policy API → and it seems you are correct. I vote +1 for this change.

PS: Might you want to ask this on slack in a broader community? Though I think it's a decent choice to change this as you proposed.

vensires → created an issue.

I closed the MR so that anyone willing to tackle this issue may start the process from the very beginning.
To be honest though, I did try to find the comment described in the issue summary but couldn't find it at all in the code. Maybe something is off here or was it just me?

vensires → made their first commit to this issue’s fork.

No, I didn't test it to be honest. It seemed like a small change. Did you review my solution yourself?

The original patch had set the return value in the catch{} block and it's actually working. My suggestion in the MR is to instead have it at the end of the function. It seems more clear to me.

@drupaldope thank you for the clarification! I set it as Needs Review then!

The my menu--navbar.html.twig file phrase in #3 confused me; I'm changing this to a support request.
Feel free to revert my change in case I was mistaken.

MR should fix the issue.

vensires → created an issue.

@wotnak, if you don't have any further issues with the MR, you might also consider mentioning either the vite plugin or just this issue in the module's project page description. I see you already have a link to the README.md file; it might just be a bit more fancy - maybe adding another "note-tip" CSS class. Whatever you decide though.

I have fixed the issue in the MR.
I also took the initiative to change the string used so that it says (minimal) and not (minimal-) if the version is missing. I think it's never actually translated so I won't introduce any further issues with this change.

I suspect it was to be set as "Reviewed & tested by the community" but the user misclicked. I set it as Needs Review for now and anyone is free to check the patch and either review it or create a MR based on it with any possible corrections.

@drupaldope, it's not clear to me whether the issue is resolved with your patch or whether the whole issue was a false report.
Could you please clarify?

So, @giannisMak do we need a new MR for this to fit what @saurav-drupal-dev described in #13?

the css should come inside toolbar file because we cannot access dropdown without the admin toolbar

@axioteo, feel free to update README.md with the correct details on how to fix this issue, either using your plugin either without it (if possible).

After this is resolved, we might open another issue to suggest the change of the description of the module if required by @wotnak.

@smustgrave, I think that the points already addressed by @theodorosploumis in #6 is the answer you are looking for:

1) Consistency, as mentioned on the issue title.
2) Performance. Mini pager is less heavy than the full pager.
3) Usability. Media are usually attached to Nodes. So navigating to the first or last item is not something really important.

Feel free to express your objection on the previous points though.

I leave this as Needs Work because I'm not 100% sure the patch and the MR are in accordance.

Added Greek Community digital presence info.

Since this issue is related directly to the navigation module of the Drupal core and not the menu links in general, I think it's well set as postponed, yes.

I add 📌 Plugin config: Delete entity along with GroupContent Needs review as a related issue due to the following comments in code:

1. GroupRelationship::preSave()(L.259-264)
   

   // We want to make sure that the entity we just added to the group behaves
   // as a grouped entity. This means we may need to update access records,
   // flush some caches containing the entity or perform other operations we
   // cannot possibly know about. Lucky for us, all of that behavior usually
   // happens when saving an entity so let's re-save the added entity.
   $this->getEntity()->save();
   

2. GroupRelationship::postDelete()(L.295-301)
   

   // For the same reasons we re-save entities that are added to a group,
   // we need to re-save entities that were removed from one. See
   // ::postSave(). We only save the entity if it still exists to avoid
   // trying to save an entity that just got deleted and triggered the
   // deletion of its relationship entities.
   // @todo Revisit when https://www.drupal.org/node/2754399 lands.
   $entity->save();
   

Created new MR based on 11.x. Uploading a patch for this too.

For tests, don't count on me unfortunately.

I have updated the issue summary.

It seems my previous code didn't work. I have changed the query to a formula in order to be able to check whether the comment_count has a non-zero value and act accordingly.

I have created a MR and also attach the diff as a patch for anyone needing this.