Changelog

Two settings on the FileDeck settings screen are marked as belonging to the AI tier. The marker was rendering as plain text run on to the setting's name, so "PDF watermarking AI tier" read as one long heading rather than a name and a badge.

Fixes & improvements

• The "AI tier" markers beside PDF watermarking and Retention schedules render as badges on the settings screen, instead of running on to the setting name.

The same fix as last release, applied to the other component it affected. A theme that defined its own chip or pill style could override the one FileDeck ships, and the active-filter chips above your library would take on its colours, shape and spacing instead.

Active-filter chips are no longer restyled by the surrounding theme

When you pick a category or tag, the filters you have applied appear as removable chips above the library. fdk-chip is a common class name, so a theme could define one without ever having heard of FileDeck — and because a theme's stylesheet loads after ours, its version won. The result was chips that looked like whatever pill the theme used elsewhere, sometimes without the affordance that shows they can be removed.

FileDeck's chip styling is now scoped to the library, so it holds regardless of the theme around it.

If you restyle the chips deliberately with your own CSS, prefix the selector with .filedeck — .filedeck .fdk-chip { … } — and it will apply as it did before.

Fixes & improvements

• Active-filter chips keep FileDeck's styling on themes that define a chip or pill style of their own.

A theme that defined its own card style could override the one FileDeck ships, and the document grid would take on padding, borders and hover effects it was never designed for. The library's own styling now wins.

Your theme can no longer restyle the document grid by accident

fdk-card is a common enough class name that a theme can define one without ever having heard of FileDeck. When that happened, the theme's rule loaded after ours and the grid layout inherited it — usually as extra padding, a heavier border, or a card that lifted on hover. The fix scopes FileDeck's card styling to the library itself, so it applies regardless of what the surrounding theme does.

If you restyle grid cards deliberately with your own CSS, prefix the selector with .filedeck — .filedeck .fdk-card { … } — and it will apply as it did before. Everything else about the grid, including the gallery layout and the style presets, is unchanged.

Fixes & improvements

• The document grid keeps FileDeck's card styling on themes that define a card style of their own.

Semantic search was too willing to find a match. Type something your library has no answer for and it would return most of the library anyway, ranked by a similarity score that was barely above noise. This release raises the bar a match has to clear, adds a way out of the protected vault, and warns you when something else on your site is still serving files you thought were locked away.

A nonsense search now returns nothing

The relevance floor for semantic search shipped far too low for the embedding models it runs on. Measured against a 78-document library, a query of pure gibberish scored 49 of those 78 documents above the old floor — so the results looked broken, and worse, a real search carried a long tail of documents that had nothing to do with it.

The floor is now set where the noise stops. A meaningless query returns nothing; a real one returns the documents that actually match, and stops. If your library or your embedding provider needs a different setting, the filedeck_semantic_threshold filter still overrides it.

A one-command way out of the vault

Protected files are stored outside the publicly reachable part of your uploads folder. That is the point — but until now, deciding to stop using FileDeck meant moving every one of them back by hand, editing several database fields per file.

wp filedeck release now does the whole job: every protected file goes back to the exact path it came from, with its thumbnails and previews, and WordPress is updated to match. It asks you to confirm first, because publishing files should never be something that happens quietly.

Deactivating or uninstalling still leaves your files protected rather than publishing them — switching a plugin off should not put confidential documents on the open web. Deactivating now leaves the same written explanation in the folder that uninstalling always did, so the 403s are never a mystery.

Fixes & improvements

• FileDeck now notices when a media-offload plugin or CDN is still serving a protected document from a bucket or edge copy, and says so in the admin. Moving a file into the protected folder does not recall a copy that something else pushed elsewhere, and until now nothing pointed that out.

FileDeck's bot protection has always meant Cloudflare Turnstile. That is a good default — free, cookieless, usually invisible — but it is a second vendor to onboard for a site already running Google reCAPTCHA everywhere else. Pro now offers both.

Pick a service, once

Under Documents → Settings → Submissions there is now a CAPTCHA service choice: Cloudflare Turnstile or Google reCAPTCHA v2. Paste that service's site key and secret, and it covers both places FileDeck uses a CAPTCHA — the download bot gate and the front-end submission form. One choice, not two that can disagree.

Turnstile stays the default, and an existing configuration keeps working exactly as it did.

Switching back costs nothing

Changing service keeps the other one's keys rather than deleting them, so switching back is a dropdown rather than a re-typing exercise.

And a stored value that is neither of the two reads as Turnstile, not as "no CAPTCHA". A gate that quietly stops gating because of a bad value is the wrong way for this to fail.

Fixes & improvements

• The download gate's on/off switch now reports "needs keys" against whichever service is selected, instead of always checking the Turnstile fields.

CSS gets you a long way, and then one day it does not: you need a different element, an extra wrapper, a column built from your own fields. Until now the answer was to fork the plugin. FileDeck now looks in your theme first.

Copy a template, edit it

Make a filedeck/ directory in your theme and drop a template in:

“ wp-content/themes/your-child-theme/filedeck/document-row.php “

Child theme wins, then parent theme, then FileDeck's own copy. Nothing to register and no setting to turn on.

Two templates are overridable to start with — the table row and the "no documents found" state — and more will follow. The loader itself is generic; the work in adding one is deciding what a template is promised.

What you copy is what you are replacing

The files in the plugin's templates/ directory are the ones FileDeck actually renders, not example copies sitting beside a separate hard-coded implementation. A sample that nobody renders drifts from the real markup, and the person who copied it into their theme is the one who finds out.

Access rules are not in the template

Restrictions are applied before a row ever reaches a template: a document the visitor cannot see is filtered out of the query, or arrives already flagged. A customised row is therefore not a place where an access rule can be lost — which is the property that makes overriding markup safe to hand out.

The catch, stated plainly

Your copy keeps rendering after an update, because yours wins. That also means a fix we make to the built-in template will not reach it. Release notes will call out template changes; re-copy when one lands on a template you have overridden.

Full details, including the variables each template receives: template overrides.

FileDeck already put a Document Library element in Elementor, Bricks and Divi's own palettes. Three more builders now have one: WPBakery (Visual Composer), Avada (Fusion Builder) and Beaver Builder. Each also gets a Document Embed element for a single inline document.

Same options, same output

Layout (table, grid, folders or gallery), an optional category to narrow the library, and a colour scheme — the options people actually reach for. Everything else is a shortcode attribute away, and every element renders through the same pipeline as [filedeck], so a native element and a pasted shortcode produce the same page.

One map instead of six

The part worth mentioning: which control feeds which shortcode attribute used to be written out separately in each builder's element. Six copies of one rule is five chances for a control to quietly stop doing anything after a change lands in only one of them. That map now lives in a single place that every element reads.

Oxygen

Oxygen does not get a native element in this release. It renders shortcodes perfectly well through its own Shortcode element, and we would rather point you at that than ship an element written against an API we have no way to test.

Fixes & improvements

• Element registration stays guarded: a builder that is absent, or that has changed the API we register through, means no element rather than an error — and the shortcode carries on working.

If your site already sells access, your membership plugin already knows who has paid. Until now FileDeck made you tell it again — build a matching group, then keep the two in step by hand as people joined and lapsed. Pro can now ask the membership plugin directly.

Tick a plan

Edit a document category, or a single document, and tick one or more plans. FileDeck detects whichever of these is running:

• MemberPress
• Paid Memberships Pro
• WooCommerce Memberships
• Restrict Content Pro
• s2Member

Run two of them and plans from both appear in the same list. Plans sit alongside the client-area rules you already have — named people, groups and email domains — as another way in, not a replacement: someone gets in if any one of them matches.

Access follows the membership

The plan is checked when the page is drawn, rather than copied onto the document when you tick it. A lapsed membership takes the access with it: the document leaves that reader's library and the download stops working. Renewing brings it back with nothing to re-tick.

A reader without the plan does not see the title in a listing at all, rather than seeing a padlocked row.

Another membership plugin?

Three filters register one: what the provider is called, which plans an admin can pick, and which plans a given user holds. The documentation has the code.

Fixes & improvements

• A plan-gated category now appears on the client portal for the people whose plan admits them, the same way a group-granted one does.

On a library of any size, the problem is rarely "is it in here" — it is "which of these forty do I actually need again next week". Pro now lets a signed-in reader star documents and read the list back on one page.

How it works

With Pro active, every row a signed-in reader can see gets a star. Clicking it saves the document; clicking again unsaves it. Put the shortlist wherever suits you:

“ [filedeck_my_favourites] “

Each reader sees their own list. There is nothing to switch on, and no setting to find.

Access is checked when the list is read, not when it was saved

A document starred last month might have been restricted since. FileDeck does not take the saved list on trust: every entry is re-checked against the rules that apply *now*, to the person looking at it, and anything they can no longer see is simply not there. A shortlist that named a restricted document would be a leak, even without a link.

The same holds in the other direction — starring is not a way to find out what exists. A document a reader cannot see answers exactly as one that never existed.

Signed-in readers only

Logged-out visitors get no star, and the shortlist page asks them to log in.

Remembering an anonymous visitor's favourites would mean either a cookie carrying document IDs on every request, or a server-side record tied to a visitor we have deliberately not identified. Those are tracking decisions, and not ones to make quietly on your behalf. A star that never remembered anything would be worse than no star, so there isn't one.

Fixes & improvements

• The "New" marker now appears in the grid and gallery layouts, not only in the table.

WordPress 6.9 added the Abilities API: a plugin describes what it can do in a machine-readable form, and the MCP Adapter exposes that over the Model Context Protocol. An agent — Claude, Cursor, ChatGPT — can then use it without knowing anything about FileDeck in particular.

FileDeck now registers three abilities: search the library, fetch one document, and list the categories. They are in the free version, because the Abilities API is core WordPress plumbing and this is an integration rather than something to sell.

Install the MCP Adapter, point your agent at the site, and they appear. No further setup is needed. On WordPress older than 6.9 no abilities are registered and the site behaves as before.

Read-only, deliberately

There is no ability to publish, edit, delete, change access or hand out a download — and that is a stance rather than a first step. An agent acts on instructions it reads, and some of what it reads is text somebody else wrote. A library that can only be queried cannot be turned into something worse by a cleverly worded document.

Access is enforced, not assumed

Results are filtered by the same rules a library render uses, for whoever the agent is acting as. A restricted document does not appear in a search, not even its title. Asking for one by ID returns the same answer as asking for a document that does not exist — two different answers would tell an agent which hidden documents are real. Client-area categories are not named.

Agents are given a page link rather than a direct download URL, so the lead-capture, terms and bot gates still apply to anything actually downloaded.

You can require a login before agents may ask at all; the knowledge base has the one-line filter.

On a library that has been running a while, "what's arrived lately" is a common question and a hard one to answer by scrolling.

A date-added filter

Switch on Settings → Display → Show a "date added" filter and a control appears alongside the library's other filters: Any time, Past week, Past month, Past 3 months, Past year.

It is off by default — turning a new control on for every existing library without being asked is a change nobody requested. The shortcode takes it too, so one library can have it while others do not:

“ [filedeck show_period_filter="1"] “

You can also pre-filter a library without showing the control, which makes a tidy "recent additions" block for a home page:

“ [filedeck period="30"] “

The chosen period goes into the URL like every other filter, so a filtered view can be shared and opens showing what it says, and the reset control clears it along with everything else.

Periods rather than a from/to pair, deliberately: a date range asks the reader to know the answer before they search, and "anything from the last month" is the question people actually have.

The filter uses the document's published date — when it entered the library — not the date the file itself was made.

A views column

Every document now keeps a running count of how many times it has been looked at, not just downloaded. Show it with the views column:

“ [filedeck columns="title,downloads,views"] “

Sortable like any other column. The count is kept alongside the activity log rather than read out of it, so trimming old log rows with a retention window does not reset it. Views are recorded on the document's own page and known bots are excluded, the same as downloads.

With activity logging switched off the column shows a dash rather than a zero — "nobody looked at this" and "we are not recording" are different statements, and a confident zero would be the wrong one.

Duplicate a document

Hover a row on Documents and choose Duplicate. The copy carries the original's categories, tags, custom fields, access rules and delivery settings — on a library with a house style, it is the settings rather than the file that take the time.

The copy is created as a draft, whatever the original was. Counters do not come across: it starts at zero downloads and zero views rather than inheriting a history it did not earn.

The folders layout has always grouped documents by category. It just did it in one flat row, so a library filed into "Policies → Safeguarding → Reviews" came out as three unrelated folders side by side.

Sub-folders

Folders now follow your category hierarchy. A category with a parent renders inside that parent, as deep as your categories go. Nothing to configure — if your categories are flat, the layout looks exactly as it did before.

Two details that make it read properly: each folder's count includes everything beneath it, so a parent whose files all live one level down no longer looks empty; and sub-folders are listed before that folder's own documents, because a folder that opens onto a wall of files with its sub-folders buried underneath reads as though it had none.

Download all on a parent takes its sub-folders too. It still ticks the same rows you could tick by hand, so it passes every gate an ordinary download passes.

Select all

A checkbox in the table header ticks every selectable document at once. In the folders layout each folder has its own, so it selects that folder rather than the whole library.

Documents a visitor cannot access have no checkbox, and the header control does not give them one.

Two things that make a portal feel like it is paying attention.

New and already-downloaded markers

Switch on Settings → Display → New & downloaded markers and signed-in visitors get two quiet signals: a small New badge on anything published since they last looked, and a slight dimming on rows they have already downloaded.

Both are read from information the site already holds — the activity log and a per-person "last looked" timestamp. Nothing new is recorded about anyone.

Some deliberate details: a first-time visitor sees nothing marked new, because flagging the entire library on someone's first visit is noise pretending to be information. Already-downloaded beats new — something you have taken is not news, whatever its date says. And logged-out visitors get no markers at all: there is no "you" to compare against, and guessing from a cookie would mean tracking a stranger to decorate a table.

A page of your own when access is refused

Opening a document you cannot access gave a bare not-found page. Safe, but a dead end — the visitor has no idea whether to sign in, ask someone, or give up.

Under Settings → Downloads → When access is refused, pick a page. A short "request access" page is the usual choice.

Documents whose existence is private are never redirected. Anything assigned to named people, shared with a group, or filed in a client-area category keeps its not-found page. Those never appear in anyone else's library even as a locked row, so that one client cannot learn the names of another's files — and redirecting would confirm the document exists to anyone who guessed the URL. Role-restricted and password-protected documents do redirect: they already show as padlocked rows, so a friendlier refusal costs nothing.

Fixes & improvements

• Library rows can now carry extra CSS classes and a title badge from add-on features, which is what the new markers use.

Two search improvements aimed at the same thing: the moment someone types what they mean and the library says it has nothing.

Search synonyms

Every organisation has its own shorthand. Someone searches "PO" and finds nothing, because every document says "purchase order".

Under Settings → Search → Search synonyms, one group per line:

“ PO, purchase order T&C, terms and conditions CV, resume, résumé “

Groups are symmetric — no need to list it both ways round. Importantly, a synonym widens a term, it does not loosen the search: every word you type is still required, so PO template still means "(PO or purchase order) and template" and never starts returning everything containing "order". Entries with a space are matched as a phrase.

Spelling tolerance

Someone types safeguardng and gets nothing, with the document right there. Switch on Settings → Search → Spelling tolerance and a search that finds nothing is retried against the closest spelling — and the library says which word it used rather than silently substituting.

It is only ever a fallback. A search that found something is never second-guessed, so turning it on cannot change a result you get today.

Corrections come from your document titles, categories and tags, deliberately not from the text inside files — correcting towards a word that appears once inside a PDF produces a confident wrong answer. It is conservative on purpose: words under four characters are never corrected, the first letter has to match, and it allows one edit for a short word, two for a longer one.

Your search log still records what people actually typed, even when a correction rescued the search. Recording the corrected spelling would erase the evidence that people keep misspelling something, which is usually worth knowing.