Okay, just tested one thing. Dismissed the test banner, changed the start and end date, saved it and reloaded the page. No banner.
So once gone for a user, gone for good?
Okay, just tested one thing. Dismissed the test banner, changed the start and end date, saved it and reloaded the page. No banner.
So once gone for a user, gone for good?
Ah! Thatâs a very good point actually @Roi, and the short answer is yes.
Each banner is assigned an ID based on the index number, and the plugin-outlet name. Then, the ID of the closed banners are stored to browserâs local storage.
So, if a banner is closed, even if its configurationâs changes it will remain hidden.
I see that can be a problem; Iâll think of a better way to handle this. â Suggestions are welcome : )
The versatile-banner uses a cookie name setting, which admins can change to make the banner visible again for users who dismissed it.
Thanks for the pointer @Moin, renaming the cookie to invalidate the saved cookies looks like a very practical solution.
In Notification Banners the banners can be moved up and down to change the sorting order, or change the outlets. That can potentially keep a new banner hidden if there was a banner in the same place and dismissed previously.
Seems I need to change how the IDs defined, and then perhaps adapt the cookie method. ![]()
Then cookies seem to be a better way than the ids, especially when the ids change when you change the sorting order. ![]()
In my eyes it would be useful to generate a new (cookie) id every time the banner is changed.
About cycles: If it was Christmas already I would wish for a cycle which can be done in weekdays (one or more) and day of month (one or more). And maybe for both something like âevery xâ, so that I could choose e.g. âevery second Monday and Fridayâ or "every 1st and 16th of every third month).
Actually, I was able to solve this issue with a hybrid solution.
A new Banner config version setting which will apply to all banners; and new individual Banner ID values.
The real IDs for each banner are constructed using both of the values. This method should provide a better flexibility IMHO:
I will deploy this change soon.
update: The v1.4.0 is now out.
Introduced a unique[1], required Banner ID field for each notification banner and updated related settings, migration logic, and tests to support this change. Additionally, added a Banner config version setting to help reset banner visibility for users when important changes occur. These improvements ensures that banner dismissal tracking to be more robust and future-proof.
The uniqueness is up to the user. Unfortunately the theme object settings donât allow requiring unique values. However, the tab label now uses the ID value to make them more visible. âŠď¸
Wow great! Thank you! I will test and give you feedback. ![]()
Works as said! Great. Thank you again! ![]()