🇵🇱Poland @mahyarss

Committed and pushed to 2.0.x-dev.

Thanks @shane-birley for reporting this issue!

Committed to 2.0.x-dev. Thanks @shane-birley for reporting this issue!

This will be included in the next release.

I've tested the patch and confirmed it resolves the block save issue. The fix is minimal and only uncomments the essential parent::blockSubmit() call.

Thank you @shane-birley for reporting this issue and taking the time to provide clear reproduction steps. Your detailed report made it easy to identify and resolve the problem.

I've investigated the issue and created a patch that addresses the block configuration save problem. The attached patch resolves the issue where countdown block settings were not persisting after saving.

Could you please apply the attached patch and test it in your environment?

Applying a patch
Download the patch to your working directory. Apply the patch with the following command:
git apply -v [patchname.patch]

Here's how to test:

1. Apply the patch to the module
2. Clear your site's cache (drush cr)
3. Edit an existing countdown block or create a new one
4. Make some configuration changes
5. Save the block
6. Edit the block again to verify your changes were saved

Please let me know if this resolves the issue for you or if you encounter any other problems. Your feedback is valuable to ensure this fix works properly across different use cases.

Thank you again for your contribution to improving the Countdown module!

I've identified the root cause and have a working solution.
Problem Analysis:
The issue occurs because simple_menu_icons_rebuild() calls \Drupal::service('renderer')->renderInIsolation() which triggers theme registry initialization during the rebuild process. This causes $modulesByHook array in ModuleHandler to be cleared while still being iterated over, resulting in the TypeError.
Solution:
Move CSS generation from hook_rebuild() to hook_cache_flush(). This is semantically correct since CSS generation is a cache operation, not a data structure rebuild.
Testing:
Tested with Drupal 11.0.x and confirmed:

• Multiple drush cr executions complete without errors
• CSS generation works correctly
• Menu icons display properly

Patch attached: simple_menu_icons-d11_hook_rebuild_fix-3543309-2.patch

The patch includes:

1. Replace hook_rebuild() with hook_cache_flush()
2. Add simple_menu_icons_generate_css_content() function to avoid renderInIsolation() during rebuild
3. Add error handling and validation
4. Update hook documentation

Steps to reproduce the fix:

# Apply patch
patch -p1 < simple_menu_icons-d11_hook_rebuild_fix-3543309-2.patch

# Clear cache multiple times to verify
drush cr && drush cr && drush cr

# Verify functionality
drush ev "simple_menu_icons_cache_flush();"

This change maintains backward compatibility with Drupal 10 while fixing the Drupal 11 issue.

Fixed in: 8.x-1.11

Feature request completed after 14 years!

Original request (2010):

"Add option to count down in real time using Javascript"

What we delivered (2024):

Not just a simple JavaScript countdown, but a complete real-time countdown system with modern architecture:

• Pure Vanilla JavaScript - No jQuery dependency
• ES6 Modern Architecture - IIFE/UMD pattern
• Zero External Dependencies - Lightweight (~2KB gzipped)
• Drift Compensation Algorithm - Maintains accuracy over days/weeks
• Multiple Update Frequencies - From minutes to milliseconds
• Full Drupal Integration - Works with Drupal 8/9/10/11

Beyond the original request:

The implementation includes features that weren't even imagined in 2010:

• WeakMap memory management
• Event-driven architecture with custom events
• Programmatic JavaScript API
• Multiple display formats and custom templates
• Completion actions and elapsed time mode
• Debug mode for development

Performance metrics:

• Size: ~2KB gzipped
• CPU: < 0.1% usage
• Memory: Efficient WeakMap prevents leaks
• Accuracy: Drift compensation maintains precision

Credits:

Thanks to all 50+ contributors who participated in this issue over the years. Special recognition to early contributors whose ideas shaped the final implementation.

The wait is over. Real-time JavaScript countdown is not just here—it's better than we ever imagined!

For any issues with the new implementation, please open a new issue. This long-standing feature request is now officially closed.

This highly requested feature has been fully implemented in the 8.x-1.11 major refactor, exceeding the original requirements with a comprehensive solution.

What's been implemented:

• Real-time JavaScript countdown - The core request, now reality
• Dual-mode rendering system:
  • Static mode: Server-side (preserves backward compatibility)
  • Real-time mode: Client-side JavaScript countdown
• CountdownTimer library features:
  • Configurable precision (minutes, seconds, tenths, hundredths, milliseconds)
  • Drift compensation for long-running accuracy
  • Auto-start on page load
  • Pause/resume/stop/reset controls
  • Event-driven architecture
• Display formats:
  • Default (HH:MM:SS)
  • Verbose (3 days, 2 hours, 1 minute)
  • Compact (3d 2h 1m)
  • Custom templates with tokens
• Advanced features:
  • Completion actions (hide, message, redirect, reload, elapsed mode)
  • Timezone support
  • JavaScript API for programmatic control
  • Count up mode (elapsed time)

Technical details:

// New vanilla JavaScript implementation
const timer = new CountdownTimer({
  selector: '#countdown-display',
  mode: 'countdown',
  precision: 'seconds',
  autoStart: true,
  driftCompensation: true
});

// Full API available
Drupal.countdown.controlTimer(blockId, 'start|pause|resume|stop|reset');

How to enable:

1. Update to 8.x-1.11
2. Edit your countdown block
3. Change "Render Mode" to "Real-time JavaScript countdown"
4. Configure precision and display options as needed

Download: https://www.drupal.org/project/countdown/releases/8.x-1.11 →

Thank you to everyone who contributed ideas and patches over the years. Your patience has resulted in a robust, modern implementation!

Fixed in: 8.x-1.11

Closing this issue as definitively fixed.

What was the problem:

The countdown displayed static time without real-time updates.

How it's fixed in 8.x-1.11:

• New CountdownTimer library with real-time countdown
• Drift compensation for accuracy
• Multiple precision levels (seconds to milliseconds)
• Lightweight vanilla JavaScript (no jQuery dependency)
• Modern ES6 architecture (IIFE/UMD pattern)
• Full Drupal 8/9/10/11 compatibility

Key improvements:

• Performance: Optimized render loop with configurable update frequency
• Accuracy: Drift compensation maintains precision over hours/days
• Compatibility: Works with all modern browsers and Drupal versions
• Size: ~2KB gzipped, zero external dependencies

Upgrade path:

composer update drupal/countdown
drush updatedb
drush cache:rebuild

Configuration:

Simply switch to "Real-time JavaScript countdown" in block settings to enable the dynamic countdown feature.

The architecture has been completely modernized to prevent this issue from recurring. Should you experience any problems with the new implementation, please open a new issue with:

• Drupal version
• Browser details
• Block configuration export

Thank you for your patience with this long-standing issue. The wait is over - real-time countdown is here!

This long-standing issue has been completely resolved in the 8.x-1.11 major refactor.

Solution implemented:

The module now features a brand new CountdownTimer library (vanilla JavaScript, ES6) with:

• Real-time countdown mode - Live countdown with configurable precision (seconds to milliseconds)
• Drift compensation algorithm - Maintains accuracy over extended periods
• Zero dependencies - Pure vanilla JS, no jQuery required
• IIFE/UMD pattern - Modern architecture compatible with Drupal 8/9/10/11
• Auto-start capability - Begins counting immediately on page load
• Dual-mode rendering:
  • Static mode (server-side, SEO-friendly)
  • Real-time mode (client-side, dynamic countdown)

The JavaScript now properly initializes and continuously updates the countdown display, completely eliminating the "frozen time" issue.

To enable real-time countdown:

1. Edit your countdown block
2. Select "Real-time JavaScript countdown" under Render Mode
3. Configure precision (seconds recommended for most use cases)

Download 8.x-1.11: https://www.drupal.org/project/countdown/releases/8.x-1.11 →

Please test with the new version. If you encounter any issues, open a new issue with your specific configuration.

Closing as fixed in 8.x-1.11.

The release is now available at:
https://www.drupal.org/project/countdown/releases/8.x-1.11 →

If you experience this issue after updating, please reopen or create a new issue.

This issue has been resolved in the 8.x-1.11 release (major refactor).

The module has been completely refactored with proper Drupal dependencies:

- All JavaScript libraries now include core/drupal dependency
- New CountdownTimer library with proper dependency management
- Tested with anonymous users - no errors

Fixed in commit: [commit hash]

Thanks @alex.bukach for reporting this issue!

Thanks for reporting this issue. I can confirm the problem with required entity reference fields auto-selecting the first option when using the Select (ActiveTags) widget.

I've identified the root cause and prepared a patch that addresses this by:

• Adding proper empty option handling for required fields
• Preventing browser auto-selection behavior

Please test the attached patch and confirm if it resolves the issue for you.

Fixed styles

I tried to move the “Introduction” guide out of the main Contributed module documentation listing and place it properly under the “Active Tags” documentation section by changing its Parent to "Active Tags". While it now correctly appears as a child under the Active Tags project, it still remains listed on the main documentation landing page.

link issue

Correct link parent.

Fixed image src.

Fixed Guide reference.

Text and style correction

Text and style correction

Text and style correction

Style correction

Style correction

Style correction

Text and style correction

Text and style correction

Style correction

Text and style correction

Text and style correction

Added detailed configuration guide and finished documentation structure.

Change menu item weight

Added this documentation guide to the project’s Related content section for better discoverability.

Thank you for your thorough testing and detailed feedback. Since no one has reported this issue with AnimateCSS On Scroll before, it’s likely related to a specific configuration in your environment.
To narrow down the cause, please:

1. Test on a fresh Drupal 11 install with only this module and a core theme (e.g., Claro), without additional modules or custom settings. Check if fadeInUp with Top bottom anchor placement works as expected.
2. Before scrolling, inspect the element: share a screenshot of the Styles tab (looking for opacity: 1, visibility: visible, or !important) and any Console JavaScript errors.
3. Confirm whether you’ve altered the AOS.js version via the AOS JS UI module (e.g., switching from AOS 3 to AOS 2). If so, please test with both versions to see if it makes a difference.
4. Verify AOS settings in the module’s form are correct.

Please share:

• Results of the fresh install test.
• Styles tab screenshot and console errors.
• Details of any customizations, additional modules, or changes to the AOS.js version.

If the fresh install resolves the issue, consider taking a backup of your site and disabling other modules one by one to identify potential conflicts. With your expertise, I’m confident we can resolve this quickly, and I’d be thrilled to help you get this sorted. Looking forward to your update!

Thank you for reporting this issue. I’ve tested the AnimateCSS On Scroll module on a fresh Drupal installation using the default Olivero theme, and the images were correctly hidden initially before the fadeInUp animation triggered as expected. This suggests that the module is functioning properly in a standard setup.
The issue you’re experiencing might be related to the theme or custom CSS in your setup. For instance, CSS rules like:

img {
  display: block;
}

or even the use of !important could interfere with the Animate.css library, preventing the initial hiding of elements before the AOS animation kicks in.

Suggested Steps to Troubleshoot:

• In the animation configuration form provided by the module, please try enabling the following options one at a time:
  • Clean previous classes: This ensures that any conflicting CSS classes are removed before applying the animation.
  • Fix Display: This option adjusts the display property to ensure compatibility with AOS and Animate.css.
• After enabling each option, clear the Drupal cache to ensure the changes take effect.
• Test the animation again and observe if the issue persists.

Could you please try these steps and share the results? Additionally, it would be helpful if you could provide:

• Details about the theme you’re using.
• Any custom CSS or JavaScript that might affect the images or AOS animations.
• Whether this issue occurs with other animations or anchor placement settings.

Looking forward to your feedback to help narrow down the cause and find a solution!

Thanks again! 😊

Thank you for your reminder and for pointing it out!
I've now removed the "page display template project description." and replaced it with a proper message.

Thank you @pearls for using the Phone Number module and for taking the time to report this issue. I appreciate your contribution to improving the module!

I have reviewed and fixed the reported issue, and a new version has been released. Please update to the latest version and let me know if you encounter any further issues.

Thanks again for your feedback!

I encourage you to test the current alpha version, and please feel free to provide feedback or report any new issues you encounter.

Thank you for your feedback and for pointing out the issues. The current development version of the module has been available as an alpha release for quite some time. This version was released during the very early stages of development, and at that time, the code was still incomplete and in the process of being structured.

I want to clarify that the coding standard issues reported are from that early phase, and since then, the code has been significantly improved and aligned with Drupal's standards. I appreciate your observations, but as the module has now evolved past this initial stage, I will be closing this issue.

The fix is now included in the newly released 1.0.1 version. Marking this issue as Closed (fixed). If you encounter any further issues, please feel free to report them.

Your contributions are greatly appreciated!

Thank you @berliner for confirming that the issue has been resolved in the development branch.

Please ensure you are using the most recent version of the AnimateCSS Block → module, as it includes the necessary fixes for this error.

If you continue to experience issues or have any further questions, feel free to reach out, and I would be happy to assist.

Thank you for your patience and feedback!

Thank you for reporting the issue.

The error you encountered is not directly related to the WOW JS module. The root cause stems from a misconfiguration in the Animate CSS Block module. Specifically, the error occurs when the wow setting is enabled, but the configuration property third_party_settings.animatecss_block.wow.enable is missing or improperly set.

I have investigated the issue, and with the latest updates in the Animate CSS Block module, this issue has been addressed and resolved. The patch has been applied to the new version, and I recommend using the latest release to resolve this problem.

If you encounter any further issues or have additional questions, feel free to reach out, and I will be happy to assist you.

Thank you for your contributions and feedback!

I had been waiting for feedback on the previous patch, but since I haven’t received a response, I took the initiative to personally test the patch in various scenarios. Based on my testing, the issue appears to be resolved.

Additionally, I have released the latest version of the module, which includes the fixes and improvements. You can now use the updated version.

For reference, you can check the related issue in the AnimateCSS module: https://www.drupal.org/project/animatecss/issues/3422199 🐛 Cannot install via admin/modules UI: "animatecss.settings" does not exist. Closed: works as designed

It seems that this issue is related to the AnimateCSS → module, as the error about the route `animatecss.settings` is also discussed there. In that issue, it's mentioned that the problem is typically resolved by clearing the cache (using `drush cr`), which also appears to be the case here.

Since this seems to be a known issue with the **AnimateCSS** module, I will be closing this issue for now. Please feel free to reopen it if the issue persists or if you need further assistance.

If you need further assistance or if the issue arises again in the future, feel free to reopen the issue, and I will be happy to continue the investigation.

Since I haven't received any further responses regarding this issue, I assume that the solution provided has resolved the problem. Therefore, I will be closing this issue now.

Hi @delacosta456, @ananya.k,

Thanks for your efforts in testing and reporting! Based on the previous feedback, I’ve made further improvements to address the deprecated warning when passing null to the `strtr()` function. In addition, I've thoroughly tested the patch to ensure that it resolves the "memory exhausted" error that was also occurring with the previous patch.

Could you please test it again on your end and let me know if it resolves both issues?

Thank you @justcaldwell for reporting this issue and @berliner for providing a patch to address it!

I have reviewed and applied the patch, and the issue has been resolved. The fix is now included in the latest development version: 1.0.x-dev (updated on 6 Dec 2024). It will also be available in the upcoming stable release.

Your contributions are greatly appreciated. If you have further feedback or encounter any related issues, please feel free to share!

Thank you @berliner for reporting this issue and suggesting a solution!

The issue was in the frontend JavaScript and has been fixed in 1.0.x-dev (updated on 6 Dec 2024). Setting "Number of results" to 0 now correctly shows all terms in the dropdown.

Could you please test the latest development version and let me know if everything works as expected? Your feedback is always greatly appreciated!

Hi @berliner,

Thank you for reporting this issue and for suggesting a solution.

Before this issue was opened, I made changes to the CSS to address whitespace and line break problems. Specifically:

I updated the white-space property in the dropdown from pre to normal to ensure proper handling of spaces.
Additionally, I removed the following CSS rule:

.active-tags__dropdown__item-highlighted {
  display: flex;
  flex-direction: row;
}

These changes have already been included in the latest development version: 1.0.x-dev (updated on 6 Dec 2024 at 23:03 UTC). Could you please test this version and let me know if the problem is resolved with these updates, or if further adjustments are needed?

Your feedback is invaluable, and I greatly appreciate your contribution to improving the module.

Best regards,
Mahyar

Thank you for your feedback, @berliner. I see you’ve opened a new issue (#3491949) regarding this concern. I’ll follow up there with more details.

Hi @justcaldwell,

Thank you for pointing that out! Your observation is correct—the changes from your Merge Request were not merged directly but were included as part of a broader update to the module.

I have applied your proposed fix, along with several other improvements, and published them in the latest development version: 1.0.x-dev (updated on 6 Dec 2024 at 23:03 UTC). The fix for the input name/classname mismatch in the Media Library modal is now available in this release.

Feel free to test the development version and let me know if everything works as expected or if there’s anything else to address. Thank you again for your valuable contribution!

Best regards,
Mahyar

Thank you, @justcaldwell, for reporting this issue and submitting a Merge Request!

I have reviewed and accepted the proposed changes in MR. The issue is now resolved, and the fix has been successfully merged into the branch (1.0.x).

Marking the status as Fixed. If any additional feedback or issues arise, please feel free to share.

This issue has been resolved and is now being closed. The fix will be included in the next release (active_tags 1.0.1).

Thank you, @Berliner, for reporting this issue and providing a solution!

The proposed change has been tested and merged into the 1.0.x branch. The issue is now resolved.

Since the Animate CSS Block module adds animations to a block's settings form based on the configuration options of the Animate CSS module, it uses the block’s default system ID as the selector. Therefore, an additional input field for specifying a custom selector isn’t necessary in the block's settings form.

However, if you're using the Event option in the block animation settings and require a more specific selector for triggering the event, you can modify it after saving the block settings. Simply navigate to Administration > Structure > Animate List at the path admin/structure/animatecss, and there you can update the saved block's selector.

Please let me know if this solution resolves your issue.

Have you checked the settings for limiting the library files being loaded? You can find these settings in the module configuration:

1. Navigate to: /admin/config/user-interface/fontawesome.
2. In the settings form, under the "Usability" section, go to the "Files" tab.
3. Disable the "All styles" option.
4. You’ll see a list of individual file components (Font styles) that you can selectively enable for loading, depending on your needs.

Additionally, I recommend using the latest Dev version I released today, which includes a new "custom-icons" option under the "Files" section.

To use custom icons, you can place your custom icon files in the library installation directory at libraries/fontawesome:

• For CSS: libraries/fontawesome/css/custom-icons.css
• For JavaScript/svg: libraries/fontawesome/js/custom-icons.js

It’s also advisable to create a minimized version of your file:

• libraries/fontawesome/css/custom-icons.css
• libraries/fontawesome/css/custom-icons.min.css

Based on your description, I believe this solution should meet your needs. However, if I’ve misunderstood, please provide more details about your custom files/icons, and feel free to attach your file if possible.

Just to clarify, are you asking about limiting the loading of specific Font Awesome styles (e.g., solid, regular, brands), so that only the styles you need are loaded? This would help reduce the amount of resources being loaded on your site.

If this is not what you meant, could you please provide a bit more detail or clarify your request? Understanding exactly what you're looking for will help us better address your needs.

Looking forward to your response!