wpForo User Custom Fields - WordPress Plugin

How to Configure wpForo User Custom Fields for Forum Profiles

wpForo User Custom Fields is not just for dressing up a registration form. It is meant to create a structured, manageable user data system inside a wpForo forum. In this guide, we will walk through how to turn a set of extra fields into a clear workflow: what information to collect during registration, what users should be allowed to edit in their account, what should appear in the public profile, how to enable member filtering, and where to look when a field exists but does not show up on the site.

This article is written for WordPress site administrators who already use wpForo or are planning a forum with expanded profile options. It does not cover purchasing, payments, or license workarounds. The workflow is straightforward: first verify the site foundation, then create fields, build the forms, test the full path from a regular user's perspective, and only after that move on to less common cases such as displaying fields next to the post author.

The key point is simple: a field in wpForo User Custom Fields does not automatically mean the user will see it in the right place. You need to create the field in the manager, add it to a specific form or page, configure view and edit permissions, save the layout, and verify the outcome using a user account that belongs to the correct forum group.

At the end of the guide, you will find a troubleshooting section, an FAQ, and a comparison with similar solutions. These will help you decide when this add-on is enough and when it makes more sense to look at a full profile or membership plugin.

What Problem This Add-On Solves in the wpForo Ecosystem

Core wpForo already gives you a forum, members, profiles, registration, login, user groups, and access settings. But any active community almost always ends up needing more profile information. An educational forum may need specialty, course, and study format. A professional community may need job title, city, industry, and portfolio. A hobby club may need gaming platforms, experience level, team availability, or links to external profiles.

wpForo User Custom Fields handles exactly that layer between the standard WordPress profile and wpForo's forum-specific profile system. The official documentation describes it as a tool for building an extended profile using builders for the registration form, account settings form, profile page, and member search form. One important detail is that fields do not live in just one form. A field you create can be used in multiple places, but you must explicitly place it into each area where you want it to appear.

That makes it different from a typical "add a user meta field" plugin. Here, the administrator is not just managing a data key, but working within the forum context: where the field is collected, who can see it, who can edit it, whether it participates in member search, whether it should appear in the public profile, and whether it exposes too much information to guests.

That is why the product is especially useful when the member profile is part of how people navigate the community. If users only fill in a name and email address, the add-on may be unnecessary. But if members need to find each other by role, skills, city, gaming platform, membership type, or other attributes, a basic registration form is no longer enough.

How a field differs from a form or profile page

Inside the add-on, there is an important separation of responsibilities. User Fields Manager controls the field itself: the name, hint, description, length or value limits, icon, required status, editability, admin note, and permissions. The form and page tabs control placement: the field must be dragged into the Registration Form, Account Form, Profile Page, or Members Search Form.

If an administrator creates a field called "Company" but does not add it to the account form, the user will not be able to fill it in after registration. If the field is added only to the profile page, but the value is still empty, there may be nothing to display on the public profile. If the field is added only to registration, but not to the Account Form, the user can submit it when creating the account but will not have anywhere to update it later.

This approach gives you flexibility, but it requires careful assembly. Throughout this guide, we will keep coming back to the same chain: create the field - add it to the right form - save - fill it in - verify the public display or filter.

Who this product is a good fit for

This add-on works well for sites where wpForo is already the center of the community and the member profile should stay inside the forum system. That includes private clubs, educational platforms, internal professional communities, support sites, gaming teams, expert directories, or forums where it helps to search for people by additional attributes.

The plugin also fits administrators who do not need a separate social network, but simply want to extend an existing forum. If you do not want to move users out of wpForo into a third-party profile module, being able to manage fields in Dashboard > Forums > Member Fields makes sense. In that setup, users fill out their information in the same place where they read discussions, write posts, and browse other members' profiles.

Who it may not be right for

wpForo User Custom Fields should not be treated as a universal membership site builder. Based on the official documentation and forum sources, registration and account creation still belong to WordPress and wpForo, not to a separate paid-access business layer. If you need pricing tiers, payments, complex subscription rules, content restrictions outside the forum, multiple registration flows for different WordPress roles, or deep automation based on profile answers, you will likely need a dedicated membership plugin or custom development.

Another important limitation is export and bulk data management. In support discussions, the developers explained that custom field data is stored in the wpForo profile table inside a serialized array field. That is fine for how the plugin works internally, but it is not the same as having a clean CSV report ready for an administrator. If your main goal is to export profile data into a spreadsheet on a regular basis, test that process on a site copy before you commit to the setup.

What to Check Before Installing It on a WordPress Site

Before installation, do not start by drafting a long list of future fields. First make sure the forum foundation is ready for the add-on. The product page from gVectors states that this is a wpForo add-on and requires wpForo 2.3.4 or later. That is not just a formality: if the core forum is outdated, some tabs, forms, and save behavior may differ from the current documentation.

Check four things: whether wpForo is installed, whether the built-in wpForo registration flow is being used, whether the forum user groups are clearly understood, and whether you have a test account without administrator privileges. That last point often saves time. An administrator may see more than a regular member, and settings like "Who can view?" and "Who can edit?" only make sense if you test them with different roles.

Compatibility with wpForo, the theme, and registration

If the site already uses Ultimate Member, BuddyPress, Profile Builder, or another profile plugin, decide up front which system controls registration and the public profile. In one support case, a user could not see the fields in registration because they were actually looking at an Ultimate Member form rather than the wpForo form. That is a common trap: the field is configured correctly, but the wrong page is being tested.

wpForo has its own menu URL items for registration, login, profile, and account. For example, the menu documentation shows that the registration item can use the shortcode URL /%wpforo-register%/, and the account item can use /%wpforo-profile-account%/. For administrators, that means: do not create a random WordPress page with a similar title and assume it is the wpForo registration form until you verify the menu setup and the actual path.

You also need to account for the theme. Fields and forms are rendered on the public-facing side of the site, so the theme's CSS may affect column widths, spacing, hint visibility, and field behavior. Before going live, open the registration form, account page, and profile page on both desktop and mobile. This matters especially for forms with multiple columns, file uploads, long descriptions, and checkbox lists.

Permissions and user groups

The ability to set "Who can view?" and "Who can edit?" for each field is one of the main reasons to use this add-on. But permissions require discipline. Do not create a field that exposes internal information, and do not make public viewing available to every group just because it is easier for interface testing.

Start with a small matrix: who fills in the field, who can see it, and who can edit it after registration. For a normal field like "City," viewing may be available to members while editing belongs to the account owner. For a field like "Verification Status," editing is better left to administrators or moderators, and public visibility should only be enabled if the community genuinely needs it. For any field tied to user groups, it is especially important not to let visitors choose administrative or moderator-level access.

Pre-launch check: create a test user in a standard forum group, fill out the profile, log out of the admin area, and open the public profile in a private browser window. That shows you what a member or guest actually sees, not what is available to an administrator.

Personal data and site policy

Any extra field can become personal data. Job title, city, phone number, links, age, organization, documents, portfolio, or uploaded files all require a clear explanation for the user: why the information is collected and where it will be visible. wpForo includes documentation around privacy and data portability, so administrators should connect profile fields to the site's privacy policy and the internal process for handling user data requests.

A practical rule is this: do not ask for everything you might someday find useful during registration. Registration should stay short, and detailed information is better moved to the Account Form, where users can complete their profile after logging in. Only make a field required if you truly need it to safely or fairly admit someone into the community.

Installation and the First Post-Activation Check

The official documentation describes installation as a standard WordPress plugin install by uploading the ZIP archive in Dashboard > Plugins > Add New. After activation, the administrator goes to WordPress Dashboard > Forums > Member Fields and begins configuring fields and forms. If uploading through the admin panel is not possible, the documentation also allows uploading the /wpforo-user-custom-fields/ folder to /wp-content/plugins/ via FTP, but with one important check: you must not end up with a nested folder such as /wpforo-user-custom-fields/wpforo-user-custom-fields/.

This guide does not cover license keys, purchases, or license activation. For a working setup, something else matters more: after activation, you need to confirm that the Member Fields section appears, that the base fields are visible, that saving works, and that a test field can be placed into at least one form.

A minimal installation test

Do not start with a dozen fields. Create one safe field, such as "Professional Role" or "Forum Interest," and run through a short cycle:

1. Open Dashboard > Forums > Member Fields.
2. In User Fields Manager, click the add-field button and choose a simple type such as Text or Drop Down.
3. Fill in Label, Placeholder, Description, and Required if needed.
4. Save the field with Save Changes.
5. Go to the Registration Form or Account Form tab and drag the field from Inactive Fields into the form area.
6. Save the changes again and check the form on the front end of the site.

If the field does not appear at this stage, do not add more. First verify that you are opening the actual wpForo form and not a form from another plugin, that the cache has been cleared, that registration is enabled in wpForo settings, and that the field is not still sitting in Inactive Fields instead of the active area on the correct tab.

Why Reset is more dangerous than it looks

The User Fields Manager documentation specifically warns about the Reset button: it removes custom fields and restores the default field values. This is not a "clear filters" button or a gentle way to refresh the screen. On a production site, that kind of reset can destroy a carefully designed form structure.

Before experimenting, make a database backup and, if the add-on provides the Backup, Export and Import all settings tool, export the field settings and form layout. Do not rely on memory. Once the profile includes different view permissions, multiple tabs, and similarly named fields, rebuilding everything by hand turns into a long and error-prone job.

User Fields Manager: How to Design Data Instead of Just Adding Rows

User Fields Manager is the main working screen of the add-on. This is where you see the standard fields and the administrator-created ones. The documentation notes that fields with a blue background are standard fields: they cannot be deleted, but they can be added to or removed from specific forms on the following tabs. Custom fields appear separately and can be configured around the site's needs.

A good field answers three questions: what information are we collecting, where will it be used, and who has the right to see it. If you only have an answer to the first question, the field will almost certainly turn into profile clutter. For example, "Favorite Topics" might help with member discovery and recommendations, while "Admin Comment" is better left editable only by the moderation team.

Choosing the field type

The official list of types includes Text, Email, Phone, Url, Date, Color Picker, Number, Password, Drop Down, Radio, Checkbox, Textarea, File Upload, Avatar, Usergroup, and HTML. In practice, the type affects more than appearance. It affects data quality. Textarea works well for a bio, but poorly for filtering. Drop Down and Radio limit the possible answers and give you cleaner search behavior. Checkbox works for multiple selections, but it requires a well-designed list of options.

Use as little free text as possible in the registration form. Free text is harder to moderate and harder to filter. After login, you can add more detailed profile fields: experience summary, links, portfolio, list of interests. For the Members Search Form, fields with predictable values work best: city, category, level, participation type, platform, language.

Required status, hints, and limits

Label, Placeholder, Title, and Description help the user understand what is expected. Do not repeat the same wording in all four places. The Label should name the field concisely. The Placeholder can show the expected input format. The Description explains how the information will be used. Title can be used for a short hint if your theme displays tooltips well.

Enable Required carefully. A required field during registration can improve data quality, but it also increases the chance of abandonment. If the field matters only for the public profile, it is better not to block registration and instead ask the user to fill it out later. A useful compromise is to keep the field optional at registration, but add it to both the Account Form and the Profile Page so the member can return to it without pressure.

Max/Min length and Max/Min value are not decorative options. They protect the form from answers that are too short, meaningless, or excessively long. For "Professional Bio," you can limit the length so the profile does not turn into a wall of text. For a Number field, define a range if the value has practical meaning. If the limit is too strict, the user will hit an error and may lose trust in the form.

View and edit permissions

The "Who can view?" and "Who can edit?" settings give each field its own access model for forum groups. That allows one profile to look different to guests, members, moderators, and administrators. For example, a "Company" field can be visible to registered members, while an "Internal verification note" field remains limited to the site team.

The "Can User Edit" field serves a different purpose: whether the user is allowed to change the value in My Profile > Account. If that setting is disabled, the value may still appear on the account form, but without an editor to modify it. That is useful for statuses, internal notes, verification flags, manual classifications, and data assigned by an administrator after review.

Critical verification state: a regular member sees only the fields they are supposed to see, and does not see internal or administrative values. Test this from a non-admin account, not while logged in as an administrator.

File Upload, Avatar, and HTML as special cases

File Upload needs special attention. The documentation states that it has a maximum upload size in MB and a list of allowed extensions, and that the upper limit cannot exceed the server values of upload_max_filesize and post_max_size. Do not ask users to upload documents or images until you clearly understand who will be able to see them, where they are stored, and how you will remove them if requested.

Avatar is a standard type and is already used in the Account Settings form. The documentation notes that you cannot add more than one avatar field to the same form. Password is also a special field: it behaves differently on registration and on the Account Settings page, and in some registration modes it may not appear at all because the password is created through email confirmation.

The HTML field does not collect data. It is an area for displaying HTML inside the form: a divider, an explanation, a rules block, or a visual grouping element. It is useful when a long form needs to be split into logical sections. But do not insert scripts, external trackers, or unsafe code there. In most cases, a short note, a group heading, or a link to community rules is enough.

Building the Registration Form Without Overloading the User's First Step

The Registration Form is configured in Dashboard > Forums > Member Fields > Register Form Tab. According to the documentation, the standard form includes Username, Email, and Password, but Password behavior depends on the wpForo email confirmation setting. If registration confirmation by email is enabled, the password field may not appear on the first step: the user confirms the email address and creates a password later.

The most common mistake here is trying to build the entire community questionnaire directly into registration. Technically, it is possible: fields are created in User Fields Manager, then dragged from Inactive Fields into the Registration Form area, rows can be rearranged, and the one-, two-, or three-column buttons help build the layout. But a long registration form reduces completion rates and makes errors harder to diagnose.

Which fields belong in registration

Only put on the first step what is needed for forum admission or for a correct profile starting point. That may include a community role, region, communication language, agreement to the rules, a short list of interests, or member type. If a field affects moderation or access, it makes sense there. If it is only for making the profile look richer, it is better left for later.

Drop Down, Radio, and a single Checkbox work well in registration. Drop Down helps users choose one option from a list. Radio makes all options visible immediately and is useful when there are only a few. Checkbox is good for agreeing to rules or selecting a small set of interests, but large checkbox groups tend to feel heavy on a registration form.

If you are creating a rules agreement field, the documentation for field types suggests a practical technique: for a single checkbox, you can leave the Label empty, place the consent text in Values, and then make the field required. On a Russian-language site, that wording should be short and clear so the user understands what they are agreeing to instead of just checking a box automatically.

Fields that are better left for the Account Form

Bio, portfolio, links to social profiles, detailed experience, gaming IDs, file uploads, and long-form answers are usually better moved into the user's account area. After registration, the user already understands the forum context and can fill out the profile without pressure. This also lowers the risk of losing a large amount of text if the registration form fails validation.

The gVectors support forum includes a user complaint about losing entered data after an unsuccessful submission of a long registration form. Even if the exact behavior depends on version and configuration, the practical takeaway is reliable: the longer the registration form, the more painful any submission error becomes. That is why long textarea fields on the first step should only be used when they are truly necessary.

Checking Password and email confirmation

If the user expects a Password field and it is missing, check the Login & Registration settings in wpForo. The documentation explains that when email confirmation is enabled, the password may be created on the next step through a link in the email. In a Registration support case, the developer also noted that with this setting enabled, the Password field does not appear because the user receives a notice and sets the password later.

The test should be simple. Open the registration page in a private window, submit the form using a test email address, see whether the password field appears on the first step, confirm that the email arrives, verify that the account is created, and make sure the user can sign in. If you change the confirmation mode, repeat the entire test because both the form and the user's expectations change.

Section takeaway: the registration form should get people into the community quickly and collect only the information needed before the first login. Everything that can reasonably be filled in later should be moved to the Account Form.

Account Form and Profile Page: Where Users Edit Data and Where It Gets Displayed

In wpForo User Custom Fields, the account form and the profile page may look similar, but they serve different purposes. The Account Form is for editing. The Profile Page is the public or semi-public display of profile data. If you mix up those two areas, you run into a common problem: the field has been created and even added to the profile, but the user has no idea where to enter a value.

The Account Setting Form documentation says the controls are located in Dashboard > Forums > Member Fields > Account Form Tab. There you can add and remove fields, manage their order, and arrange rows and columns. The Profile Page documentation describes a similar builder for the public profile page, but explicitly notes that the Profile Page is not a form, even though it contains profile fields and is configured through a layout builder.

How to connect editing and display

The practical workflow is this: create the field in User Fields Manager, add it to the Account Form, save the layout, sign in as a test user, fill out the field in My Profile > Account, then add the same field to the Profile Page and check the public profile. If the field should also be searchable, add it to the Members Search Form after that.

You do not have to show every editable field in the public profile. For example, "Phone" may be useful for administrators to contact a member, but should not be visible to everyone. "City" may be public if location-based discovery is part of how the community works. "Internal status" may only be visible to moderators. That is exactly why view/edit permissions need to be planned together with field placement.

Rows, columns, and field order

The builder lets you define one, two, or three columns for each row, add rows, and drag fields into place. This is not just a design preference. Order and width affect how users experience the profile form. Fields with short values can sit side by side: city and role, language and participation type. Long-input fields are better left in a single column: bio, experience, project description.

Check the mobile layout. Three columns may look fine in the admin builder on a wide screen, but on a phone, long labels and placeholders can make the form harder to read. If your community relies heavily on mobile traffic, use fewer columns and shorter labels.

Why an empty field may not show on the profile page

In support discussions about similar symptoms, the developers explained that custom fields on the profile page may not appear until values have been filled in and saved through the account page. That makes sense: the Profile Page displays a value, not an editor. If no value exists, there may be nothing to show.

That is why your test needs to include filling in the field as a regular user. It is not enough to open the Profile Page right after creating the layout. First enter a value in the account area, save it, and then check the profile. If the field should be visible to guests, open the profile while logged out. If it should be visible only to members, sign in as a different non-admin member.

Members Search Form: Turning a Profile Into Member Search

One of the strongest features of the add-on is not just collecting data, but using custom fields in member search. The Member Search Form documentation explains that when Member Search Type is set to Filter, an advanced search form based on user fields becomes available. The form itself is managed in Dashboard > Forums > Member Fields > Members Search Form Tab.

Member search is useful when the profile becomes a navigation tool. For example, club members search by platform, professionals search by specialty and region, educational communities search by course and level, and support forums search by product or role. In cases like these, an extra field stops being a questionnaire "for the administrator" and becomes part of the site's public value.

Which fields work well for filtering

Fields with a limited set of values work best: Drop Down, Radio, and Checkbox. They produce predictable answers that can be matched consistently. Text and Textarea are much weaker for filtering because users phrase things differently: "New York," "NYC," "New York City," "metro area." If you want search by region, it is better to provide a predefined list.

Do not add fields to the Members Search Form that nobody will actually use for search. For example, "About me" is almost always too open-ended. "Company size," "Role," "City," "Skills," "Platform," or "Language" can be useful if members truly look for people using those attributes. The fewer filters you include, the easier it is for members to understand how to find the right person.

Filter mode and verifying the outcome

To test it, open the Members settings in wpForo and make sure Member Search Type is set to Filter. Then add the necessary fields to the Members Search Form, save, and open the members page. Create two test profiles with different values and verify that the filter distinguishes them correctly.

If the filter does not change anything, check three things. First, the field must actually be added to the Members Search Form, not just created in the manager. Second, the test members must have values filled in. Third, the field's view permissions must not hide it from the current user group. If the filter depends on an empty or inaccessible field, the outcome will look like search "doesn't work."

The boundary between user fields and topic fields

It is important not to confuse user fields with topic fields. In the wpForo support forum, a developer clarified that you cannot filter topics by user custom fields. Members can be searched and filtered by user custom fields, while topics are filtered through the separate wpForo Topic Custom Fields add-on. That is an important architectural limitation for your community setup.

If your goal is to find members by specialization, use wpForo User Custom Fields. If you need to filter topics by request type, product, difficulty, region, or status, look at Topic Custom Fields instead. Trying to solve both problems with one set of user fields will create confusion because a member profile and a topic record are different kinds of entities.

Field Mapping for Different Types of Forum Communities

The most useful wpForo User Custom Fields setup starts not with choosing a field type, but with an editorial map of the profile. You need to understand which data helps the community, which data moderators need, which fields support search, and which ones only make the form longer. If you skip that step, administrators quickly end up with a long list of "just in case" fields: members fill them out poorly, filters become useless, and view permissions become harder to maintain.

Below are several practical models. You do not need to copy them exactly. Use them as a way to validate your own structure: every field should have a place where it is collected, a place where it is displayed, a view permission, an edit permission, and a clear benefit.

Professional forum or expert community

For a professional community, role, industry, specialization, city or time zone, experience, and a link to a public page are usually important. Role and, if needed, Industry can go in registration. The rest is better moved to the Account Form. On the Profile Page, it makes sense to show specialization and a short bio, but not necessarily email, phone number, or internal verification status.

For the Members Search Form, controlled values are especially useful here. Instead of a free-text "Specialization" field, it is better to create a Drop Down or Checkbox with a limited list of categories. That way, members can actually find experts, and the administrator does not have to manually reconcile entries like "SEO," "search optimization," "organic search," and "optimization" afterward.

Result check: create three test users with different roles and specializations. One should be discoverable by role, another by city, and the third by a combination of several attributes. If the filter feels overloaded, remove the secondary fields from the Members Search Form, but keep them in the Account Form and Profile Page if they are still useful.

Educational forum

For an educational community, you often need course, cohort, level, member role, communication language, and agreement to the rules. Registration can ask for course and consent, while level and interests can be completed later. If the forum is private, it is useful to tie the "Course" field to manual moderation: the user states their course, the administrator reviews the request, and then assigns the correct forum group.

Do not turn the course field into a direct selector for elevated access. If access depends on enrollment, it is better to use the field as a signal for the moderator rather than an automatic pass. This is especially important if some parts of the forum are available only to instructors, mentors, or paid members.

On the Profile Page, you can show course, interests, and a short project description. In member search, Course, Skill Level, and Study Track make sense. Long responses such as "Why you joined" are better kept in the account area or hidden from the public profile if they are only needed by the team.

Gaming club or hobby community

In a gaming club, the profile often centers on platforms, gaming IDs, time zone, favorite genres, and team availability. Checkbox works well for multiple platforms, Drop Down for a primary region, and Text for a specific gamertag. But it is important not to ask for too many public identifiers during the first registration step.

A practical setup is to keep "Main platform" and agreement to the rules in the Registration Form, then add "PlayStation ID," "Xbox Gamertag," "Steam Profile," "Preferred schedule," and "About my play style" to the Account Form. On the Profile Page, show only the values the member expects other people to see. In the Members Search Form, add platform, region, and genre.

Your result check should include viewing another person's profile as a regular member. If an identifier is visible to search engine visitors but the community did not intend that level of publicity, change "Who can view?" before launch.

Product support forum

For a support forum, product, product version, license type, or access level can be useful, but those fields can easily become sensitive. Do not display private statuses or internal notes next to every post. It is better to let the user specify the product and environment while keeping internal verification visible only to moderators.

At registration, you may only need to ask for the member type: customer, partner, developer, or community member. In the Account Form, add product interest, public website, short bio, and optional support context. On the Profile Page, show the role and product if that helps other members understand the context behind an answer. In the Members Search Form, a product interest field may be useful if the forum covers several different products.

If you want to display product interest next to the post author, first verify that the value is short, does not expose private information, and does not break the theme layout. For a long technical environment description, a dedicated support topic works better than a profile field.

Private internal community

In an internal community, fields often resemble a directory more than a public profile: department, team, role, location, manager, internal status. The key here is not to confuse a forum profile with a corporate data system. wpForo User Custom Fields can surface the right information inside the forum, but it should not become the organization's only source of HR data if a separate system already exists.

Keep public and internal fields separate. Department and Role can be visible to members. Internal note, verification status, or access reason are better limited to administrators. If you need regular exports, test storage and export early because support replies point to serialized storage for custom field values.

Best Field Settings: A Practical Decision Table

There is no universal "best settings" preset for every site, but there are durable rules. Each field should be strict enough to make the data useful and flexible enough that users do not abandon the form. In wpForo User Custom Fields, that balance comes from the field type, placement, required status, permissions, and a short description.

How to choose custom field settings in wpForo

Field purpose	Recommended type	Where to place it	What to verify
Selecting a member role	Radio or Drop Down	Registration Form and Profile Page	The user does not gain unnecessary permissions, and the value is visible only to the intended groups.
Agreement to the rules	Checkbox	Registration Form	The field is required, the wording is clear, and the rules link works.
City or region for search	Drop Down	Account Form, Profile Page, Members Search Form	The filter finds test users with different values.
Short bio	Textarea	Account Form and Profile Page	A length limit is set, and the mobile layout remains usable.
Internal moderator note	Text or Drop Down	Account Form or a hidden profile area	A regular member cannot edit it and cannot see the internal value.
File or image	File Upload or Avatar	Account Form	Size and extensions do not exceed server limits, and file access is clearly understood.

Label, Placeholder, and Description should serve different purposes

Administrators often write the same thing in Label, Placeholder, and Description. The result is a form with repeated text that does not actually help the user. It is better to separate the roles. Label is the short field name: "City." Placeholder shows the expected format: "Select your city" or "Enter portfolio URL." Description explains the purpose: "This value is shown in your forum profile" or "Visible to moderators only." In this Russian article, we translate the meaning, but in the actual UI you should keep the exact labels exactly as they are defined in your form.

If the field is public, say that clearly in the Description. If it is used in search, mention that too. People are more willing to fill out a profile when they understand the benefit: others will be able to find them by specialization, city, or role. If the field is internal, the description should make sense to the team, not to all users.

Required: where it helps and where it gets in the way

Required works well for community rules, a basic role, minimum access requirements, or legally meaningful consent. It works poorly for a long bio, an optional link, an avatar, a file, extended experience details, and anything the user can reasonably complete later. Once registration starts to feel like a long application, part of your audience will leave before posting anything.

A good compromise is a two-step model. Keep the minimum required fields on the Registration Form. Put the extended profile in the Account Form and explain that a completed profile helps other members find the right person. That matches real behavior better: users join the community first, browse discussions, understand the value, and then fill out the rest of the profile.

Can User Edit and "Who can edit?" are not the same thing

Can User Edit controls whether the user can change the value in their own account. "Who can edit?" works at the group level and defines which groups have permission to edit the field. Do not mix them up. If the field is a user-authored description, the profile owner should be able to edit it. If the field reflects a review outcome, a manual classification, or an internal status, the owner should not be able to change it independently.

Check questionable fields in three states: administrator, moderator, and regular member. If a regular member sees an editor for an internal field, go back to the settings. If a moderator is supposed to see a field but cannot, check "Who can view?" and the forum user group, not just the WordPress role.

How to roll back a questionable setting

The rollback path should be simple. If you added a field to the Registration Form and you see a drop in completed registrations, move it to the Account Form, save the layout, and repeat the test. If a public field reveals too much, change "Who can view?" and check the profile while logged out. If a new filter confuses members, remove the field from the Members Search Form but keep it in the profile if it is still useful.

Do not use Reset to roll back a single field. Reset restores the default values and removes custom fields. For a targeted rollback, it is enough to remove the field from a specific form by moving it back to Inactive Fields or adjusting view permissions. Before deleting the field itself, make sure the data is no longer needed and that you have a backup.

How to test a form without unnecessary risk

For every new field, keep a short verification card: where it was created, where it was added, who fills it in, who sees it, which test user checks it, and what counts as the correct outcome. That is not bureaucracy. It is a way to preserve the connection between the form and the public-facing side of the site.

For example: "Expertise - Checkbox - Account Form, Profile Page, Members Search Form - edited by the member - visible to registered users - check: the filter finds the user by selected expertise." That kind of note immediately shows that the field has to pass through three interfaces and one access check. If it only appears in the account area, the test is not finished yet.

Practical Example: A Club Questionnaire with Profile and Member Search

Let us walk through a realistic example. Imagine a private professional learning community. The administrator wants users to choose a role and agree to the rules during registration, complete an extended profile after signing in, and allow other members to search for people by specialty and city. At the same time, the phone number should only be visible to moderators, while the public bio should appear on the profile page.

Goal of the setup

You need to achieve three outcomes. First, a short registration flow that does not overwhelm the user. Second, an editable profile inside the account area. Third, a filter on the members page that helps people find each other by useful attributes. This is a typical case where wpForo User Custom Fields is more powerful than a simple user meta field plugin.

Preparation

Before setting anything up, make sure wpForo is working, registration is enabled, the members page is available, and you have a test user account. Also decide which fields will be required. In this example, the required registration fields are "Role" and agreement to the rules. "City," "Expertise," "Bio," and "Phone" will be filled out later.

Creating the fields

In User Fields Manager, create the following fields:

• Role - Radio or Drop Down with options like "Student," "Mentor," and "Partner." This field can be required at registration.
• Rules Agreement - Checkbox with the consent text. Make it required if accepting the rules is a condition of participation.
• City - Drop Down or Text. For search, Drop Down is better, but the list must stay manageable.
• Expertise - Checkbox if multiple specialties can be selected, or Drop Down if only one primary specialty is needed.
• Bio - Textarea with a length limit and a clear explanation of where the text will appear.
• Phone - Phone with view permissions limited to moderators or administrators if the number should not be public.

Fill out the Description for each field. This is where you can be transparent about how the data will be used: "Shown in profile," "Used in member search," "Visible only to the moderation team." That kind of clarity reduces distrust and helps align the setup with sound personal data handling practices.

Building the Registration Form

Go to the Register Form tab. Add Role and Rules Agreement from Inactive Fields to the active form area. Do not add Bio or Phone at this stage if they are not required for admission. Save the changes. Then open the registration page in a private browser window and make sure the fields appear, the required logic works, and the user understands what needs to be selected.

If the Password field is not visible, do not assume the add-on is broken. Check the email confirmation mode in wpForo. With email confirmation enabled, the user may create the password on the next step. It is worth explaining that flow in the form text or registration rules if your audience often asks, "where is the password?"

Building the Account Form and Profile Page

In the Account Form, add City, Expertise, Bio, and Phone if needed. Configure the Phone field so that the user can edit it, but only the intended groups can view it. If the number is entered by an administrator instead, disable self-editing through Can User Edit and check how that appears to a regular member.

On the Profile Page, add Role, City, Expertise, and Bio. Do not add Phone to the public profile if it should not expose contact details. Arrange the fields by row: short values can go in two columns, while Bio should stay in one. Save the layout and check the profile after the account fields have been filled in.

Configuring the Members Search Form

In the Members Search Form, add City, Expertise, and Role. Search does not need Bio. Then enable Filter mode for Member Search Type in the Members settings. Create several test values: one member as a "Mentor" in one city, another as a "Student" in another city, and a third with multiple expertise values. Verify that the filter returns the expected people.

Checking the outcome

The final verification should cover the full chain:

1. A new user registers through the wpForo form and sees only a short set of fields.
2. After signing in, the user opens My Profile > Account and fills in the extended profile data.
3. The public profile shows only the values that are allowed to be visible.
4. The members page filters people by Role, City, or Expertise.
5. A guest or a member without the right permissions cannot see restricted fields.

If all five points pass, you can move on to real fields. If even one breaks, do not continue with further setup. In wpForo User Custom Fields, issues usually come not from creating the field itself, but from failing to add it to the right form, leaving the value empty, or assigning the wrong view group.

Permissions, Groups, and User Data Security

Profile fields often seem harmless until they become part of access control. The riskiest type is Usergroup. The Field Types and Options documentation explicitly warns that Admin and Moderator user groups must not be enabled in the Registration Form, otherwise users could register with administrator or moderator capabilities. This is not a cosmetic warning. It is a basic security rule.

A similar issue came up in support discussions about assigning groups based on an answer to a question. The wpForo team recommended being careful with permissions and using secondary usergroups for those cases rather than allowing everyone to choose high-level groups directly. For administrators, that means any field-driven automation must be tested as an access model, not just as a convenient questionnaire.

How to configure visibility safely

Start with the minimum level of access. If a field does not need to be public, do not show it to guests. If a field is needed only by moderators, do not place it on the Profile Page for everyone. If the user should not be able to change a value after review, disable editing for the profile owner and leave updates to the administrator.

A useful practice is to keep a decision table outside the site: field, collection point, display point, who can see it, who can edit it, and why it is collected. Even if you only have ten such fields, that table helps preserve the intent through future revisions. This matters especially when the forum is connected to education, medical topics, legal advice, minors, or internal workplace data.

Spam Protection and unwanted registrations

If unwanted registrations increase after you expand the profile, do not assume the add-on itself caused the problem. Registration is controlled by wpForo and WordPress settings, not only by the field form. The Spam Protection documentation describes wpForo's multi-stage protection model and recommends strengthening it with settings, Google reCAPTCHA, and other measures where appropriate.

Check whether registration is enabled, whether email confirmation is required, whether new accounts need manual approval, whether public fields are too attractive to spammers, and whether you allowed file uploads or links before a member has been reviewed. For an open forum, it is usually better to limit public display of links and files first, then expand capabilities for trusted groups later.

Data storage and export

Support replies from gVectors and wpForo state that custom field data is stored in the wp_wpforo_profiles table inside the fields column as a serialized array, while other user data may live in wp_users and wp_usermeta. This matters for administrators planning reports, migrations, or responses to data requests.

Do not edit serialized arrays manually in the database without a developer and a backup. Even a small mistake in string length or structure can corrupt profile data. For regular exports, test wpForo's official GDPR process, available hosting tools, and your own data format requirements in advance.

Practical takeaway: wpForo User Custom Fields is good at collecting and displaying profile data inside the forum, but it is not a ready-made reporting system. If reporting matters, design that part before you launch the form.

Displaying Custom Fields Next to the Post Author

Sometimes the profile alone is not enough: an administrator wants to display part of the information next to the author of a forum post. For example, on a support forum it may help to see the product, role, or member level. On a gaming forum, the platform or team. On a professional forum, the specialization. The official product page mentions the ability to display integrated fields in Topics and Posts next to the author information when used with Profile Builder, and the support forum has also discussed outputting custom fields through wpForo functions.

This is already a more technical use case. It should not be attempted until the basic forms have been verified. First make sure the field has been created, added to the Account Form, filled out by the user, and made visible to the correct group. Only then should you think about displaying it next to the post author.

When this makes sense

Displaying a field next to the author works best for short, stable, non-sensitive values. For example, "Role: Mentor" or "Platform: Xbox" helps readers understand the conversation. A long bio, phone number, email address, internal statuses, and free-form comments do not belong there. The author's sidebar should stay compact.

You should also consider the culture of the forum. If a value could create pressure on the user or reveal too much, leave it on the profile page. Just because a field can technically be displayed does not mean it should appear next to every post.

A safe example for a template customization

In an older support reply, a developer pointed to the function wpforo_user_field( 'field_name' ); for displaying a field in wpForo templates. Use this approach only in a child theme or through a supported template override mechanism if you understand how wpForo templates are structured. Do not edit WordPress core, the plugin file, or a live theme without a copy.

<?php
// Example for the post author template area.
// Replace professional_role with the actual field key from your setup.
if ( function_exists( 'wpforo_user_field' ) ) {
    echo '<div class="wpf-author-extra-field">';
    wpforo_user_field( 'professional_role' );
    echo '</div>';
}
?>

After making this change, test the theme as a regular member, a guest, and a moderator. If the field should not be public, do not output it in the template without an additional permission check. If the wpForo template changes after an update, compare your copy with the current version and reapply the customization carefully.

A lightweight CSS tweak for compact display

If the field is already being displayed but feels visually heavy, you can add a small CSS rule set to your child theme or the standard location for custom CSS. This example does not affect how data is saved and can be rolled back easily by removing the rules.

.wpf-author-extra-field {
    margin-top: 6px;
    padding: 4px 7px;
    border-radius: 4px;
    background: rgba(54, 121, 191, 0.08);
    color: #2f4d68;
    font-size: 12px;
    line-height: 1.35;
}

The check is simple: open a topic with several posts, look at an author who has the field filled in and another author with no value. The block should not break the author card height, overlap the avatar, or stretch the column. If the theme uses a dark wpForo color scheme, adjust the colors to match and verify contrast.

Verifying the Setup Result

After creating the fields and forms, one quick look in the admin panel is not enough. You need a full test path. A good verification simulates the user lifecycle: registration, login, account completion, profile viewing, member search, editing attempts, and viewing from another group's perspective. That is the only way to catch permission issues and empty-value problems.

Set up the test with a separate user account that you do not mind deleting. Do not use your administrator account: it sees more than it should and can hide real problems. If the site is already live, run the check during a low-activity window or on a staging copy.

Regular user test path

1. Open the wpForo registration page while logged out.
2. Fill in the required fields and submit the form.
3. If email confirmation is enabled, complete the confirmation flow and set the password.
4. Sign in as the new user and open My Profile > Account.
5. Fill in the fields that are meant to be editable after registration.
6. Open the public profile and verify the visible values.
7. Open the members page and apply filters based on the fields you created.

At each step, record not just "works" or "doesn't work," but the exact state: the field is visible, the field is required, the value is saved, the profile displays the value, the filter finds the user, the restricted field does not leak.

Administrator and moderator test path

Check whether the administrator can see internal fields that are hidden from regular members. If a moderator is supposed to edit or view certain values, test specifically with the moderator group. Do not judge based on the administrator account because it has maximum permissions.

If a field is tied to access into the community, test manual moderation of new accounts in wpForo. The Login & Registration documentation describes manual approval: the user cannot sign in until the administrator approves the registration. That can be useful for private communities, but it needs a clear process or users will assume registration is broken.

Post-update verification

After updating wpForo or the add-on, run a shortened test: open Member Fields, make sure the form layout is still there, create or update a value in a test account, then verify the profile and search. Pay particular attention to checkbox and multi-select values because fields like these are more complex than plain text. The wpForo core changelog has included fixes related to profile fields and array-value handling, so post-update verification is worth doing.

If the site uses page caching, exclude registration, account, and profile pages from aggressive caching. User forms and personal account pages generally should not serve stale HTML. For troubleshooting, temporarily clear the cache and repeat the test in a private browser window.

Maintaining Your Field Structure After Launch

After the initial setup, working with wpForo User Custom Fields does not end. Communities change: new roles appear, old fields stop being useful, new access groups are added, and profile visibility requirements evolve. If you keep adding fields without reviewing older ones, the profile gradually turns into a heavy form where users can no longer tell what actually matters.

Every few months, it is useful to review the Member Fields structure like an editor rather than a technical administrator. Ask yourself: which fields are actually being filled out, which ones are used in Members Search, which ones are visible on the profile, which ones are needed only by moderators, and which ones can be removed from registration. That kind of review matters especially after community rules change, a new forum section launches, or the site migrates from another profile system.

Back up before changing the form

The official product page mentions a Backup, Export and Import all settings tool for custom field settings and form structure. If it is available in your setup, use it before any major restructuring: moving fields between tabs, changing required status, deleting old values, or importing from BuddyPress. Also create a database backup through your normal hosting tools or backup plugin.

The reason is not only technical risk. Field structure is part of the user experience. If you remove a field from the Account Form, members can no longer edit it. If you remove a field from the Profile Page, it stops being visible even though the data may still be stored. If you change the list of Drop Down values, older profiles may contain options that no longer exist in the new list. Any major change should therefore be tested on a site copy or at least with a small pilot group.

How to change fields without losing meaning

If a field is no longer needed in registration, do not delete it immediately. First move it from the Registration Form into Inactive Fields on that tab, but keep it in the Account Form or Profile Page if users have already filled in values. Then watch whether questions from new members decrease and whether useful profile information disappears.

If you rename a field, do not just check the Label. You may also need to update the Description, hint text, permissions, and community rules wording. For example, you can rename "Company" to "Organization," but if the description still says "visible to all members" while the field should now be visible only to moderators, a simple rename does not solve the actual problem.

If a free-input field needs to become a list, do not change it abruptly on a live site without reviewing old values. First export or inspect the common responses, group them into sensible options, and then create a new Drop Down or Checkbox field. You can temporarily keep the old field hidden from the public profile while users gradually fill in the new version. That is safer than losing the context of older profiles.

Checking permission changes

Changes to "Who can view?" and "Who can edit?" should be tested separately from layout changes. After editing permissions, open the profile in four ways: as an administrator, as a moderator, as a regular member, and as a guest. If the field is sensitive, the guest view is the most important test. The administrator view is almost always too permissive and does not show the true public state.

For fields tied to usergroup behavior, create a separate test path. Set up a user in a regular group, a user in a secondary group, and a moderator. Check who can see the field, who can change the value, whether the field appears in Members Search, and whether a restricted value leaks next to the post author. If the outcome differs from your access matrix, fix permissions first and only then adjust the form design.

Handling outdated and empty values

Empty values are not always an error. If a field is added to the profile but the user has not yet filled it in through the Account Form, the public page may show nothing. That is a normal state for optional fields. The problem starts when the administrator expects the field to be filled out but has not created a clear path for the user.

To improve completion rates without pressure, add a description in the Account Form, explain the benefit of the field, and only show it on the Profile Page after it has been saved. For an important field, you can create a pinned topic with instructions: where to open the account page, which fields to fill out, and what other members will see. Do not make every field required just to maximize database completeness. Less data is better if it is meaningful and voluntarily provided.

When it makes sense to delete a field permanently

You should delete a field when it is no longer used, has no legal or moderation value, does not participate in search, and is not important to the community's history. Before deleting it, check whether real users still have values stored in it. If the field may contain personal data, think through retention rules and deletion upon user request. wpForo provides privacy and data portability documentation, but the site owner is still responsible for deciding what data gets collected.

If you are unsure, first remove the field from the Registration Form, Members Search Form, and Profile Page, but keep the field itself. That allows you to see whether members or moderators miss it. Permanent deletion should come only after a backup and a final check that the field is no longer needed in the current workflow.

Common wpForo User Custom Fields Problems and Troubleshooting

Below are the issues most commonly encountered when working with wpForo custom fields. Some symptoms are confirmed by the official documentation, while others come from support discussions. The troubleshooting path is always the same: first check where the field was created, then where it was placed, whether the value has been filled in, which permissions are assigned, and which page the user actually opened.

The field exists, but it is not visible in registration

Symptom: the field is present in User Fields Manager, but the user does not see it on the registration page.

Possible causes: the field is still in Inactive Fields on the Register Form tab, the page being tested is not the wpForo form but a registration form from another plugin, changes were not saved, the cache is showing an old page, or permissions hide the field from the current group.

What to check: open Dashboard > Forums > Member Fields > Register Form Tab and make sure the field is in the active form area. Then verify the actual wpForo registration menu item and clear the cache. If the site uses Ultimate Member or another profile plugin, make sure you are testing the wpForo registration form specifically.

How to fix it: drag the field into the Registration Form, click Save Changes, clear the cache, and retest in a private browser window. If another plugin's form is meant to be the main registration flow, do not expect wpForo fields to appear there automatically.

Password does not appear in the registration form

Symptom: the administrator added Password, but users do not see a password field on the public registration form.

Possible cause: registration confirmation by email is enabled. The Registration Form and Login & Registration documentation explains that in this mode, the password may be created after the user follows a link in the email.

What to check: open the Login & Registration settings in wpForo and see whether email confirmation is enabled. Then submit a test registration and inspect the email message.

How to fix it: either keep confirmation enabled and explain to users that the password is set after email confirmation, or change the registration mode if your site needs a password field on the first step. After making the change, retest the entire path.

The field is visible in the Account Form but does not show on the profile

Symptom: the user can fill in the field in the account area, but the public profile page stays empty.

Possible causes: the field was not added to the Profile Page, the value was not saved, the profile is being viewed by someone without permission to see it, the theme hides the block through CSS, or the user has not yet met the conditions for profile display in a specific wpForo setup.

What to check: whether the field has been added to the Profile Page Tab, whether the value is filled in under My Profile > Account, which groups are selected in "Who can view?", and whether the profile is visible for a user with at least one approved post if your setup depends on that behavior.

How to fix it: add the field to the Profile Page, save, fill in the value, verify permissions, and create test user activity if your version's support behavior hides profile fields for members without approved posts.

The user cannot change the value

Symptom: the field is displayed, but a regular user does not see an editor or cannot save a new value.

Possible causes: Can User Edit is disabled, the field was not added to the Account Form, "Who can edit?" does not include the user's group, or the value is meant for administrative control.

What to check: open the field settings in User Fields Manager and verify Can User Edit and Who can edit. Then open the Account Form and make sure the field is placed in the active area.

How to fix it: enable editing only for the appropriate groups. If the field is internal, do not make it editable just to simplify testing. It is better to leave a clear description in the Account Form or remove the field from the user-facing form.

Members Search does not filter members

Symptom: the search form is present, but the selected values do not produce the expected outcome.

Possible causes: Member Search Type is not set to Filter, the field was not added to the Members Search Form, members do not have values filled in, the field type allows too much free-form input, or permissions hide the field.

What to check: Filter mode in the Members settings, the active area of the Members Search Form, values in the test accounts, and view permissions. For filters, use controlled values: Drop Down, Radio, or Checkbox.

How to fix it: enable Filter, add the fields to the search form, re-save the values for the test users, and verify the result on the members page. If the field is text-based and users enter inconsistent variations, replace it with a list-based field.

Exporting custom fields is awkward

Symptom: the administrator wants to export all user data to CSV, but custom field values do not appear as clean, separate columns.

Possible cause: support replies indicate that custom field data is stored in wp_wpforo_profiles inside the fields column as a serialized array. That works for the plugin's internal structure, but it is not the same as a ready-made report.

What to check: what data actually needs to be exported, whether the need is for a one-off GDPR response or a regular administrative export, and whether there is a safe way to process serialized data.

How to fix it: for individual requests, follow the wpForo documentation on data portability. For recurring reports, involve a developer and work on a database copy. Do not manually edit serialized values on the live site.

Fields disappear after experimenting with Reset

Symptom: after a reset, the form structure returns to the defaults, and the custom fields disappear or stop displaying.

Possible cause: the Reset button in User Fields Manager restores default values and removes created custom fields, exactly as the documentation warns.

What to check: whether you have a database backup or an exported add-on settings file, when the reset was performed, and which fields were removed.

How to fix it: restore the settings from backup or recreate the fields based on a previously saved field map. On a production site, do not use Reset as a way to "refresh" the form.

Integrations, Migration, and the Limits of Automation

The official product page highlights two important capabilities beyond the basic builder: integration with Profile Builder and an import tool for moving custom user fields from BuddyPress into wpForo. These features are useful when a site already has profile data in another system and the administrator wants to reuse it in the forum members directory, profile pages, topics and posts, or member search.

But integrations do not eliminate the need to design your data model. If a field in Profile Builder has a different name, uses a different set of values, or supports a different access model, you cannot move it into the forum blindly. The same applies to BuddyPress: migrating a field does not automatically make it useful in search or safe for public profile display.

Working with Profile Builder

If the site already uses Profile Builder, wpForo User Custom Fields can select fields from Profile Builder and use them inside wpForo. The product description states that values from those integrated fields can be displayed in Members Directory, Profile Pages, Topics and Posts next to author information, and also used in the Members Search Form.

A practical case would be this: you already have a "Company" field in Profile Builder, and the wpForo forum is launched later. Instead of forcing users to enter the same data twice, you can try using that field in wpForo, show it in the profile, and add it to member search. The check should include editing, display, and access validation. If the value appears in Profile Builder but not in wpForo, verify that it has been added to the appropriate Member Fields tabs.

Migrating from BuddyPress

The tool for importing user custom fields data from BuddyPress to wpForo is useful when moving from a BuddyPress-style social profile system to a wpForo forum profile. But profile migration is a sensitive operation. Start by making a copy of the site, exporting a database backup, mapping the fields, and deciding which ones are actually needed in the new profile.

Do not migrate outdated fields just because they exist in the old database. If a field does not support search, does not help moderators, and is not useful to the user, it should not be carried into the public profile. The less unnecessary data you keep, the easier the form is to maintain and the easier it is to explain to users why they are being asked to complete their profile.

What should not be automated without development work

Do not expect a field answer to automatically create complex business logic. Support discussions show that workflows such as assigning groups based on job title or bulk-filling custom fields require caution and sometimes separate development. A field can help the user choose a secondary usergroup or provide information to a moderator, but automatic access assignment needs to be designed and security-tested separately.

If you want to assign permissions based on a profile questionnaire, start with manual moderation. The user chooses a role, the moderator reviews the request, and then manually assigns the correct group. Add automation only after the process is stable and you clearly understand which mistakes could lead to unnecessary access.

FAQ: Configuring Custom Fields in wpForo

Can I add a field only to the profile without showing it during registration?

Yes. A field is created in User Fields Manager, then added separately to Account Form, Profile Page, Registration Form, or Members Search Form. If the field should be filled out after login, add it to the Account Form and, if needed, to the Profile Page. You do not have to place it in registration.

Why is the field in the manager, but the user cannot fill it out?

Most likely, the field has not been added to the Account Form or editing is restricted for it. Check the Account Form tab, the Can User Edit setting, and the "Who can edit?" option. The Profile Page displays data, but it is not an editing form.

Can I search forum topics by custom profile fields?

No, those are different entities. User custom fields are used for profiles and member search. To filter topics by their own fields, you need a different type of solution, such as wpForo Topic Custom Fields, if it fits your use case.

What should I do if Password is not visible during registration?

Check email confirmation in the Login & Registration settings. When email confirmation is enabled, the password may be created after the user follows the link in the email, so the Password field is not shown on the first step. That does not necessarily mean the form is broken.

Can I let users choose a forum usergroup during registration?

Technically, the Usergroup field exists, but it needs to be used with extreme caution. Do not include administrative or moderator groups in the registration choices. If users need to choose a participation level, it is safer to work with secondary usergroups and manual review rather than giving visitors direct access to elevated permissions.

Where are custom field values stored?

Support replies indicate that custom field values are stored in the wp_wpforo_profiles table inside the fields column as a serialized array. Do not edit this data manually in a live database without a developer and a backup.

Do I need to add every field to the Members Search Form?

No. Add only the fields members will actually use to find each other. Drop Down, Radio, and Checkbox work best for filters. A long Textarea, bio, or free-form comments usually do not produce good search behavior.

Can I use this add-on instead of a larger profile plugin?

If your entire user flow is centered around wpForo, often yes. If you need standalone registration flows, content restrictions, payments, account areas outside the forum, or a complex site-wide member directory, compare it with profile and membership plugins first.

When wpForo User Custom Fields Is the Right Choice

wpForo User Custom Fields is worth using when the forum profile needs to become a useful community tool rather than just a page with an avatar. The product works best in setups where a single field moves through the full chain: the administrator creates it in User Fields Manager, adds it to registration or the Account Form, displays it on the Profile Page, includes it in the Members Search Form, and verifies view permissions for different groups.

The add-on's main strength is its native connection to wpForo. You are not working with abstract WordPress meta fields, but with forum forms, profiles, member search, and usergroups. That is especially useful for communities where members meet each other, find each other, confirm roles, show experience, or complete a profile specifically inside the forum.

You should also accept its limitations up front. The add-on does not replace a full subscription system, does not automatically solve complex permission assignment, does not turn serialized data into ready-made reports, and should not be used to collect extra personal information "just in case." A strong setup is built on a minimum of required fields, clear permissions, a test workflow, and verification from the perspective of a regular user.

If this guide has helped you understand which fields your community needs, where they should be filled out, and who should be able to see them, the product can be tested safely on a site copy. Start with one or two fields, take the chain all the way to a visible saved outcome, and only then expand the profile where new data genuinely helps members and moderators.