Why does Extension Manager now require 3 separate plugins?

  • Resolved newharvest

    (@newharvest)


    4 months ago

    Previously, installing Extension Manager was very straightforward, like any other plugin:

    1. Download plugin zip file
    2. Upload to WP and activate it
    3. Activate the extensions you need (Transport mostly in our cases)
    4. Use Transport
    5. Deactivate/delete EM later if no longer needed

    Now, there are three separate plugins involved and it’s really a pain.

    1. Download plugin zip file
    2. Upload to WP and activate it
    3. The file you uploaded is not actually EM itself but an “Installer” plugin ???
    4. It installs the “real” EM plugin and “Troy Client”
    5. It deactivates the installer plugin
    6. Delete the installer plugin manually
    7. Use Transport
    8. Deactivate/delete EM later if no longer needed
    9. Can’t delete Troy Client because TSF “needs” it even though it didn’t before you installed EM
    10. Deactivate TSF to see if you can remove Troy Client then
    11. Still can’t remove Troy Client
    12. Delete TSF
    13. Deactivate/delete Troy Client
    14. Reinstall/activate TSF again without Troy Client this time

    Given that every WP plugin comes with some amount of performance cost, personally I don’t really appreciate plugin developers automatically installing multiple plugins for me, and making it difficult to remove those plugins. Even if this particular plugin is well written, I don’t really have anyway of knowing that beforehand. I also don’t understand why an intermediary “installer” plugin is needed when no other WP plugin behaves in this way.

    Additionally, it is not clear from the plugin description what actual benefit Troy Client is providing me. “Troy Client enables updating your WordPress plugins and themes from decentralized Troy Server repositories.”

    1. What is Troy Server in the first place? I have never heard the name “Troy” in reference to TSF before today.
    2. Why are Troy Server repositories preferred over default WP behaviour?

    I checked https://theseoframework.com/ and there is only one tiny link to “Deploy Troy” in the footer.

    Having now looked into what Troy is, it seems innocuous, maybe even good — but now I have another question.

    We run other third-party plugins that push updates directly from their own servers (Beaver Builder being one). Many “Pro” plugins do this. Why is a separate plugin required to do this for TSF when this behaviour could be built-in?

Viewing 1 replies (of 1 total)
  • Plugin Author Sybre Waaijer

    (@cybr)

    3 months, 3 weeks ago

    Thank you for the detailed feedback — you raise valid concerns.

    The Installer bundles The SEO Framework, Extension Manager, and Troy Client into one package to simplify onboarding. It’s intentionally disposable — once it finishes, you can safely delete it. I’m considering enabling automated deletion after installation to avoid this confusion.

    You’re right to question why Troy Client exists as a separate plugin. Many plugins (like Beaver Builder Pro) include update logic directly in the main plugin. This works, but it’s fragile: if the plugin breaks or gets deactivated, updates stop flowing. The plugin can’t update itself if it can’t run. Troy Client solves this by being a separate, robust, and lightweight plugin whose sole job is to deliver updates. If Extension Manager has an issue, Troy Client can still fetch and install a fix. Your update pipeline won’t depend on the plugin it’s updating.

    The removal protection exists because Troy Client knows which plugins depend on it. Without it, those plugins would lose their update source with no way to receive fixes. You figured out how to remove it — that friction is intentional, to prevent accidentally stranding plugins. Performance-wise, the impact is negligible (around 0.29ms, a typical WordPress site takes 1500x that time to load), and the hooks only fire when WordPress checks for updates, not on every page load. Better yet, because Troy Client handles updates for all Troy-enabled plugins, those plugins don’t need their own update logic — if just two plugins use Troy instead of bundling their own updaters, the performance wins are immediate. You’re familiar with how fast The SEO Framework is already; Troy is the culmination of 10 years of performance optimization experience.

    I just created a KB article explaining this in more detail: https://tsf.fyi/kb/what-is-troy-client

    I understand the friction of an extra plugin. But Troy Client is small, fast, and ensures you’ll always get updates — even if something goes wrong with dependent plugins. That’s the tradeoff: one extra plugin for a more resilient update system.

Viewing 1 replies (of 1 total)

You must be logged in to reply to this topic.