Ensure that the Ad Blocking Recovery is used consistently across the plugin code

[kuasha420]

Feature Description

For the most part, the feature behind the adBlockerDetection feature flag is referred as Ad Blocking Recovery in the UI and code- namely, the copy, components, API routes, and other variables and pieces of codes. However, in a few place, Ad Blocker Detection is used, namely the Ad Blocking Recovery related AdSense module settings.

Besides the instances with the feature flag ie. isAdBlockerDetectionEnabled, all other usage of the Ad Blocker Detection (or its variants adBlockerDetection and AdBlockerDetection) and Ad Blocker Recovery (or its variants adBlockerRecovery and AdBlockerRecovery) should be refactored to use the actual feature name.

---

Acceptance criteria

• AdBlockerRecovery or it's other case variations should be replaced with AdBlockingRecovery across the code base, including code, comments, copies and file names.
• AdBlockerDetection or it's other case variations should be replaced with AdBlockingRecovery across the code base, including code, comments, copies and file names.
  • The only exception here is usage of the adBlockerDetection feature flag and related variables. ie. isAdBlockerDetectionEnabled.

Implementation Brief

• Search for instances of the word AdBlockerRecovery and all it's case variations, and replace them with the correct string as described in the IB, keeping the case intact.
  • Non exhaustive list of the possible cases are:
    • AdBlockerRecovery
    • ad-blocker-recovery
    • adBlockerRecovery
    • ad_blocker_recovery
    • Ad Blocker Recovery
  • Also replace any offending file names.
• Search for instances of the word AdBlockerDetection and all it's case variations, and replace them with the correct string as described in the IB, keeping the case intact.
  • Non exhaustive list of the possible cases are:
    • AdBlockerDetection
    • ad-blocker-detection
    • adBlockerDetection
    • ad_blocker_detection
    • Ad Blocker Detection
  • Also replace any offending file names.
  • Remember to make the exception for the feature flag!

Test Coverage

• None needed, make sure all the existing tests pass.

QA Brief

• Except for the feature flag, or the change log, there should be no mention of AdBlockerRecovery and AdBlockerDetection or its case variants in the plugins' code base.
• Ensure that the Ad Blocking Recovery main widget appears when all the conditions are met as par Display Ad Blocking Recovery Notification in the dashboard when all the conditions are met #6953.
  • Ensure that it does not appear when Ad Blocking Recovery is already set up.

Changelog entry

• Fix bug that caused Ad Blocking Recovery widget to appear/hide under the wrong conditions.

[promise-dash]

Hey, I would like to resolve this issue.
Could you please assign me this?

[techanvil]

Hi @promise-dash, thanks for your interest here. This issue is scheduled to go through our usual development process, but if you create a PR we'll happily consider it. However please do bear in mind this issue should most likely be implemented after the other Ad Blocker Detection issues to ensure that all relevant code is updated.

[techanvil]

Hey @kuasha420, this IB is LGTM. However I notice that this issue doesn't have any dependencies, I think we should add some to ensure that it doesn't collide with or miss any new additions that use the outdated naming scheme.

We could either check through the remaining ABD issues for those which reference the old names and add those as dependencies, or, what I think would be safer would be to schedule this after all of the ABD issues are complete. Or a third option could be to proactively go and update any existing issues to clear up the names in their definitions. What do you think?

[bethanylang]

@techanvil @kuasha420 Totally up to you from an engineering perspective, but if we do decide we'd prefer to wait until ABD Is complete, I'd say that this would be something that we do post-launch – e.g. we finish engineering in Sprint 104, go through the whole Bug Bash/release process over the next several sprints, and then come back to this later in August after the initial release. Otherwise, pre-launch testing will be tricky because we'd still be making changes across the code for this feature.

If we don't want to wait that long, we'd want to get this done in Sprint 104 along with all of the other work on this feature. Let me know what you think!

[techanvil]

@bethanylang you raise a good point, however I would advocate for getting this done pre-bug bash, as otherwise a change like this which touches a lot of code would ideally require a regression test across the ABD feature anyway so it would be more efficient to get it in prior.

The thing is, as this is just essentially a load of search and replacing with no logical changes it should be pretty quick to implement, as such I'd suggest we should get it done immediately preceding the bug bash. Interested to hear @kuasha420's thoughts on this too.

[bethanylang]

@techanvil Yep, agreed that Sprint 104 would be the most efficient, but will leave it up to @kuasha420 to confirm!

[kuasha420]

Hi, we should definitely do this before launch, because it will change a few settings name. If we do it post launch, we'll need a Settings migration which is absolutely not desirable for such trivial change.

As for dependencies, we can get by without it I think, as getting this done and merged will probably create merge conflict or test failures in the in-flight PR which will get naturally resolved and the rest of the tickets will just use the new names and variables naturally (although some part of their IB will become less accurate). That way nothing will be held up.

Or we can make it dependant on 6962 and 6966, that way there will be less friction on other tickets but this one will likely not start until the very end of 104 or will likely get pushed over to 105. However as TOM said, the change here is not very high effort and can probably be done very quickly upon start.

TLDR: We should do it before launch and preferably before bug bash, but the when is totally up to you.

Cheers

[bethanylang]

Thanks @kuasha420, this is a really helpful explanation! I'm going to schedule this for Sprint 104 and add an Sp Wk 2 label to indicate that it should be done in week 2, but without dependencies. As you said, we should just be mindful that this will affect any ABD issues that are still in-flight at that time, which we can hopefully just do with a Slack message.

@kuasha420 Do you mind assigning this one to yourself once it gets to EB, since you're familiar with it? Then you can plan to work on it w/c 26 June. TY both!

[kuasha420]

@techanvil Now this is sorted, feel free to have a look over and assign this one to me in EB. Cheers!

[techanvil]

Thanks @kuasha420 & @bethanylang, SGTM! In that case, IB ✅ and I'll assign this to @kuasha420 in EB. 🎉

[wpdarren]

QA Update: ✅

Verified:

• Set up Ad Blocking Recovery and made sure all the screens referenced the correct terminology.
• Checked that the ABR CTA does not appear in the dashboard when set up.
• Made sure that the correct terminology was used on the AdSense settings
• Checked source code on the front end to make sure the code placement was commented with the correct terminology.

Screenshots

abr-2.mp4