Support » Plugin: WP ADA Compliance Check Basic - Most Comprehensive Web Accessibility Solution for WordPress » Honor the HTML Validation suggested plugin notice’s dismissal

  • Resolved KZeni

    (@kzeni)


    As it is now, the notice shown suggesting people check out the HTML Validation plugin (https://wordpress.org/plugins/html-validation/) is dismissible, but that doesn’t have any code seeing if it’s been dismissed (per https://plugins.trac.wordpress.org/browser/wp-ada-compliance-check-basic/trunk/wp-ada-compliance-basic.php#L357 [it just sees if the plugin is installed or not & doesn’t see if the notice has been previously dismissed]).

    As such, it keeps showing this notice even when it’s previously been dismissed. Having this be a persistent notice is really something that can rub people the wrong way & have them look to go elsewhere to avoid having something like that always shown (for those that don’t want or otherwise have an alternative to the HTML Validation plugin.)

    ​Proposed fix for this notice:

    1. Make it so the dismissal triggers an AJAX call via a script that’s included alongside the notice which then has update_option save the dismissal to the site’s settings (using transients isn’t reliable for this & can still have it show more often than users want/expect so using options is the better way to go.)
    2. The dismissal option being saved could be a timestamp so determining if the notice is shown can show if that option isn’t set yet and/or the timestamp in the option is beyond a certain duration (ex. a year or so.) Alternatively, it could have the plugin version as what’s saved as the option so it shows whenever a different version of the plugin is being used from when it was last dismissed (probably more relevant than being time-based.) Then again, it could be a permanent dismissal of that message by using a simple boolean setting for it being dismissed.
    3. This notice could then still be shown 100% of the time on the plugin’s settings page for those looking to check/update things regarding the accessibility setup. I think that would be entirely reasonable & potentially helpful.
Viewing 6 replies - 1 through 6 (of 6 total)
  • Plugin Author seshelby

    (@seshelby)

    Hello, thank you for taking the time to suggest updates to the plugin. After completing a code review and testing on one of our websites I have found that the feature you are requesting already exists. The notice is dismissable for 30 days. If this is not what you are experiencing please review your javascript console to see if there are any related errors that may be contributing to this issue. You might also try disabling plugins to locate a plugin conflict. Please let me know if I can assist further.

    Thread Starter KZeni

    (@kzeni)

    Ah, the code indenting threw me off & I missed that part above the code I looked at.

    That said, it’s still showing on my site even after dismissing.

    What’s interesting is that https://www.website.com/wp-admin/index.php is showing the notice even though the database has eae_dismissed_notice-htmlvalidation-30 set to 1 for my user with it still being shown.

    Dismissing the notice does send an AJAX request

    
    MIME Type: application/x-www-form-urlencoded; charset=UTF-8
    notice: notice-htmlvalidation-30
    action: eae_dismiss_notice
    

    with it returning a 200 OK response.

    I have W3 Total Cache being used with Redis for database & object caching (among other optimizations) on PHP 7.2.x (currently) so I’m wondering if its related to that.

    However, I’m curious where eae_dismiss_notice is coming from as that’s being added into the dismissal info in the database & might be conflicting with it checking for a match.

    Thread Starter KZeni

    (@kzeni)

    Okay, it turns out that deactivating Email Address Encoder (https://wordpress.org/plugins/email-address-encoder/) has it working.

    Having EAE disabled also changed the AJAX request when dismissing this notice to contain

    
    MIME Type: application/x-www-form-urlencoded; charset=UTF-8
    action: dismiss_admin_notice
    option_name: notice-htmlvalidation
    dismissible_length: 30
    nonce: 540cb2b7bb
    

    So it seems EAE is somehow hijacking/conflicting with this setup.

    That said, EAE is a very useful & widely used plugin so addressing this conflict is probably worthwhile.

    Thread Starter KZeni

    (@kzeni)

    It largely seems due to EAE having:

    
    wp_enqueue_script(
        'dismissible-notices',
        plugins_url( 'dismiss-notice.js', __FILE__ ),
        array( 'jquery' )
    );
    

    while this plugin is using:

    
    wp_enqueue_script(
    	'dismissible-notices',
    	plugins_url( 'dismiss-notice.js', __FILE__ ),
    	array( 'jquery', 'common' ),
    	false,
    	true
    );
    

    The fact these are enqueueing their dismissal scripts with the same name has it so only one is loaded (with EAE then having higher priority so the dismissal script for this plugin isn’t loaded at all.)

    While changing the name of the script being loaded to something like wp_ada_compliance_basic_dismissible-notices has both scripts be loaded, it appears EAE is still hijacking the dismissal AJAX request & still has the notice shown after dismissal. So something more needs to be done to truly fix the conflict.

    Thread Starter KZeni

    (@kzeni)

    I’ve posted this at https://wordpress.org/support/topic/plugin-conflict-notice-dismissal-hijacking-notice-dismissal-of-other-plugins/ just in case there’s something to be done on EAE’s end of things.

    That said, this really is using naming & some selectors that are very generic & open to having conflicts (potentially with other plugins now & in the future) that should ideally be addressed either way. So there’s likely something to be updated for both plugins involved in this conflict.

    Is there a way to mark this as not resolved? It seems that was done even though the issue is very real & needs things updated, and it just needed some additional investigation to identify the cause of the problem.

    Plugin Author seshelby

    (@seshelby)

    Thanks for the additional information. I will get the generic naming issue taken care of. Hopefully the other plugin owner will address the hijacking issue as that isn’t something that I can resolve on my end.

Viewing 6 replies - 1 through 6 (of 6 total)
  • You must be logged in to reply to this topic.