Rebuilding a WordPress plugin to directory standards

A SaaS provider’s plugin was running on its customers’ live sites but no longer met WordPress.org plugin directory standards. We replaced the bundled framework and fixed the cross-site scripting issues, keeping existing shortcodes and settings working.

~95,000 lines of framework code replaced
Standards violations ~3,728 → 29
53 automated tests

Services: Enterprise Web Platforms · Cloud, DevOps & Security

The challenge

A SaaS provider’s WordPress plugin, used on its customers’ live sites, had grown around a large bundled framework. It carried cross-site scripting issues and thousands of coding-standards violations, and it no longer met WordPress.org plugin directory standards.

Any rebuild had to keep working on every customer site that already depended on it.

What we did

Replaced ~95,000 lines of bundled framework code with the WordPress Settings API.
Fixed cross-site scripting issues by escaping output and validating input across every shortcode.
Cut coding-standards violations from ~3,728 to 29 against the WordPress Coding Standards.
Added 53 automated tests.
Prepared the plugin for directory review: unique prefixes, disclosure of the external services it calls, and current compatibility headers.

Key decisions

Replace, don’t patch. Removing the framework shrank the attack surface and made the code reviewable, instead of fixing issues one by one inside it.
Backward compatibility first. Existing shortcodes and settings kept working, so customers didn’t have to change anything on their sites.
Ask before guessing. Where shortcode behaviour wasn’t documented, the client confirmed the intended behaviour before anything changed.

What this delivered

The rebuilt v2.0 plugin is prepared for WordPress.org directory review, with its framework replaced, cross-site scripting issues fixed and standards violations down to 29. Existing shortcodes and settings kept working, so no live customer site broke.