Working on it.
Hey,
I think we can close this issue, as the functionality here works as expected.
The basic functionality for both subscribing and unsubscribing is working fine for users and administrators.
Thanks !
Hey @jorisclaes,
Thanks for the clarification!
I initially removed the $items->isEmpty() check because I added a fallback at the end:
return !empty($elements) ? $elements : [['#markup' => $formats[$format][1]]];
However, I now see that keeping the early return makes the logic clearer and more efficient, since it avoids even entering the loop when there are no field values.
I'll restore the $items->isEmpty()
check and update the MR. Thanks for the feedback!
Also, while raising the MR against 11.x, it reflected around 1236 commits to be merged to the 11.x branch, so I think the 3505775-boolean-formatter-behavior branch needs a rebase to sync with the latest 11.x.
Please let me know, what's best here, to proceed further.
Thanks!
Working on it.
Hey,
I have implemented the fix to ensure the Boolean field formatter properly displays FALSE when the value is empty. Previously, empty boolean fields were not rendered, which caused confusion for end users expecting a clear ✔ or ✖ (or any other format) output.
Changes Made:
- Updated BooleanFormatter.php to handle NULL values by defaulting them to FALSE.
- Ensured that empty boolean fields are now correctly displayed in Views or any other place too, where the field is is used.
- Refactored the logic to prevent skipped fields and improve code readability.
Commit: Link
Please review and test the patch to confirm expected behavior.
Let me know if any improvements are needed.
Thanks!
Working on it.
Hey @tjtj,
I have tried reproducing the issue on my local, although on the module installation I didn't receive any error related to the database table. I am using version 1.0.0 of Statistics module and also tried the same on both Drupal 10 and 11.
And, on looking into the Database I can see the table node_counter was present there.
Can you please provide the steps to reproduce the issue, If I am missing something here.
Thanks !
Hey @tim bozeman,
After some research into the cause of this issue, I found that the version we're using—1.0.0—has not been updated. The commit (link) that changed the module name from Toolbar+ to Navigation+ is present only on the 1.0.x branch and is not included in the deployed 1.0.0 tag.
As a result, the version we are installing via Composer still includes the module name as Toolbar+ instead of Navigation+.
Could you please take a look and confirm if this understanding is correct? Let me know your thoughts.
Thanks!
Hey @scbritton,
You can find the name with the name of Toolbar+ under the Page Building section on the /admin/modules
.
Please have a look and let me know if there is anything else I can help with. I am attaching the screenshot for reference.
@tim bozeman, to avoid any confusion, we could consider renaming the module in the toolbar_plus.info.yml
file or updating the name on Drupal.org. Let me know what you think!
Thanks !
Hi,
I've added the test case for the Piwik PRO snippet when loaded via the library. The test ensures that:
- The configuration is set correctly.
- The snippet is loaded from the library.
- The expected piwik_domain appears in the drupal-settings-json script.
Please review the changes and let me know if any modifications are needed. Thanks for your guidance!
Hey @martonadam,
I have tried reproducing the issue you have mentioned. I am using Drupal 10 and version 2.0.0 of Realname, but on installing the module I didn't received any problem.
I even tried installing the module from UI, didn't face any black screen issue and it shows "Module Real Name has been installed" without any error related to database name.
I am attaching screen shots related to the site of both before and after enabling the module.
Please let me know if I am missing something here.
Thanks!
Okay @phenaproxima,
Let's wait until one of the two ways available, is decided, I'll continue on this further if required.
Thanks!
Working on it.
Hi,
Thanks for the feedback! I’ve made the following updates based on your suggestions:
- Ensured isVisible() is checked before adding the library in piwik_pro_page_top(), so the new script loading method respects exclusion settings.
- Improved the admin UI description to avoid confusion about "external libraries."
I've also cleared the cache and tested the changes, ensuring they work as expected. Let me know if there's anything else you'd like to adjust!
Thanks again!
Hey,
I think the mentioned changes have been made, the tests are also running fine now.
Please have a look.
Thanks!
Hi @jaykumar95,
The issue has been resolved in the provided MR, which has now been merged, But I think you forgot to add credit to the developers who have worked on it. Please have a look into it, as these credits keeps us motivated and acts as a fuel to work on contributing further.
Thanks.
Thank you, @heikkiy.
The PHPCS and ESLint errors have been resolved as well. I am currently working on finalizing the PHPUnit test cases.
Hey,
I have reverted the previous changes and added the mentioned functionality.
Changes made:
- New Setting: Added a boolean field to the module settings page, Load Piwik PRO snippet from a library, as per your suggestion. The default value is set to false, ensuring backward compatibility with existing implementations.
- Load Snippet from Library: Updated the module to check the new setting value. If the setting is TRUE, it will load the JS file from the external library. If FALSE, it will continue using the old method by injecting the Piwik PRO snippet directly into the DOM.
- Installation Hook: Added an installation hook to set the default value of the new setting (FALSE) for sites that already have the module installed.
- ESLint and PHPUnit Tests: The current ESLint and PHPUnit test failures are acknowledged and are still in progress. I am working on updating the tests to reflect the new script loading mechanism:
- When the setting is FALSE, the test will check if the Piwik PRO domain is present in the DOM.
- When the setting is TRUE, the test will validate if the new piwik_pro/piwik_pro_snippet library is properly loaded.
I am still working on finalizing the test validations. Please let me know if there are any other changes or adjustments that need to be made, and I will add them.
I am attaching the screen shot for the config form page.
Thanks for the guidance and let me know if you have any further feedback!
Hey,
I have tested version 3.5.1 (3.x-dev) on Drupal 10 and did not encounter any flashing issues with the menu. I also tested it by navigating between pages and using different themes on my site, but the issue did not occur. The functionality of admin toolbar is working fine.
For better clarity, I have attached a screenshot. Please let me know if you need any further details.
Thanks!
Thank you @joachim and @quietone for your guidance and support in resolving this! I really appreciate the insights shared in this discussion.
After reviewing everything, as per knowledge, I would like to suggest updating the issue status to "Closed (Works as Designed)" instead of "Fixed", as there was no underlying bug or code change required. The taxonomy field is working correctly on the user registration form, and the issue does not seem to be present in the default setup.
As I mentioned in my previous comments, if the field is not appearing, it is likely due to configuration settings, such as ensuring the Register form mode is enabled and properly configured under Manage Form Display. Once these settings were verified and adjusted, the taxonomy field displayed as expected.
Since this appears to be a configuration-related matter rather than a core issue, I believe "Works as Designed" would be a more appropriate resolution. However, please let me know if there are any other considerations or if I may have overlooked anything. Please have a look into this.
Thanks again for the support and valuable input!
Hi,
The changes look good. The input fields under the Advanced Search now display properly in both the mobile view and tablet view (around 768px). They are no longer getting cut off.
Thus, moving it to RTBC.
Thanks!
Hi,
I tested version 2.0.3 (2.0.x-dev) of the Infinite Scroll module on my Drupal 10 site, and the "Load More" button works fine for me on a Views Block.
Here are a few things to check if you're facing issues:
1. Ensure the "Use AJAX" option under the Advanced section of the view is set to "Yes".
2. Confirm that the Infinite Scroll option is selected and correctly configured under the Pager settings of the view.
I have attached a screenshot of my configuration and a video demonstrating the functionality and settings. Please review them and let me know if I'm missing something or if the issue has been resolved.
Thanks!
Hi,
As mentioned earlier, the issue with the hamburger menu not working was due to incorrect paths in the plugin_path variable in test.js, which pointed to /themes/custom/
instead of /themes/contrib/
.
I resolved this by dynamically setting the theme path in drupalSettings using the following approach:
$theme_path = \Drupal::service('extension.list.theme')->getPath(\Drupal::theme()->getActiveTheme()->getName());
$variables['#attached']['drupalSettings']['smartyAdmin'] = [
'themePath' => '/' . $theme_path,
];
Updated test.js to:
var plugin_path = drupalSettings.smartyAdmin.themePath + '/assets/plugins/';
This ensures the correct path is used dynamically, avoiding hardcoding issues. Now, whatever the path of the theme be, the scripts will load dynamically.
I've raised an MR with the changes.
Thanks!
Hey @jaydeep_patel,
I have done the styling for the buttons and also attached the screenshot of how the buttons look after making the changes.
Although while styling the same, I found an issue with the search form present on the sidebar region, which is not functional because of pull-left
class being attached to the form in smarty_admin.theme
file in the smarty_admin_form_alter
hook. This class acts the same as float: left;
property, which hides the search form.
Please have a look into this and let me know any further changes needed. Thanks.
Working on it.
Hi,
I encountered an issue where the hamburger menu in the theme was not working correctly. After debugging, I discovered that the JavaScript files required for the functionality were not being loaded due to incorrect paths. Specifically, the plugin_path variable in the test.js file was pointing to the custom folder instead of the contrib folder. So, whenever we install the site it is installed in the '/themes/contrib/' rather than '/themes/custom/'.
Here’s a summary of the issue and resolution:
Issue:
- The JavaScript files, including bootstrap.min.js and jquery.flot.min.js, were not loading.
- The browser console showed MIME type errors and 404 errors for the JS files.
- The incorrect path in the plugin_path variable was causing the system to look for files in /themes/custom/smarty_admin/ instead of /themes/contrib/smarty_admin/.
Resolution:
- I updated the plugin_path variable in the test.js file to:
var plugin_path = '/themes/contrib/smarty_admin/assets/plugins/'
- After this change, the JS files were correctly loaded, and the hamburger menu started working as expected.
Recommendation:
Please update the test.js file in the theme to ensure the correct path (contrib instead of custom) is used for plugin_path.
Alternatively, consider making the path dynamic to avoid hard-coding issues in the future.
Currently, I am raising the MR with the changes and attaching the screenshots along with the error Let me know if you need any further details or assistance.
Thanks!
Thank you @arunsahijpal for making the changes.
Everything looks fine as per the requirements.
The above MR consists the patch changes too mentioned in #14, which has added the below functionalities :
- The failed login attempts are now being added to the database schema, in "login_history" table, where the validation is being done by the username and password. Also the entries are being properly managed (deleting user deletes the related entries).
- The label of Event Type is changed to "Login Type".
- The validation for unsuccessful email login attempt has also been added to the module, and not only for username.
I have done proper testing of the changes and everything works fine.
I am attaching the screen shots for the reference.
anish.ir → changed the visibility of the branch 3482342-move-js-snippets to hidden.
Hey @heikkiy,
The current issue fork does not contain the 1.2.x
branch. I tried updating the fork and creating a new branch, and received this error : Failed to create branch '3482342-move-snippets-js': invalid reference name '1.2.x'
.
Hey @tamannarahuja,
Thank you for reporting this issue! I have reviewed the functionality of the Simplenews module, and here are my findings:
User Subscription/Unsubscription:
- The module provides a block that can be placed on the sidebar (or any other region). This block displays the list of available newsletters for users.
- Users can manage their subscriptions directly by checking newsletters to subscribe.
- The block also includes a "Manage existing" button for easier subscription management. This allows the users to access the functionality to check for subscribing and unchecking them to unsubscribe.
Administrative Mass Unsubscription:
- For administrators, there is a "Mass Unsubscribe" feature available under the "People" > "Subscribers" section, where email addresses can be added in bulk to unsubscribe users.
Attached are screenshots of both the user-facing block and the admin mass unsubscribe feature for reference.
From my testing, the basic functionality for both subscribing and unsubscribing is working fine for users and administrators. If there are specific concerns about the user interface or usability that you were referring to, please let me know, and I can explore further enhancements or adjustments.
Thank you !
Working on it.
Hi camilo.escobar,
Thank you for your detailed review and feedback on the MR. I appreciate the time you took to analyse the changes and provide valuable suggestions.
Regarding the Role Selection and Checkbox:
I’ve implemented the suggested changes to ensure that the "Trigger email if users have the 'Authenticated user' as their only role" checkbox (admin_content_notification_authenticated_user_only) is not effective when the "Authenticated user" role is deselected in the configuration form. This ensures that both configurations work in combination as intended and avoids the problematic scenario you described.
And for the Log Entry for Non-Configured Roles:
I’ve considered your comment about logging entries for users with roles that aren’t configured to trigger emails. Since this might not add significant value for admins or developers, I’ve removed the log entries for such cases.
Please let me know if there are any further adjustments needed. I’m happy to iterate further.
Thank you again for your guidance!
Hii,
I’ve successfully implemented the changes requested.
Now, the system will only trigger email notifications for users who have only the 'Authenticated user' role. This ensures that users with additional roles (like "Administrator" or "Editor") will not trigger notifications, as per your requirements.
To make this configurable, I’ve added a new checkbox in the settings: "Trigger email if users have the 'Authenticated user' as their only role". This option will only appear when the "Authenticated user" role is selected, allowing administrators to control the behavior more precisely. Also, updated the logic in admin_content_notification.common::isCurrentUserRoleAllowedToSendNotification
to check the user roles accordingly.
Please review the changes and let me know if everything works as expected or if any further adjustments are needed.
I am attaching a screenshot for the reference.
Thank you !
Working on it.
Hi @a.dmitriiev,
I have reviewed the additional public methods in the src/FloodUnblockManagerDatabase.php
class that query the flood table and added the necessary validation to check whether the flood table exists. Here are the changes made:
1. Added a floodTableExists() check in all relevant public methods of the FloodUnblockManagerDatabase class:
- floodUnblockClearEvent: Ensures the table exists before attempting to clear flood entries.
- getEntries: Returns an empty array if the table does not exist.
- getEventIds: Returns an empty array if the table does not exist.
2. Updated the Drush commands in FloodUnblockCommands to handle cases where getEventIds or floodUnblockClearEvent might not proceed due to the missing table.
Please let me know if any additional adjustments are needed. Thank you !
I'll check for the rest of the public methods too.
Hi @a.dmitriiev,
I have reproduced the issue by deleting the flood table and visiting the /admin/people/flood-unblock page, which resulted in the error:
The website encountered an unexpected error. Try again later.
To address this, I’ve added a validation to check whether the flood table exists:
If the table exists : The functionality works as expected.
If the table does not exist :
- A logger error is recorded: "The flood table does not exist."
- The /admin/people/flood-unblock page displays the message: "There is no table found named flood."
I’ve attached screenshots showing the behavior before and after implementing the changes for your reference.
Please let me know if any additional changes are needed, such as:
- Displaying an error message at the top of the page.
- Adjusting the wording of the message.
Thank you !
Hey @joachim,
I followed your suggestion and checked the "Register" form mode under "Structure > Display modes > Form modes". Here’s what I did:
1. I accessed "Structure > Display modes > Form modes" and ensured that the "Register" form mode was enabled for the "User" type by
editing the form mode and selecting the checkbox for "User."
2. Then, I navigated to "Configuration > People > Account settings > Manage form display" and switched to the "Register" form mode tab.
3. I enabled the "Favourite Genre" taxonomy field and configured its widget settings there.
After completing these steps, the "Favourite Genre" field is now visible on the /user/register page, and everything is working as expected.
Attaching a screenshot for the field settings and form mode.
Thank you !
Thank you @joachim for the clarification! I’ll check the configuration for the registration form mode and ensure the field is enabled there. I’ll update here once I’ve verified it.
Hey @khoebeke,
I have followed all the mentioned steps, and the taxonomy field is visible on the user registration form. I am attaching screenshots for reference. I am using Drupal 10.4.0 and have created a vocabulary named "Genre," which I added to the user registration form.
Here’s what I did:
1. Created the "Genre" vocabulary and added terms.
2. Added a taxonomy reference field to the user entity and configured it to appear on the registration form.
3. Verified whether the field is enabled under the Manage Fields section.
4. Cleared all caches after making the changes.
Could you please confirm if there are any additional steps I might have missed? Also, kindly check if the field is enabled in the Manage Fields section for the user registration form or if there are any known issues with this setup in Drupal 10.4.0.
Thanks for your help!
Hey @astonvictor,
I think this issue has been fixed in
#3493225 →
.
The hook_install has been removed and the config install has been added.
We may close this now.
Hey @pearls,
I tried reproducing your issue by registering new users but there were no such errors mentioned above. I am using Drupal 10.4.0 and the module versions I have used for testing were 2.x-dev and 8.x-1.4. There were no errors received on both the versions and the module works fine for me.
Please can you provide more detailed steps to reproduce the issue.
Attaching screenshots for reference.
Hey,
I have added the condition to attach the library using hook_library_alter instead of hook_page_attachments ( which was attaching it directly).
Please have a look and let me know if there are any changes need to made here ( as suggested by @jurgenhaas )
I am attaching a screenshot for console when a anonymous user visits the site, no error is present.
Thank you.
Working on it.
Hey,
I have changed the 'config_filter' references to 'config_ignore'. I think this will work for both - older sites containing config_filter and the new ones where config_filter is not present.
Please have a look.
Thank you !
Working on it.
Hey,
I have updated the PHP unit method, the PHP unit tests are working fine now, also rebased the 3.0.x branch to this branch as the PHP unit was giving error :
Unable to install modules: module 'private_message' is incompatible with this version of Drupal core.
Now the PHP unit tests are all good but PHP stan gives an error :
Call to an undefined method : Drupal\private_message\Mapper\PrivateMessageMapper::getCanUseRids().
Although the function was used earlier too.
Please have a look.
Working on it, for PHP unit.
Hey,
The issue cannot be reproduced with the mentioned Steps. I request the reporter to please provide the detailed steps for better understanding.
Thank you.
Hii @arunsahijpal,
Everything works fine as mentioned. But the function "login_history_update_8004" in login_history.install file is declared twice.
Here is the error for reference.
PHP Fatal error: Cannot redeclare login_history_update_8004() (previously declared in /app/web/modules/custom/login_history-3233477/login_history.install:111) in /app/web/modules/custom/login_history-3233477/login_history.install on line 154
Fatal error: Cannot redeclare login_history_update_8004() (previously declared in /app/web/modules/custom/login_history-3233477/login_history.install:111) in /app/web/modules/custom/login_history-3233477/login_history.install on line 154
Please have a look.
Hey,
I have applied the MR ( MR !158 ) on version : 8.x-1.x-dev and also on 1.18.
The label's text is being aligned in the center, attaching the screenshots for both after and before for reference.
Hence, moving it to RTBC.
larowlan → credited anish.ir → .
Thank you for the feedback!
The initial tests were placeholders to verify the test setup, I’ll remove the example tests and the MaskKernelTest.php too, and have tests extend MaskKernelTestBase.php directly. I created this as a concrete test class to provide a base for tests, but I now realize it’s redundant.
I mistakenly had LibraryInfoAlterTest.php extend MaskKernelTest.php. It should extend MaskKernelTestBase.php directly, and I’ll correct this.
I’ll restructure the tests. Thanks again for pointing this out!
Hey @mattyg77,
I have reproduced the issue on version 6.0.0-rc2 on my local, and the issue seems to be of the configuration settings of the theme.
I have applied the settings you have mentioned in the screenshot attached and was also facing the same issue.
On some research I got to know that the cause of the issue is the "Fixed Position" Checkbox being enabled in your settings, under : "Header & Main Menu" > "Mobile Header" > "Fixed Position".
Disable the option ( remove the check from the checkbox ) and save the settings, see if the issue still persists. As for me it was resolved after doing this.
If it works as mentioned we either need to change the issue summary and check the functioning of "Fixed Position".
Please let me know if this works and anything else I can help with.
Thank you !
Hey @tim-diels,
I have implemented the suggestion you have made, please have a look. There are no pipeline issues and it is fixed too.
I have refactored the MaskUnitTest by creating a MaskUnitTestBase class for shared setup logic and moved the concrete test cases to MaskUnitTest. This follows the same structure as MaskKernelTest.
Please let me know if any changes are needed!
Hey,
I have updated the module files to use dependency injection, as mentioned.
Please have a look.
Hey,
If someone is not able to reproduce this issue, please follow these steps:
1. Make sure the layout paragraphs module is enabled and you have already created some paragraph types.
2. Add the content type to the mercury editor ( probably from "/admin/config/content/mercury-editor" and add a field to this content type of
entity reference type, set 'Type of item to reference' to Paragraph.
3. Change the field's format to Layout Paragraph under the Manage Display of the content.
After these steps, whenever you edit or create new content type you can see the '+' icon mentioned in the video under steps to reproduce section.
I have tried resolving the issue, added the back button but the form we want to go back to, is an AJAX form, and the method I am using is AJAX to load that form, but there is some issue and the form is not rendering.
Please let me know if there are any changes I can make in the code to make it work properly.
Hey,
I have added the return types to the stub file as suggested.
Please review.
anish.ir → made their first commit to this issue’s fork.
Hey,
I have resolved the issues and warnings stated above, but there is a warning stating that : No tests found in some classes.
There were 2 PHPUnit test runner warnings:
1) No tests found in class "Drupal\Tests\mask\Kernel\MaskKernelTest".
2) No tests found in class "Drupal\Tests\mask\Unit\MaskUnitTest".
WARNINGS!
Tests: 8, Assertions: 21, Warnings: 2.
I think we need to add some tests in these classes.
Thank you !
Hi @tim-diels,
I have fixed one of the test's error, working on the other one.
I'm getting warnings that MaskKernelTest and MaskUnitTest are abstract, but they're being used directly. I'm currently extending MaskUnitTest in FieldWidgetPluginTest, (and many more places) which works fine, but the warnings persist.
Should I:
1. Ensure these abstract classes are only extended and not instantiated directly (seems most likely)?
2. Remove the abstract keyword if it's unnecessary?
Which approach would you recommend to resolve this issue?
Thanks for your help!
Hey @nginex,
Thank you for the reference, I have updated the MR. Please have a look.
Hey @nginex,
I have tried implementing your suggestion but the funciton formatSize() is deprecated in Drupal 10.
I have also tried using : Bytes::toHumanString(Environment::getUploadMaxSize())
but it was also not working as expected to be.
Please have a look and let me know, whether I need to revert the changes or not.
Okay, I'll do it.
Hey @jkingsnorth,
I have installed the module (with version - 4.0.18 ) on my local and on uninstalling the module there was no error as mentioned, please can you mention a detailed method to reproduce the issue.
Here is the screenshot for the reference.
The eslint issues are fixed now.
Please have a look.
Hello @mattyg77,
I tried reproducing the issue by using : 'composer require 'drupal/dxpr_theme:^6.0@RC'' but I think the issue has been resolved in 6.0.0-rc2.
As when I tried reproducing the issue using the above command, the version 6.0.0-rc2 was installed automatically and the issue was not found in that version.
Please have a look on this, attaching a screenshot for the same.
Hey @sourojeetpaul,
I have resolved the Merge conflicts on the MR, please have a look.
Thank you !
I'll resolve the merge conflicts.
Hey @astonvictor,
The MR you have raised have some stylelint and PHPCS errors, should I resolve them?
Hey,
The configuration settings are being loaded now rather then default settings.
Please review.
Working on it.
Working on it.
Hey @agentrickard,
In the issue (
link
📌
Fix failing test
Fixed
), the MR has been merged to 2.0.x. so do we need to rebase the branch in the current issue branch ?
I have resolved the merge conflicts.
Please have a look.
@yas
The comment you have posted on my MR has been resolved. Although there is a merge conflict since there has been a new commit that was merged into the main branch.
Working on it, resolving.