- πΊπΈUnited States Greg Boggs Portland Oregon
I would like to add to this to mention that on my Drupal 9 site, this module accounts for between 20%-50% of all the resources uses by a page load depending on the cache status of the page when loaded. While it's cool that it's fancy for folks who need that up to the second detail, we really just use it to display a note at the top of the page. So, spending 50% of our used server resources displaying a note at the top of the screen seems... like something we want to improve.
- π¬π§United Kingdom malcomio
Regarding the cache lifetime, that has been made configurable in β¨ sitewide_alert cache max age value is hard coded Fixed , but I agree that this module shouldn't be making so many requests, and ideally would include everything it needs in one page load.
- πΊπΈUnited States chrissnyder Maryland
I like this idea. I am wondering if we can implement it in a way that allows the alert rendering method to be configurable. For some projects I have worked on, the advantage of this module over other similar modules or a solution using normal blocks/views is that this module was designed to avoid breaking fully cached pages, including those cached downstream (varnish, reverse proxy), at a time when a new alert is published site wide. One of the main goals of loading the alerts as a separate request was to allow pages to be fully cached independently of active alerts. In addition, this module also supports showing alerts for those who have already loaded the page.
Example situation when this is important:
A university, school, or government agency needs to publish a very important time-sensitive alert sitewide at a time when traffic to the site is abnormally high. This may be an alert regarding public safety. With this change, adding a sitewide alert would cause the page cache of all the pages on the site to be invalidated (due to the cache tag), resulting in excessive stress on the site as it needs to rebuild all of the pages at a time when traffic is high and the information is important.However, this situation/use does not apply to all sites, so it should be configurable to allow the site builder to choose which loading method fits their project.
- πΊπΈUnited States Greg Boggs Portland Oregon
The module would literally crash any website using it while their traffic was abnormally high. So that feature does not exist despite what the project description says.
- Merge request !41Issue #3291075: Render site alerts in drupalSettings β (Open) created by malcomio
- last update
over 1 year ago 8 pass - π¬π§United Kingdom malcomio
Work in progress on a slightly different approach in https://git.drupalcode.org/project/sitewide_alert/-/merge_requests/41
The change is fairly minimal - just moving the alerts into
drupalSettings
This probably needs further thought from a security and performance point of view.
Also, as per #5, ideally we would make this configurable.
- last update
over 1 year ago 8 pass - First commit to issue fork.
- Open on Drupal.org βCore: 9.5.x + Environment: PHP 7.4 & MySQL 5.7last update
about 1 year ago Not currently mergeable. - last update
about 1 year ago 4 pass, 8 fail - last update
about 1 year ago 8 pass - last update
about 1 year ago 4 pass, 8 fail - last update
about 1 year ago 4 pass, 8 fail - last update
about 1 year ago 4 pass, 8 fail - πΊπΈUnited States mlncn Minneapolis, MN, USA
Would absolutely love this with the further enhancement that if "Automatically Update (Refresh) Alerts" (polling) is disabled in
/admin/config/sitewide_alerts
and "Dismissible" is disabled for the alert(s), there is no reason to load the init.js (or any other) JavaScriptβ yet more optional performance enhancement and site admin flexibility for this excellent module. - last update
about 1 year ago 4 pass, 8 fail - last update
about 1 year ago 4 pass, 8 fail - πΊπΈUnited States chrissnyder Maryland
Would it be possile to include this feature as a configuration option so that the existing functionality is preserved for those who need it and the new ability to avoid the extra request is avoided for others?
- Open on Drupal.org βCore: 9.5.x + Environment: PHP 7.4 & MySQL 5.7last update
about 1 year ago Waiting for branch to pass - Open on Drupal.org βCore: 9.5.x + Environment: PHP 7.4 & MySQL 5.7last update
about 1 year ago Waiting for branch to pass - Open on Drupal.org βCore: 9.5.x + Environment: PHP 7.4 & MySQL 5.7last update
about 1 year ago Waiting for branch to pass - Open on Drupal.org βCore: 9.5.x + Environment: PHP 7.4 & MySQL 5.7last update
about 1 year ago Waiting for branch to pass - Open on Drupal.org βCore: 9.5.x + Environment: PHP 7.4 & MySQL 5.7last update
about 1 year ago Waiting for branch to pass - Open on Drupal.org βCore: 9.5.x + Environment: PHP 7.4 & MySQL 5.7last update
about 1 year ago Waiting for branch to pass - Open on Drupal.org βCore: 9.5.x + Environment: PHP 7.4 & MySQL 5.7last update
about 1 year ago Waiting for branch to pass - Open on Drupal.org βCore: 9.5.x + Environment: PHP 7.4 & MySQL 5.7last update
about 1 year ago Waiting for branch to pass - Status changed to Needs review
11 months ago 12:15am 29 January 2024 - Status changed to RTBC
10 months ago 2:02pm 11 March 2024 - ππΊHungary aron novak Hungary, Budapest
We tested it on a client project, worked well.
- Open on Drupal.org βCore: 9.5.x + Environment: PHP 7.4 & MySQL 5.7last update
9 months ago Waiting for branch to pass - First commit to issue fork.
- Open on Drupal.org βCore: 9.5.x + Environment: PHP 7.4 & MySQL 5.7last update
7 months ago Waiting for branch to pass - πΊπΈUnited States rpayanm
I added some suggestions and fixed the test error. Please review.
- π¨π¦Canada ibullock London, ON
+1 for RTBC, been using in the wild for a few months now without issue.
@qusai taha, you can just click on the plain diff and that's a patch already, no need for a separate patch
- π―π΄Jordan Qusai Taha Amman
Re-roll the patch to make it working with latest version
- π―π΄Jordan Qusai Taha Amman
Re-roll the patch to make it working with latest version