Titanium Compatibility Control Tutorials

10 practical ways to manage plugin compatibility, updates and recovery with clear WordPress-native tools.

These step-by-step tutorials explain how to read compatibility information on the Plugins screen, understand Tested up to and repository states, use the detailed Plugin List, adjust the Unmaintained threshold, refresh metadata after external file changes, download the version currently installed, roll back an eligible WordPress.org plugin, read Update History and use Site Health or Multisite safely.

Get Free Version View Features

Compatibility metadata
Repository status
Rollback and Download
Update History

Step-by-step plugin compatibility and recovery tutorials.

Start with the compact information on the normal Plugins screen. Open the detailed Plugin List when you need repository status, latest-version metadata, Download or Rollback, then use History and Site Health to understand what changed and what deserves attention.

FreePlugins Screen

How to read WordPress and PHP compatibility directly on the Plugins screen

Titanium adds compact compatibility information beside each installed plugin so you can compare its declared requirements with the WordPress and PHP environment currently running on the site.

Read the compatibility row

Open Plugins in wp-admin or Network Admin on Multisite.
Find Requires WordPress for the minimum WordPress version declared by the plugin.
Read Tested up to for the WordPress version through which the plugin declares testing.
Read Requires PHP for the minimum PHP version declared by the plugin.
Use the colour as a quick signal, then read the actual version values before making a decision.
Use Download from the Plugins screen when you want a ZIP of the files currently installed.

What the colours tell you

Green means the declared range covers the compared environment.
Deep red highlights an unmet or outdated declaration.
Missing metadata is shown as unavailable instead of being guessed.
The values describe declared metadata, not a source-code scan.
A plugin can work even when its Tested up to declaration is old.

Important: Compatibility metadata helps prioritize testing. It is not a guarantee that two plugins work together or that a plugin has no runtime bug.

FreeVersion Check

How to interpret Tested up to without treating an old declaration as a broken plugin

Tested up to is an author declaration. Titanium compares that declaration with your WordPress version, but a red value means the declaration is behind the compared version — not that the plugin has been proven incompatible.

Choose the comparison style

Open Titanium Compatibility → Settings.
Find the Version Check comparison preference.
Use major/minor comparison when patch releases inside the same WordPress branch should count together.
Use exact comparison when the complete version number must match the tested declaration more strictly.
Save the setting and return to Plugins or Plugin List.
Use the result as a testing signal, especially before major WordPress changes.

Default behaviour example

Tested up to 7.0 remains valid through WordPress 7.0.x with major/minor comparison.
The same declaration becomes outdated when WordPress reaches 7.1.
Requires WordPress is a minimum requirement and is evaluated differently.
Requires PHP is also a minimum requirement.
Missing values remain unavailable rather than receiving invented compatibility.

Use case: A red Tested up to value is a good reason to check the plugin changelog, support history or a staging site. It is not enough evidence to uninstall a working plugin by itself.

FreePlugin List

How to use the detailed Plugin List for versions, repository dates and recovery tools

The dedicated Plugin List combines local installation data with reliable WordPress update and repository metadata so you do not need to open every plugin separately.

Review the table

Open Titanium Compatibility → Plugin List.
Compare Installed with Latest when reliable WordPress update metadata is available.
Review Requires WP, Tested up to and Requires PHP.
Check Last Repository Update for identified WordPress.org plugins.
Read the repository status instead of assuming every missing value means the same thing.
Use Download or Rollback from the Tools column when the plugin is eligible.

Why Latest can be unavailable

Titanium does not guess the latest version without reliable WordPress update metadata.
Private plugins can use their own update systems.
Repository identification may be unavailable or intentionally external.
Temporary API problems are not converted into false repository-removal results.
Manual Refresh can rebuild local compatibility data when files changed outside WordPress.

Practical tip: Use Plugin List as the deeper investigation screen; keep the normal Plugins page for fast daily checks.

FreeRepository Health

How to distinguish Removed, Unmaintained, Repository not detected and External / private

These states answer different questions. Titanium keeps them separate because “not found”, “old”, “unknown” and “privately updated” are not interchangeable.

Read each repository state

Use Unmaintained when Last Repository Update has reached your configured age threshold.
Use Removed from WordPress.org only when a previously identified repository plugin is reported as not found by the Plugins API.
Read Repository not detected as an identification uncertainty, not a removal verdict.
Read External / private when the plugin explicitly declares a non-WordPress.org update source.
Retry or refresh later when WordPress.org is temporarily unavailable.
Combine repository status with your own testing and maintenance requirements before taking action.

FreeSettings

How to choose when a WordPress.org plugin should be labelled Unmaintained

The age threshold is configurable because update cadence differs between plugins. A simple utility can be stable for a long time, while another plugin may normally publish updates much more often.

Change the threshold

Open Titanium Compatibility → Settings.
Find the Unmaintained threshold.
Choose a value between 1 and 3650 days.
Leave the default at 180 days when you do not need a custom maintenance policy.
Save the setting.
Review Plugin List and Site Health again with the new threshold in mind.

FreeManual Refresh

How to refresh compatibility data after replacing plugin files by FTP or File Manager

WordPress updater events can tell Titanium when a normal plugin change happened. External file replacement is different, so Manual Refresh gives you a direct way to rebuild the current local view.

Refresh after an external change

Finish the FTP, SSH or hosting File Manager replacement first.
Open the Titanium Compatibility plugin-management screen.
Run Manual Refresh.
Allow WordPress update metadata and local plugin compatibility data to rebuild.
Let repository metadata refresh separately in its small batches where needed.
Recheck Installed, Latest and the compatibility fields for the replaced plugin.

Scheduled refresh

A monthly refresh is scheduled automatically.
It is scheduled for the first day of each month at 4:00 a.m. site time.
WP-Cron must actually be triggered.
Sites using external cron must keep their WordPress cron runner configured.
Repository metadata refreshes separately from the local compatibility rebuild.

History limitation: Manual Refresh can rebuild the current state, but it cannot reconstruct a normal Update History event for an old FTP replacement that WordPress never observed.

FreeDownloadLocal Copy

How to download the exact plugin version currently installed on the site

Titanium creates the archive from the installed plugin files instead of downloading a fresh repository package. That makes Download useful before updates and for private or premium plugins whose exact installed package may not be available elsewhere.

Create the ZIP

Open Plugins or Titanium Compatibility → Plugin List.
Find the plugin whose installed files you want to preserve.
Choose Download.
Save the generated ZIP somewhere outside the live WordPress installation.
Confirm the filename and keep the archive with your update notes if it is part of a planned change.
Remember that database settings and site content are not part of this ZIP.

FreeRollbackBackup First

How to roll back an eligible WordPress.org plugin to an older official version

Rollback is deliberately limited to currently identified WordPress.org plugins in their normal repository folder. Titanium requests older official versions and installs the selected package through the WordPress Core upgrader.

Roll back step by step

Create a normal site backup and consider downloading the current installed plugin ZIP first.
Open Titanium Compatibility → Plugin List.
Choose Rollback for an eligible WordPress.org plugin.
Review the older versions loaded from WordPress.org.
Select the required older version and confirm the action.
After WordPress installs it in overwrite mode, test the site and check Titanium Update History.

Why Rollback can be unavailable

The plugin must currently be identified as available on WordPress.org.
It must be installed in its normal repository folder.
Only versions older than the currently installed version are offered.
The package URL must come from downloads.wordpress.org.
Private, custom, removed or unidentified plugins do not receive WordPress.org rollback versions.

Database warning: Rollback replaces files only. An older plugin version may interpret or migrate its own stored database data differently, so a normal backup remains important.

FreeUpdate History

How to see which plugin version changed, how it changed and when it happened

Update History records successful WordPress plugin updater events after Titanium is installed. It can help explain when a version changed and whether the change was manual, automatic or a Titanium rollback.

Read an event

Open Titanium Compatibility → History.
Find the plugin name and previous version.
Compare the previous and new version values.
Check whether the event was manual, automatic or a rollback.
Review the local WordPress user when one was available for a manual update.
Use the date to match the version change with any site issue or maintenance window.

FreeSite HealthMultisite

How to use Site Health checks and manage Compatibility Control on WordPress Multisite

Titanium adds compatibility and repository-maintenance checks to WordPress Site Health. On Multisite, plugin management is centralized at network level so the same installation is not managed independently from every subsite.

Use the diagnostic view

Open Tools → Site Health on a normal site and review the Titanium compatibility checks.
Investigate unmet declared compatibility separately from repository-maintenance warnings.
For Multisite, network activate Titanium Compatibility Control.
Manage the plugin from Network Admin.
Use network plugin-management permissions for Download and Rollback actions.
Keep the WordPress cron runner active so the main site can perform centralized scheduled repository refresh work.

Check first, keep a copy, then update with a recovery path.

Titanium Compatibility Control keeps declared compatibility, repository maintenance signals, installed-version downloads, official rollback and local update history together in one Free WordPress plugin.

Get Free Version

Want a clearer picture before the next plugin update?

Use Titanium Compatibility Control to review declared compatibility, repository status and update history, then keep the installed ZIP or use an official rollback when recovery is needed.

Get Titanium Compatibility Control