Feature: Add compatibility layer and compatibility status output

[al-esc]

• closes Bug: Missing function namespace in reference #50
• bumps version to 1.5.0

---

Adds automated compatibility fixes & reports on compatibility status for the following plugins:

• AMP for WP – Accelerated Mobile Pages
• Auth0
• Autoptimize
• Better Search Replace
• Broken Link Checker
• Contact Form 7
• Event Espresso
• Facebook for WordPress (official-facebook-pixel)
• Fast Velocity Minify
• Force Login
• PolyLang
• Redirection
• Revive Old Post
• Self-Updating Themes
• Slider Revolution
• WooZone
• WP Rocket
• YITH WooCommerce Extensions with MPDF Library

---

Reports on required manual plugin compatibility fixes:

• Big File Uploads
• Jetpack
• Wordfence
• WPML - The WordPress Multilingual Plugin

---

Reports on plugins with known compatibility issues that need review (are either incompatible or partially compatible):

• AdThrive Ads
• All-in-One WP Migration
• Bookly
• Coming Soon
• Disable REST API and Require JWT / OAuth Authentication
• Divi WordPress Theme & Visual Page Builder
• Elementor
• FacetWP
• GDPR Cookie Consent
• H5P
• HM Require Login
• Hummingbird
• HyperDB
• InfiniteWP
• Instashow
• Maintenance Mode
• ManageWP worker
• Monarch Social Sharing
• New Relic Reporting for WordPress
• Object Sync for Salesforce
• One Click Demo Import
• Posts 2 Posts
• Query Monitor
• Site24x7
• Smush Pro
• Solid Security (Previously: iThemes Security)
• Unbounce Landing Pages
• Unyson Theme Framework
• Updraft / Updraft Plus Backup
• Weather Station
• WebP Express
• WooCommerce
• WordPress Download Manager
• WP All Import / Export
• WP Migrate DB
• WP phpMyAdmin
• WP Reset
• WP-Ban
• WPFront Notification Bar
• Yoast Indexables
• Yoast SEO

---

Reports compatibility status in a new tab on the Site Health admin page (screenshot attached)

[guardrails]

⚠️ We detected 1 security issue in this pull request:

Insecure Access Control (1)

Severity	Details	Docs
Low	Title: Insecure HTTP redirect pantheon-mu-plugin/inc/compatibility/fixes/class-acceleratedmobilepagesfix.php Line 35 in 3e10ed4 header( 'Location: ' . $redirect_header_value );	📚

More info on how to fix Insecure Access Control in PHP.

---

👉 Go to the dashboard for detailed results.

📥 Happy? Share your feedback with us.

[al-esc]

@scottbuscemi compatibility layer PR here ^

[jazzsequence]

Thanks for the PR! I've left some comments. A couple thoughts before really digging in...

---

I use the 🔢 emoji throughout to indicate "this is a comment that applies elsewhere in the code". It should be pretty obvious in the context but I'm not saying "this only needs to be changed in this file", I'm saying "anywhere there is code that is like this, it should be fixed there, too".

I would expect any new major functionality added to the mu-plugin to add equivalent tests for that functionality. We have WPUnit tests running against the plugin and, with this big of a change, I would expect at least some tests. (Unfortunately, forks don't trigger the GitHub actions, but we can manually trigger them ad hoc if necessary, which I did for this PR.) While I don't think you necessarily need to test every compatibility and fix class, it is at least worth writing tests for the base class with example/test compatibility checks/fixes.

We don't fully support translations in the mu-plugin, but all of our code should be internationalized with the expectation that at some point in the future, we could. There are a lot of plain text strings here that are not i18nized or not using the correct textdomain. The current codebase isn't consistent with what that is, but any new code should use 'pantheon' as the textdomain.

Many functions lack docblocks. For future maintainability, I would expect those to exist at least in the base class(es) and factory class.

Everything else looks great. Happy to chat next week if necessary to go into any of the fine grain details.

[al-esc]

TYSM for the review @jazzsequence! The team is currently addressing your comments and will have an update ASAP. Thanks again! 🙌

[jazzsequence]

@al-esc Feel free to hit me up if y'all want to chat. I'm around on Slack. :)

[jazzsequence]

Looking good :)

A couple smaller changes requested, but this looks really close. The spacing issues are minor, and it's the inconsistency that I'm more concerned about. I know we're already inconsistent, and I don't want to add more inconsistency to the codebase.

[jazzsequence]

One last thought now that I'm actually testing it:

I like that we have our own separate tab. But I'm afraid it will get ignored too easily. It would be nice if manual fixes and things that "need review" also showed up in the main Site Health checks as recommendations with links to the Pantheon Compatibility tab for more information

[al-esc]

@jazzsequence main site health info tab should now also output compatibility layer tests.

FYI phpcs is outputting a warning on:(looks like this has been addressed by pantheon-systems/Pantheon-WP-Coding-Standards#6)

[jazzsequence]

Hey @al-esc
Just dropping a note here that I just got back from vacay this week, so I'll be jumping back into this hopefully today. I expect this will be a quick ✅ after I do some testing because I recall the last pass looked pretty much there.

[jazzsequence]

Some very weird linting regressions. Did we get our PHPCS wires crossed? Some regressions broke URL strings and others affected code that was there before the compatibility layer feature you wrote. Not sure what happened. I'm fixing as many as I can find.

[jazzsequence]

I guess I can't actually apply the suggestions in the PR. I will pull down and make the changes manually.

[jazzsequence]

Okay, I've opened a PR against your fork since I can't merge changes directly into this PR: crowdfavorite#3

This fixes the various linting regressions that are in this last round.

Additionally, although I'm happy that we're now showing up on the main site health tab, it looks like there is a regression with the plugin names (presumably related to pulling out the hard-coded plugin names in favor of something more dynamic) that are displayed in both the main site health tab and the Pantheon Compatibility tab

Indeed, it looks like across the board, Plugin names are either not displaying or displaying the wrong data:

If we could get these things cleaned up I think we'll be good to go.

[al-esc]

Hi @jazzsequence ! Apologies for the wait, this should hopefully solve plugin name retrieval. Let me know whenever you get a chance, please and thank you! 🙌

[jazzsequence]

This looks good so far. I'm going to pull this into my test site and take a peek but if that checks out we're good to go. A couple minor questions but nothing I'm going to block this on.

[jazzsequence]

Strange, the plugin nice name isn't showing up in the list, just the slugified versions.

I'm not complaining, this is a huge step forward for the plugin overall and I feel like this is a thing we could iterate on. I'll open a separate issue for it so we remember to come back to it later.

[jazzsequence]

[jazzsequence]

@al-esc I clicked approve but it looks like there's one minor linting issue

FILE: inc/site-health.php
--------------------------------------------------------------------------------
FOUND 1 ERROR AFFECTING 1 LINE
--------------------------------------------------------------------------------
 850 | ERROR | [x] Expected 1 space after "=>"; 2 found
     |       |     (WordPress.WhiteSpace.OperatorSpacing.SpacingAfter)
--------------------------------------------------------------------------------
PHPCBF CAN FIX THE 1 MARKED SNIFF VIOLATIONS AUTOMATICALLY
--------------------------------------------------------------------------------

[al-esc]

@jazzsequence thank you! I would definitely like to maybe spend a bit of time looking at this together, not quite sure what's going on there with the plugin names using the fallback values for you 🤔

[jazzsequence]

@al-esc I did some digging/testing. Looks like paths are failing when you construct $file because what's coming through is, e.g. "/app/web/app/plugins/fast-velocity-minify/fvm.php" instead of "/app/plugins/fast-velocity-minify/fvm.php" -- at least in my Bedrock-based install. I will look into why Bedrock is giving WP_PLUGIN_DIR a value of "/app/web/app/plugins".

[jazzsequence]

Oh wait, maybe it's actually because the plugins weren't active? I think there are a couple different things at work here.

Partially I think the names were wrong because the files didn't exist. And I think the files didn't exist because I had installed them in SFTP mode and then maybe didn't actually commit them to the repository -- meaning the checks ran, and cached in the database, but the plugins weren't actually there so when the plugin files were pulled for plugin information, there was nothing there.

I think this is probably an edge case but maybe something worth collaborating on in the future (specifically retaining check data if the plugin in question has been deactivated or uninstalled) but not worth pursuing at this time. I'm getting mostly correct plugin names now.