🇸🇳Senegal @diaodiallo

diaodiallo → created an issue.

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

Thanks mdruilhe, vistree.

Ohh you are right I was focussed on the topic call, opening it again.

A patch for 10.3.x.

A new patch for 10.3.x

Hi @mdruilhe thanks for your codes I am going to push it.

Hi @mdruilhe this was fixed 2 days earlier and released with the version 1.1.0. I think you found it in a previous version.
I am going to close the issue, feel free to open it if you find it again.

This is fixed in this duplicate issue Invalid default frequency settings 🐛 Invalid default frequency settings Active

Hi @mdruilhe thanks for the work on this issue.

I did a small update and tested the code, I wanted to make sure we still keep track the old config structure to make sure people do not loose data till we hook_update it.

Adding a patch however this will be applied to a new 2.0 version of the module since this is a very big difference and some people would like to stay with the old concept.

diaodiallo → created an issue.

Thank you mdruilhe for this work, I will review it soon.

Thank you and sorry for the delay, I will check this.

Thank you @amit.rawat777 I will check this.

diaodiallo → created an issue.

A patch fixing this issue.

diaodiallo → created an issue.

Hello, I am sharing a patch I refactored for my colleague @yospyn.

As mentioned @yospyn we have synonyms in a term field which need to be called 'field_synonym' (Just add this field and your synonyms to use the patch).

Thanks to @JakeAPoe for the patch I used it for this version 3 patch.

Added an updated patch.

I had this issue when updating 10.2.6 to 10.3.1 and fixed by just cleaning cache. Thanks to @Kasey_MK for the idea.

Need to test the four new tokens within this patch.

Working under 1.0.4 version.

Thank you @bjsomers, this is actually a duplication of another issue https://www.drupal.org/project/forum_notifications_subscription/issues/3401680 🐛 Call to a member function get() on null in getForumName() Needs work

diaodiallo → created an issue.

Added a patch.

diaodiallo → created an issue.

Added a patch.

diaodiallo → created an issue.

Added a patch.

diaodiallo → created an issue.

Added the patch.

Hi @vistree sorry for the delay.

After closely checking this issue I found this is from the drilldown plugin itself, I think the main thing is because the main label is a clickable text so the formatting is different with the drilldown label.

See attached screenshot from the plugin demo.

Updated the readme file.

diaodiallo → created an issue.

Yes make sense @smustgrave. Thank you.

Thank you @smustgrave, maybe it could be nice to see this jQuery_ui_slider stuff before pushing this module.

I am not sure, are we going to reference this new module NoUiSlider Better Exposed Filters → in this documentation?

diaodiallo → created an issue.

Thanks @martin and @Harpreet_singh_saluja for your nice work.

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

I actually think the work around this should focus on the deletion process.
#1 Someone remove a post.
#2 A hook (something like hook_ENTITY_TYPE_delete()) check if this node id has a forum_notification_frequency (this nid means the entity_id of the frequency)
#3 If That forum_notification_frequency exists it removes it.

Here is the Entity definition itself

Here is how to get notification by id

So should implement the same thing to get notification by subscribed entity id (entity_id) in the ForumNotificationsSubscriptionService class.

After finding it we should delete it so we will no longer fall on it when looping frequencies in the user_form.

Please let me know if someone want to work on this or if there is any need for clarification.

Hi Chetan, thanks for working on this.
After quick review of this I think we need not just to return a default name but also do more i.e about the frequency around that post.

I reviewed the patch group-notify-beta1-3436167.patch. I think can go to RTBC.

Thank you @phjou for your patches, I will check it and let you know.

Here is a patch to support both versions.

diaodiallo → created an issue.

Thank you @ericmulder1980 I spent almost half a day with this issue and your small code is working perfectly for me.

Changing the status so more user can test and confirm.

RTBC.

Moving this patch to 2.0.0-beta1.

Hi all,

I am having this same issue with Drupal 10.2.0, when I upload a file which too large (150mb) than the maximum (10mb) nothing happen but was supposed to have error message that the file is larger than allowed. However a size like 15mb trigger the error message.

Thanks for any helping idea.

Hi, I am having this same issue with 2.2 but patch 2 is not working. Do someone fix this on 2.2?