🇸🇳Senegal @diaodiallo

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?

Fixed two coding standard issues.

Added test coverage as suggested.

diaodiallo → created an issue.

Addressed coding standards issues.

Standard issue fixes.

Trying still to fix the same failing test related to schema.

Fixing test issues which are related to stops schema structure.

Adding a patch which adds solidgauge as chart type for 5.0.x-dev.

Best coding styles.

Added more options and updating it for dev release.

Adding annotationHeader, categoryDatetimeHeader and categoryHeader in this patch.
Will see for more options.

diaodiallo → created an issue.

Committed this patch.

Tested it and works well.

Added a patch for this by just removing the @message in the addWarning function.

diaodiallo → created an issue.

Thanks Martin, I tested the patch and it works well.

Thank you milossramek for the feedback.

I tested it and can't access it without an admin account, can you give more details on your issue. Attached some screenshots.

Thanks.

Thank you Jay, let's see if this is still an issue in alpha3.

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

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

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

Thanks a lot for this. I had this issue after deploying a pantheon site to an Ubuntu server with apache.

Just updated

if (isset($_ENV['PANTHEON_ENVIRONMENT'])) {
  $settings['hash_salt'] = $_ENV['DRUPAL_HASH_SALT'];
}

to

$settings['hash_salt'] = 'CHANGE_THIS';

More complete patch which works with Group 1.x, 2.0.x and 3.0.x.

In fact for our case addContent() and getContentByEntityId() do no longer exist in version 2 and 3 of the Group module. The groupContent entity is also replaced by the groupRelationship.

I tested this patch on Group 1.x and 2.0 but is supposed to work with 3.0. Waiting for more feedback.

I think this patch should work, fixing the getContentByEntityId() & the #5 issues.

@qpro I am making sure #5 is not happing however you are supposed to select the content type in this config form /admin/config/content-to-group-settings that's why this was happening.

@arpitk I am not sure why this is happening, however can you check again with this patch?

Hi! anyone have this fixed in 9.5.x I am having this issue on a 9.5.9 Drupal site.

#7 is not working yet.

Thanks.

I am stopping the process early if the subject is empty. This avoid me queue a lot of useless emails.

diaodiallo → created an issue.

diaodiallo → created an issue.

diaodiallo → created an issue.

Thanks Nia for the great work. This patch works for me as excepted for my use case, working with the legacy plugin to use my data from version one.

Howeveer I found two potential issue which worth to discuss:

1. When I enable the generic usage data and the generic usage data counter in plus the legacy plugin I have this exception:

if (!$database_schema->fieldExists($table, $counterField)) {
  throw new \Exception('Usage Data table ' . $table . ' schema should have a counter ' . $counterField . ' column.');
}

Line 77 in srcUsageDataDatabaseStorage.php
I think we need to test more to see how to have them all enabled without issue.

2. I noticed when I visit/view a page where I have a media (I have a video) the module is adding the event_type download for the entity_type_id media row, it should be just 'view'
I think this may be an issue for the version 2 of he module.

Thanks.

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

Hi jeffersonpatron, thanks for your good help here.

I think it's a good solution for the PHP issue. Can you please give more clarification about the #type attributes?
To go quickly with the urgent PHP patch we should maybe take off the UI issue before we have more understanding and unanimity.

Manu thanks