Troubleshooting

Registration is refused with no explanation

By design — a bot that is told which check it failed is a bot that stops tripping it. The reason is in the log under the memberz category:

grep memberz storage/logs/web.log

The usual causes are Craft's public registration being off, the honeypot having been filled, or the form having been submitted faster than its minimum seconds on screen.

"Username cannot be blank"

Craft's useEmailAsUsername is off, so an account needs a username, and the form has no Username row. Add one, or turn that setting on.

Memberz refuses to save a registration form in this state, so if you are seeing this the form predates that check — open and re-save it and the error will name the problem properly.

The email address changed but nothing arrived

When Craft requires email verification, an address change is held in unverifiedEmail and only moves onto the account once the link is clicked. That is what stops a stolen session repointing an account at an attacker's inbox and then walking in through "forgot password".

Check that the confirmation went to the new address — that is where it is sent. If nothing was sent at all, Craft's mailer is the place to look, not Memberz.

A member's field is visible when they set it to private

Check three things, in order.

The template. {{ member.jobTitle }} is Craft's own accessor and knows nothing about privacy. Use {{ craft.memberz.value(member, 'jobTitle') }}.

Who is looking. Owners always see their own fields and admins always see everything. Test signed out, or as a different member.

Other profile forms. The strictest row wins across all of them, so this should not happen — but if a field is hidden when you expect it visible, a second, tighter profile form is the reason.

The privacy dropdowns aren't there

Let members set their own privacy is off in the plugin settings, or the individual row has Members may change this switched off, or the form is a registration form — privacy controls only appear on profile forms, since there is no account to attach a preference to yet.

Photo uploads do nothing

The upload control posts with fetch, which needs the optional runtime:

{{ craft.memberz.js() }}

Without it the file input renders and is inert. If uploads are failing rather than doing nothing, the response carries a message written for the member; check the browser's network tab. 413 from the server before Memberz sees it means PHP's own upload_max_filesize or post_max_size is lower than the plugin's limit.

A field vanished from a form after I deleted it

Deleting a field from the user field layout leaves the row behind in every form that used it. Rows pointing at something that no longer exists are skipped rather than fatal — an author deleting a field should not take the registration page down with it. The form editor marks them.

A directory ignores my ?sort= or ?f[…]=

It is not in the directory's own list. That is the security boundary, not a bug: a request can ask for anything, and the directory answers only for entries it was actually given. Add the field to Sort options or Filters.

If it is in the list and still does nothing: sorting works on account fields only, and a filter needs a field with its own option list. See Directories.

Directory search finds nothing in a custom field

The field has to be marked searchable in its own settings, and the index has to be up to date:

php craft resave/users --update-search-index

Forms disappeared after a deploy

Forms and directories are project config. A deploy that applied a project.yaml from before they were created removes them, exactly as it would a section. Create them on one environment and let project config carry them, rather than creating them on each.

Two members' profiles 404

A slug is unique, and a stranded row from a restored backup or a hand-truncated table can be holding one that belongs to nobody:

php craft memberz/prune
php craft memberz/backfill-slugs

The account area shows "No form has been built for this yet"

The account area renders the first Profile form and the first Account settings form it finds. A site with neither has nothing to show. Tabs only appear for forms that exist, so a site with no account-settings form gets no tab offering one.