Before uploading a WordPress plugin ZIP: verify the source, edition and update route

Describe the capability before choosing a file

Write one required outcome: for example, a fictional museum needs editors to create an accessible event list. Record whether WordPress or the current site already provides that capability. A downloaded archive should answer a defined need rather than create a reason to install something.

Then identify the intended product and edition. A free base plugin, a paid edition and a specialist add-on can have similar names but different requirements. Confirm whether an add-on needs another plugin or external service. Do not infer that from a filename such as events-pro-final.zip.

Learn WordPress’s plugin-selection lesson suggests reviewing developer, update, compatibility and support information. Use those as questions for investigation. A large download count, recent release or positive rating does not establish that a particular archive is the correct package.

Find the publisher independently

Start from a publisher route you can verify independently: its known website, the intended WordPress.org directory entry or the legitimate account where the purchase is recorded. A forwarded download message is not enough if you have not established where it leads.

Check the exact domain and product page. A lookalike name, sponsored result or company logo on an unrelated site does not settle ownership. If the website’s download goes through another host, confirm that route in the publisher’s own documentation or support information rather than treating every redirect as either legitimate or malicious.

The WordPress hardening handbook recommends trusted software sources as part of reducing risk. This is ongoing maintenance advice, not a guarantee that any directory or publisher can never have a compromised release.

Resolve unexpected download contents

If an account offers several downloads, establish which one is the actual installable plugin package. A documentation bundle, an add-on and a previous release can require different decisions. Ask the publisher to identify the intended archive instead of renaming files or rebuilding its folder structure until WordPress accepts it.

Likewise, explain a version discrepancy before proceeding. A known account may legitimately offer an earlier release, but that does not answer whether it is the edition and release your maintenance plan requires. Record the explanation and the supported next step.

Keep a small private provenance record

Record the product name, edition, publisher, version, date acquired and verified acquisition route. Note who owns the account or custom-code relationship and where the current installation/update instructions live. Keep the original archive unchanged in protected working storage until the evaluation is resolved.

Do not copy passwords, licence keys, signed download URLs or private customer details into a shared checklist. A useful entry can say “downloaded from the organization’s verified publisher account” and identify the responsible role. The secret-bearing receipt or account remains in its approved private location.

For the museum example, the record distinguishes the free event plugin from its paid recurring-event add-on. This prevents a later maintainer from replacing one with the other merely because both display the same company name. It also exposes whether future updates depend on an account nobody can access.

Understand what a checksum can establish

A checksum comparison needs a trusted reference for the exact intended file or release. A digest published beside an unknown ZIP on the same unknown page does not independently establish publisher identity. Matching it shows agreement with that reference, not that the reference deserved your trust.

The WP-CLI plugin checksum command checks installed WordPress.org plugin files against available WordPress.org checksums. Its scope does not extend automatically to a publisher’s paid edition or private custom archive. A difference requires investigation; a match is not a general malware or compatibility certificate.

Do not install an untrusted archive on the public site merely to make that command available. Ask the maintainer what verification route exists for the acquired package before installation. Do not disable secure transport checks or substitute a random online scanner for a source decision.

Separate acquisition, installation and activation

WordPress’s plugin-management documentation describes directory installation and uploading ZIP packages, with activation as a separate step. A successful upload or installation proves neither safe provenance nor correct behavior. Keep the acquisition decision before those operational steps.

Do not use the live Plugins screen as a place to inspect a suspicious file. Installing code into the environment is already a consequential action, even when activation is a separate control. If provenance remains unresolved, stop and obtain a fresh package through the confirmed original route.

If an archive was already added accidentally, tell the responsible maintainer what happened and preserve a private incident record. Avoid improvising a mass deletion or assuming that deactivation alone resolves every possible effect. The response depends on the actual installation and evidence.

Rehearse only after the source decision

For an approved package, plan a controlled evaluation with recovery and no live secrets, customer messages or payment activity. Define the needed capability and the pages, content and dependencies that could change. Use our WordPress change rehearsal for those operational checks.

A disposable demonstration can help with editor behavior, but it does not reproduce every server integration or prove security. Our Playground persistence guide explains how to preserve a rehearsal without confusing it with the live installation.

Agree the update route before accepting the package

Ask how future releases arrive, who reviews them and what happens when account access or support expires. Do not assume that a paid licence ending either disables the installed software or leaves update access unchanged. Confirm the actual publisher’s arrangement and record its practical consequence.

Finish with a clear decision: acquire the verified original, investigate a specific discrepancy, or defer the capability. Keep the evidence and responsible owner. The goal is an explainable software supply route that a future maintainer can continue, not a reassuring filename followed by an irreversible experiment.