Medifence – Access Control for Media Uploads

add_filter( 'medifence_allow_access', function ( $allowed, $file_path ) {
    // Example: always allow files inside uploads/public/.
    if ( false !== strpos( $file_path, '/uploads/public/' ) ) {
        return true;
    }
    return $allowed;
}, 10, 2 );

Changelog

1.53.1

• The screenshots on this page were taken again: the screens they showed date from 1.17.0, before the audit, the scheduled checks, the change history, and most of the share link options existed. Six screens now, in place of four. No change to the plugin itself.

1.53.0

• The list of active share links can now be downloaded as CSV: file, attachment, issue and expiry dates, download counts, whether a password is set, and the note — the ledger a compliance process asks for.
• The links themselves are deliberately not in the file. A ledger gets attached to emails and dropped into shared folders; leaking it must not leak access.
• Times are machine-readable UTC, matching the access log export.

1.52.0

• A freshly issued share link can now be sent by email straight from the result box: recipient, an optional line, one press. The message carries the link, the file name, and the expiry.
• Copy-and-paste into a mail client is where links get truncated and addressed to the wrong person; sending from here removes the paste. Each press sends exactly one message — nothing is automatic.
• Nothing about the recipient is stored. Only a link whose record is still active can be sent, and only links of this site — the form cannot be turned into a relay for arbitrary URLs.

1.51.0

• The lifetime and download limit that the share forms start with can now be chosen under “Share link defaults” on the settings tab. A site that issues many links the same way stops re-selecting the same values every time.
• Only the preselection changes: every link can still be issued with different values, links already issued are untouched, and WP-CLI keeps its own defaults so scripts stay reproducible.

1.50.0

• A dashboard widget now shows the protection’s vital signs on the admin home: whether the rules are in place, the last live test, how many files anyone can open, the active share links, and whether the scheduled checks run.
• The status tab and Site Health answer when someone goes looking; the dashboard is what gets seen without looking. Administrators only.
• The widget reads stored values exclusively — rendering it never scans the library and never makes an HTTP request.

1.49.0

• The daily count now remembers which files it saw, so the files that became reachable since the previous count are named — on the Audit tab and in the increase email — instead of leaving an administrator to find them by hand.
• Stored as hashes with a hard cap; when the library outgrows what the daily count examines, the comparison says so rather than quietly claiming completeness.
• The first count only records the baseline. Nothing is reported until there are two counts to compare.

1.48.0

• The daily count of reachable media files now runs with the daily check regardless of the email notification, and the last 30 days are kept as a trend on the status tab.
• A single day’s comparison catches a jump; only a trend catches the quiet drift of a scope widening over weeks. Days the check did not run are shown as absent, not as zero — an uncounted day is unknown, not empty.
• The increase email itself still requires the notification switch, exactly as before.

1.47.0

• Repairs of the rule block are now counted, and two or more within a week are called out on the status tab and in Site Health as a standing conflict with another plugin.
• One overwrite is an accident the automatic repair already handles. A repeated one means something on the site keeps writing over the rules — and a conflict that gets silently repaired forever is a conflict nobody ever fixes.
• The warning points at the kept snapshot of what the other plugin wrote, which is the clue to which one it is. Reading the verdict costs nothing: it is judged from stored timestamps, never by scanning.

1.46.0

• New: the MEDIFENCE_LOCK_SETTINGS constant in wp-config.php freezes everything that moves the protection scope — saving, previewing, importing, undoing from the history, and per-file exceptions, in the admin and over WP-CLI alike.
• Diagnosis, audits, the access log, share links, and the pause stay available: the lock freezes the scope, not the operations. The settings tab says plainly that it is locked.
• This is the written-down form of an agreement, not a security layer — whoever can edit wp-config.php can remove the constant. For handed-over sites and teams where the protection is not changed casually.

1.45.0

• Site Health now carries two more Medifence tests: a recommendation when document or archive extensions are excluded from the protection, and the last daily count of reachable media files.
• Both read stored values only — opening Site Health never triggers a scan or an HTTP request.
• The exclusion warning matches the one on the settings screen; the count is information rather than a verdict, with a link to the audit that lists each file.

1.44.0

• wp medifence status --format=json and wp medifence inspect --format=json print the full report as one JSON object, for deployment scripts and CI that so far had to parse the human-readable table.
• The exit codes are unchanged — a pipeline that only asks “is the protection working” keeps its one-line answer, and one that wants the details no longer greps for them.
• audit and stray already offered machine-readable listings; their output is untouched.

1.43.0

• WebP and AVIF copies placed beside the originals by an image optimizer (foo.jpg.webp, foo-300×200.webp) are now resolved back to the file they were made from. Optimizers record these copies nowhere, so until now every attachment-based decision saw them as unknown files.
• They follow their source everywhere: the derivative of a published image size is public, the derivative of the protected original stays protected, and the “follow the parent post” mode treats them as the post’s own image.
• A replaced-extension derivative whose source is ambiguous — foo.jpg and foo.png existing as different attachments — stays unresolved on purpose, and unresolved falls to the protected side.

1.42.0

• Repairing the rules — automatically or with the rewrite button — now keeps what stood in the rule block beforehand. Repairing used to destroy the evidence: whatever another plugin wrote over the rules was gone the moment they were restored, and with it the only clue to who keeps overwriting them.
• The settings tab shows the kept content next to the last-repair line, or says plainly that the rules were removed rather than overwritten.
• One generation is kept, and only the marker block — the rest of the file is other plugins’ business.

1.41.0

• A recorded settings change can now be undone with one click from the history: the previous values of that entry are restored, the rules are rewritten, and the undo itself appears in the history.
• Recovering from a wrong save used to mean reading the old values out of the history and typing them back in. Now it is the button next to the entry.
• Only the settings that entry changed are touched, and everything runs through the normal save path — nothing downstream is skipped. Entries recorded by versions before this one are shown but cannot be undone, because the exact previous values were not stored yet.

1.40.0

• The audit now lists the attachments whose file is missing on disk — deleted over FTP, or lost in a migration — with the recorded path, a link to the attachment, and the upload date. The count existed before; which files it meant did not.
• The uploads scan finds files without an attachment; this is the reverse: attachments without a file. Kept separate from the reachable-files list, because a missing file is an integrity problem, not an access problem.
• Requests for such files are answered with 404 either way; the point is to repair or retire them before someone issues a share link that cannot work.

1.39.0

• The status tab and Site Health now report when the scheduled checks are overdue. The automatic repair, the alert emails, and the weekly summary all ride on WP-Cron — and on a site with almost no visits, or with DISABLE_WP_CRON set but no server cron job, all of it stops silently while the protection itself keeps working.
• An event more than a day past due is the direct evidence, so the verdict needs no extra bookkeeping and is judged when an admin screen asks — a cron cannot report its own absence.
• The status tab also shows when the daily check last actually ran.

1.38.0

• New shortcode: [medifence_files path="members/gold"] lists the files of that uploads folder — but only the ones the visitor viewing the page could actually download, decided by the same rules as the delivery itself.
• A member sees their documents, a visitor without access sees nothing, and the list can never disagree with what the protection would serve — which a hand-maintained list always eventually does.
• The output is one unstyled list with class names, for the theme to style. The plugin sets DONOTCACHEPAGE on pages using it; make sure your caching plugin honours that.

1.37.0

• The Audit tab can now scan published content and list the protected files it links to — the opposite question from the other scans: not “what can anyone open” but “what did we embed that visitors cannot open”.
• A protected file inside a published post is the misconfiguration that shows up as a broken image or an inaccessible link on a public page, and until now nothing reported it.
• The verdict mirrors the delivery path exactly: published image sizes, per-file exceptions, and the content-aware mode’s published-parent rule are all honoured, so every finding is one an anonymous visitor really cannot open.

1.36.0

• Excluding a document or archive extension — pdf, zip, doc, docx, xls, xlsx, ppt, pptx, csv, rar, 7z, gz, tar — is now flagged: a warning appears under the exclusion field, in the preview of an unsaved change, and in the message after saving.
• These are the files a protected uploads directory usually exists for, and an excluded extension covers every file of that type, including future uploads. The warning does not block anything — excluding them is sometimes right; doing it unnoticed never is.

1.35.0

• The file dialog — the one that opens when media is inserted into a post — now shows whether the file is protected or public, with the deciding rule underneath. A protected file is recognised before it lands in a public page.
• The media REST endpoint gains a matching read-only medifence field with the verdict, the reason, and a description. It is returned to administrators only; everyone else receives null — which files are reachable is itself information.
• No JavaScript was added: the dialog field rides on WordPress’s own attachment details, so it works in the block editor’s media dialog and the classic one alike.

1.34.0

• How many files the access log keeps (50–500) and for how long (7–90 days) can now be chosen, next to the log switch. The defaults are unchanged: 200 files, 30 days.
• The log tab now shows the last 7 days as one count per day, in the site’s timezone, so a surge of blocked requests stands out without reading the list.
• The weekly summary names the configured limits instead of the old fixed ones.

1.33.0

• A weekly summary email can now be switched on: one message a week with the number of files anyone can open, what the access log counted, the active share links, and any changes to the protection settings.
• The existing alert only speaks when something changes; the summary confirms the quiet weeks too, and goes to the same notification address.
• “Send the weekly summary now” on the settings tab shows what it will look like without waiting a week.

1.32.0

• A share link can now carry a password, as a second factor against the link being forwarded or leaking: whoever opens it is asked for the password before the file is served.
• A correct answer is remembered in a signed cookie for an hour — at most until the link itself expires — so a video keeps seeking and a gallery keeps loading without asking again.
• Only a hash of the password is stored. After 20 wrong attempts the link stops accepting passwords for good; the issuer can always create a new link.
• The password is optional and set when the link is created — on the Share links tab, in the bulk action, or with wp medifence share --password=....

1.31.0

• Deleting a file from the media library now also revokes its share links. They stopped working anyway once the file was gone, but their records stayed in the list until they expired, and a list that shows links nobody can use is not telling the truth.

1.30.0

• Generated image sizes can now be published while the original file stays protected — for a photo site where the gallery is open to everyone and the full resolution is not.
• Tick the sizes anyone may see under “Image sizes anyone may see” on the settings tab. The original and the -scaled copy of a large upload are never among them.
• Which size a file is comes from what WordPress recorded when it generated it, not from the numbers in the file name, so a size that does not crop cannot leak through a coincidental match.
• This only widens access inside the protected scope: an excluded extension or folder is still decided first, and a per-file exception still overrides everything.
• Fixed: generated sizes of an image large enough to have been scaled on upload did not resolve back to their attachment, so the “follow the parent post” mode treated them as belonging to no post.

1.29.0

• The audit is no longer limited to the newest 1000 attachments: it examines a batch at a time and offers to continue, so a library of any size can be covered from the admin screen.
• It reports how far it has come and says plainly when the whole library has been examined — the oldest files are reached last, and those are the ones nobody remembers.
• Batches are paged by attachment ID rather than by offset, so files added or deleted while the scan runs cannot make it skip or repeat any.
• wp medifence audit now covers the whole library by default; pass --limit to stop early.

1.28.0

• Individual folders can now require their own capability, so a site with several membership tiers can keep each tier’s files closed to the others.
• The most specific folder decides: a rule on members/gold is applied ahead of one on members.
• Folder rules only narrow access — they never admit someone who failed the site-wide capability — and share links keep working for the file they were issued for.
• The settings screen reports which roles have each capability, and the file inspector names the rule a given file falls under.

1.27.0

• The audit’s list of files anyone can open is now actionable: select files and set them to “always protected” without leaving the list.
• The library is scanned again immediately afterwards, so what remains on screen is what is still reachable rather than what was reachable before.
• Files your web server delivers without ever asking the plugin — an excluded extension, an excluded folder, or a scope limited to other paths — are named separately, because storing an exception for those changes nothing, and saying otherwise would claim a protection that is not there.

1.26.0

• Share links can now be created for several files at once: select them in the media library and use the new bulk action.
• The lifetime, the download limit, and the note are asked once and applied to every link, and the links are shown together for copying into a single message.
• Each link still covers its own file alone, and the download limit applies per link. Up to 25 files per request.
• Files whose file is missing on disk are named rather than quietly left out of the set.

1.25.0

• The daily check now counts how many files anyone can open, and emails you when that number grows.
• This catches what the live test cannot: a widened scope leaves the rules working perfectly, so the existing verdict stays green while more files sit outside the protection.
• A falling number is never reported, and the first count is only a baseline, so switching the notification on does not produce a message.
• The message names a few of the files and links to the Audit tab. The count examines the newest 500 attachments; the new medifence_exposure_limit filter changes that.

1.24.0

• The Audit tab can now scan the uploads directory itself, not only the media library, and report the files no attachment points at that anyone can open.
• These are the files nothing else mentions — exports another plugin left behind, leftovers from a migration, anything copied in over FTP — because every other view starts from the library.
• Generated sizes, the scaled copy of a large upload, and edited versions are resolved back to their original, so they are not mistaken for strays.
• Also available as wp medifence stray, which covers the whole directory and can write the list to CSV.

1.23.0

• The settings that decide access now keep a change history: what moved, from what to what, when, and which administrator did it.
• Covers every route into the settings — the form, an imported file, and WP-CLI — because the record is taken where the settings are written.
• Settings that move no file, such as the log switch or the notification address, are left out so the list stays readable.
• The last 50 changes are kept and can be cleared at any time. Also available as wp medifence history, with --clear.

1.22.0

• Denied visitors can now be sent to a page of your own instead of the login screen — a membership or contact page, which reads better to someone who has no account yet.
• The file they asked for is passed to that page as mf_from, so the page can name what was behind the door.
• If the chosen page is unpublished or trashed later, denied visitors fall back to the status code instead of being sent into a 404.
• The access log counts this separately from the login redirect.

1.21.0

• The settings can now be downloaded as a JSON file and read back in on another site, so a configuration worked out on staging does not have to be repeated by hand.
• Only the settings are exported. Share links, the signing key, the access log, and per-file exceptions belong to one site and are never included.
• An imported file is treated as an unsaved change and its effect on the receiving library is reported first, so a scope from another site cannot quietly expose files.
• Every imported value goes through the same sanitizer as the settings form, so a hand-edited file cannot introduce a setting the screen would reject.
• Also available as wp medifence export and wp medifence import <file>, with --dry-run.

1.20.0

• A settings change can now be previewed before it is saved: “Preview the effect” applies the values in the form to your library without storing them, and lists the files that would change side.
• Files that would stop being protected are reported first — until now the only way to notice was to save, audit, and find out afterwards.
• The edits stay in the form after a preview, so they can be saved or discarded once the effect is clear.

1.19.1

• The Help tab now covers the access log and its CSV download, which had no entry there at all.
• The developer reference lists the paused value of the X-Medifence header and the pause and resume commands, both introduced in 1.18.0.
• Documentation only. Nothing changes in how files are protected.

1.19.0

• The access log can now be downloaded as CSV from the Access log tab — one row per file, with one column per event and machine-readable UTC times.
• Handy for a spreadsheet, or for keeping a record before clearing the log. Until now the CSV was only available on the command line.

1.18.0

• The protection can now be paused for 5, 15, or 60 minutes: every file is served as if the plugin were inactive, and the protection always resumes by itself.
• Deactivating the plugin used to be the only way to rule it out while diagnosing a broken page; a pause does the same without touching the rules — and cannot be forgotten.
• While paused, a warning shows on every admin screen and in Site Health, served files carry an X-Medifence: paused header, and the email notification does not report the pause as a failure.
• Also available as wp medifence pause --minutes=15 and wp medifence resume.

1.17.0

• The protection scope can now be filled in by picking an existing folder from the uploads directory, instead of typing the path.
• Configured paths that do not exist are pointed out — a typo used to look exactly like a working setting.
• The capability field suggests the common ones and reports which roles actually have the capability you entered, or warns when no role has it.

1.16.0

• The daily check can now email you when the protection stops working, and again when it works again.
• The message is sent only when the verdict changes, so a site that stays broken does not send one every day.
• A live test that could not reach your site at all is never reported as a failure.
• The address can be set separately from the site administrator’s, and a test email can be sent from the settings screen.

1.15.0

• A single file can now be an exception to the protection scope: always public, or always protected.
• Set it for several files at once with the new bulk actions in the media library, or on a file’s own edit screen.
• Generated image sizes follow their original, and the exceptions are listed on the Audit tab where each can be reset.
• The file inspector reports when “always protected” cannot take effect because an excluded extension or folder keeps the file away from Medifence.
• Also available as wp medifence override <id> --set=public|protected|default.

1.14.0

• Added an optional access log: it counts, per file, what Medifence did — blocked a request, served the placeholder, sent someone to the login screen, or accepted a share link.
• Off by default. Nothing identifying is stored: no IP addresses, no user agents, no user names — only the file, what happened, and when.
• The 200 most recently seen files are kept, for 30 days, and the log can be cleared at any time.
• Also available as wp medifence log, with --clear.

1.13.0

• Added an Audit tab: one click applies the current settings to the whole media library and lists every file a logged-out visitor can open, with the reason for each.
• The result also counts the files that are protected and the attachments whose file is missing on disk.
• Also available as wp medifence audit, which covers the entire library and can write the list to CSV.

1.12.0

• A share link can now be limited to a number of downloads. Once it has been used that often it stops working, even if it has not expired yet.
• Each link can carry a short note, so it is clear later who it was issued to.
• The list of active links shows how often each one was downloaded and when it was last used.
• Reloading a cached file and seeking inside a video are not counted as downloads.
• wp medifence share accepts --uses and --label.

1.11.0

• Files are now picked from the media library instead of typing an attachment ID by hand — both for the placeholder image and when creating a share link.
• The chosen file’s name is shown next to the field, so it is clear what a stored ID refers to.

1.10.0

• Added an Access column to the media library, showing whether each file is protected or public. Hovering a badge explains which setting decided it.

1.9.0

• Added a file inspector: paste a URL, an attachment ID, or a path, and see whether a logged-out visitor can reach that file — and which setting decided it.
• The verdict names the exact rule responsible (the excluded extension, the excluded path, the parent post, and so on), so a misconfigured scope is easy to spot.
• Also available as wp medifence inspect <file>.

1.8.0

• Reorganised the settings screen into tabs — Protection status, Settings, Share links, Rules, and a new Help tab — so each part is easier to find.
• Added a status bar that states at a glance whether the protection is active.
• Introduced a stylesheet matching the look of our other plugins. It is loaded only on this screen.

1.7.0

• The settings screen now lists every active share link, with the file it points at and when it expires.
• Any single link can be revoked without affecting the others; expired entries drop off the list on their own.
• Links issued before this version stop working. A link is now valid only while its record exists, which is what makes individual revocation possible.

1.6.0

• Denied requests can now send the visitor to the login screen and back to the file afterwards, instead of returning a status code.
• The redirect only happens for top-level navigation, so images and videos embedded in a page are never replaced by a login page.

1.5.0

• Added a third protection scope: each file follows the post it is attached to. Files on published posts are served to everyone, files on private, draft, or password-protected posts require a login, and files attached to no post stay protected.
• Generated image sizes follow their original attachment, so a thumbnail is never more public than the full image.

1.4.0

• Moved the settings screen from Settings to Media → Access Control, next to the library it protects. The screen itself is unchanged; bookmarks pointing at the old location need updating.

1.3.1

• Added a Japanese translation covering the whole admin interface, the Site Health report, and the plugin description.

1.3.0

• Added a daily scheduled check that rewrites the rules when they are missing or outdated (can be turned off).
• Added a Site Health test reporting whether uploaded media files are actually protected.
• Added WP-CLI commands: wp medifence status, rewrite, remove, verify, and share.

1.2.0

• Added expiring share links: grant access to one protected file without an account, for 1 hour up to 30 days.
• A share link is the file’s normal URL plus a signature, so it cannot be reused for any other file or kept alive past its expiry.
• Added a “Share link” action to the media library rows, and a “Revoke all share links” button that replaces the signing key.

1.1.0

• Added a protection scope setting: protect everything except the folders you exclude, or protect only the folders you list.
• Excluded folders are served directly by the web server, without loading PHP.
• The same scope is now also evaluated in PHP, so behaviour stays consistent when the .htaccess rules are outdated.

1.0.0

• Initial release.