I have created the MR for this. I have applied the success/failure messages by checking the number of successful and failed entities. And also applied the logger for failed entities. Please review once.
Thank You !!
I am working on this request.
Hey @Kingdutch I have corrected the incorrect usage of TranslatableMarkup in README and created the MR for same. Please review.
Thank You !!
I am working on this issue.
@Anybody Thank you for your feedback and sorry if I am not making sense. I understand the importance of addressing this issue with a proper fix thats why I am open to discussion. My point of discussion is that, this module's general purpose is to provide better SEO for comments which involves comment view links. So do we really need to change the Edit and Delete links like we did in the linked issue ? As per my understanding making Edit and Delete links SEO friendly serves no purpose. So I want to know your thoughts on same that how you think of it so that I can learn from it.
I think this issue is coming because of this fix :
https://www.drupal.org/project/comment_fragment/issues/3455106
🐛
Permalink now points to comment/XYZ/edit
Fixed
I think we should revert this fix because I think this module's general purpose is to provide better SEO for comments. So changing the Edit and Delete uri probably may not help us here.
I have placed the MR to revert this fix. Please let me know if you have any other thoughts on same so we can discuss more.
Thank You !!
I am working on this issue.
I checked the history and found out that this has been removed under this issue : https://www.drupal.org/project/drupal/issues/2493911 →
Drupal\Core\Http\Client service has been removed. The recommended approach for handling HTTP requests now is to use GuzzleHttp\Client
This change facilitates easier updates and better security management by relying directly on Guzzle.
I have placed the MR to update the @see annotation to point to the new recommended approach. Please review.
Thank You !!
I am working on this issue.
According to @joachim 's suggestion instead of checking the instance I have applied the condition check the truthy value. I have placed the MR ,please review once. Thanks !
According to @joachim 's suggestion instead of checking the instance I have created the patch to check the truthy value. Please review once. Thanks !
Just to provide more context on above issue, I am only able to reproduce this issue when I use Geolocation Google Maps API - Geocoding and Map in Form display of this Geolocation field.
I was facing similar issue with version 8.x-3.12 when I was adding any string in the Lat/Long fields as soon as focus was going out of field input, it was changing to NaN.
In code, parent set value was being called before the custom code execution. After changing the order of execution it started working for me. I have attached my patch below.
I created one temporary patch which worked for me. Basically node_type condition was causing issues in Extra settings form and also in Conditional plugin handler. So I ignored that condition and make the code move forward skipping that condition. I tried comparing it with fresh Drupal 10 setup where I was unable to replicate this same issue, there also no node_type condition was coming. So something was fishy with this condition only. So I applied this fix and it worked.
Thank You !!
jagraj_singh_gill → created an issue.
Hi @hussainweb,
Thank you for your feedback. I have revised my patch and attached it. Please review and verify. Thanks again !!
Hi @donpwinston,
Can you please provide more details on it ? I tried with Drupal version 9.5.11 with same version as you described i.e. 8.x-1.7
Placed the Superfish menu block in header, Turned off css and js aggregation, Flushed Drupal and browser cache. Checked the page source, browser console as well as Drupal logs. I was unable to replicate the same.
Hello @hussainweb,
I have fixed this issue 'Attempt to read property "value" on array in Drupal\do_username\DOComputedFields->getValue()' and also attached patch.
I feel there were only one change required as all other fields were not fetching any array data.
Please review and verify.
Thank You !!
jagraj_singh_gill → made their first commit to this issue’s fork.
As per my understanding, versioning of Drupal core plays a key role here.
Menu Per Role →
doesn't have a stable release for Drupal core versions below 9.4. Additionally, it lacks the ability to inherit the Parent's visibility settings on Child menu items.
So, these seems to be the good reasons to go for
Menu Item Role Access →