Troubleshooting

DaisyFilter is disabled and chat is unfiltered

Look for a single SEVERE line at startup saying DaisyFilter could not find or validate a licence key. The server itself starts normally, so the visible symptom is that nothing is being filtered rather than an obvious failure — check for this first after any restart that followed a network or host change.

DaisyFilter validates its licence against https://license.daisy.cat on every start and is fail-closed: no key, a rejected key, or an unreachable licence server all disable the plugin. It needs outbound HTTPS on port 443, every time, with no offline mode.

The message carries a code — LK-01 to LK-04 for a missing key, or a rejection reason plus after 2 attempts. licensing.md explains each one and what to do. Your key is never written to the log; quote your fingerprint in a support ticket instead. /daisyfilter status shows it on a server that started, and BuiltByBit installs also keep a copy in plugins/DaisyFilter/secrets/license.properties.

Note the symptoms overlap with the section below: both are outbound-network problems at startup. The difference is which host is blocked — Maven Central for the drivers, license.daisy.cat for the licence — and that a driver failure is reported by Paper before DaisyFilter runs at all, while a licence failure is reported by DaisyFilter itself.

The plugin does not load at all on a brand-new install

DaisyFilter needs outbound network access the first time it starts. The SQLite and MariaDB database drivers are not shipped inside the jar — they are declared in plugin.yml and downloaded by Paper’s own library loader at boot. That keeps the download substantially smaller and lets the drivers be shared with any other plugin declaring them.

If the machine has no outbound access, or Maven Central is blocked or unreachable, Paper cannot resolve them and the plugin is disabled before it runs. Look for a library-resolution failure naming DaisyFilter early in the server log, before DaisyFilter’s own startup banner — it is a Paper error, not a DaisyFilter one.

What to do:

• Start the server once on a host with outbound network access. The drivers are cached in the server’s shared libraries/ folder, so every later start works offline.
• If your host firewalls outbound traffic, allow it to Maven Central for one boot, or copy an already-populated libraries/ folder from a machine that has started successfully.
• This affects the first start only. Reloads, restarts, and normal running need no network.

/daisyfilter status shows Database: Degraded

The database is unreachable or failing. Filtering continues (censoring, blocking, warnings) while persistence retries. Check the console for rate-limited storage errors, verify storage.yml, and confirm the database server is reachable. Queue depth and dropped counts are shown in status.

A rule is not matching

• Confirm the packs loaded: status shows enabled/disabled rule counts and how many packs are live.
• Run /daisyfilter filters to see per-pack rule counts and any parse errors. A pack that fails to parse is skipped and named in the console; the previous rules stay live.
• A rule disabled at load is reported with its rule ID and reason (the pattern is never printed). Invalid regex disables only that rule, not the pack.
• Run /daisyfilter test <message> to see the decision and which rules fired.
• Check /daisyfilter allowlist — the term may be allowlisted, or the rule disabled, from an earlier in-game decision.
• If a benign word is wrongly flagged, see which whitelisting route you need.

Rule state shows degraded

The filter packs could not be read on the last reload, so the previous rule snapshot is still active — you are protected, but not by the edit you just made. The console line above says which pack failed and why.

Fix the file and run /daisyfilter reload again, or restore the shipped version with /daisyfilter filters reset <pack> (your copy is kept as a .backup-* file beside it). If filters/ is empty or unreadable entirely, DaisyFilter falls back to a built-in core rule set and says so loudly in the log.

Reload did not apply a change

/daisyfilter reload re-reads the configuration files, every pack in filters/, and the allowlist. The storage backend, spam tuning, escalation structure, and chat listener priority require a restart. A failed reload keeps the previous valid snapshot — check the console for the compilation error.

Exact evidence is unavailable

Exact evidence requires both enabled raw storage and the daisyfilter.view.raw permission. Existing installations retain their previous privacy setting. If the key under secrets/ is missing or invalid, raw storage is refused and the GUI shows the masked preview instead.

A GUI punishment is refused

Confirm the profile is enabled, the staff member has its permission, its command root appears in allowed-command-roots, and the selected duration belongs to the profile. Unknown placeholders and line breaks are rejected. Failed attempts are recorded in the incident’s staff-action audit.

Temp-mute / kick never fire

Escalation is disabled by default. Enable it in escalation.yml and define thresholds. RUN_COMMAND steps additionally require the template to be listed in command-allowlist.

Players bypass filtering unexpectedly

Bypass permissions default to false. Check your permission plugin for an inherited daisyfilter.bypass* grant. Snapshots refresh on join and in batches; with LuckPerms installed a refresh hook keeps them current.

Export produced no raw content

export ... include-raw requires daisyfilter.view.raw and enabled raw storage; otherwise the raw field is omitted and the run is reported as metadata-only.