WP Adverts Custom Fields - WordPress Plugin

Guide to Setting Up WP Adverts Custom Fields for Listing Fields and Search

WP Adverts Custom Fields becomes necessary when the standard listing form no longer fits the real needs of your site. One project may need to collect a vehicle make, mileage, and transmission type; another may need square footage, neighborhood, and lease term; a third may need service format, schedule, hourly rate, and preferred contact method. This guide shows not just where to add a field, but how to design the form so users can submit listings without confusion, administrators get useful data, and visitors can find the right listing through a search experience that actually makes sense.

Below, you will find the preparation process, installation, your first form schema, field types, data sources, search rules, category-based schema assignments, and a practical use case for a classifieds site. It also covers how to verify the outcome, which mistakes show up most often, and when it is better not to overcomplicate the form.

This material is intended for site owners, editors, WordPress integrators, or developers maintaining a WPAdverts classifieds board. It does not replace the official documentation, but it turns that documentation into a usable workflow, from the initial field idea to a verified result on the public-facing site.

How the Add-On Changes the Way a Classifieds Site Works

Base WPAdverts already gives you the foundation for a classifieds board: a listing post type, listing and submission pages, forms, blocks, shortcodes, and listing management. WP Adverts Custom Fields adds a form schema builder on top of that. The key word here is schema. You are not configuring a random standalone input, but a managed structure: which fields exist in the form, what they are called, whether they are required, where their choices come from, where they are displayed, and whether they participate in search.

The official add-on page highlights three areas you can change through the visual editor: the submission form [adverts_add], the listing and search form [adverts_list], and the contact form on the listing page. The documentation also explains that when you create a schema, you choose a Form Type: Adverts Add, Adverts List, or Contact. That keeps responsibilities separate. A field needed when someone submits a listing does not always belong in search filters. A field that is useful in a message to the seller does not necessarily need to appear on the listing page.

Internally, the flow looks like this: the administrator creates a form scheme, chooses the form type, adds or edits fields, saves the schema, sets it as default or applies it through a shortcode parameter, and then checks the front-end result. For visitors, this shows up as a more precise submission form, more capable search, and a more informative listing card. For administrators, it means less manual moderation and fewer follow-up emails.

Why This Is Not the Same as Standard WordPress Custom Fields

WordPress includes built-in custom post fields, but on their own they do not give you a usable public form, validation, search support, or output on the listing page. WP Adverts Custom Fields works inside the WPAdverts system: fields appear in the submission form, are saved as listing data, can be displayed in the listing card, and can be used in the search form. That is why the add-on is especially useful for classifieds, where data structure matters just as much as the description text.

If you add a custom field manually through code or a third-party builder, you then have to solve each part separately: where it appears, how it is validated, how it is searched, and how it is displayed on the page. Custom Fields removes most of that routine through the schema interface, but it does not eliminate the need to think through your data model. The main implementation mistake is adding dozens of fields first and only later trying to figure out which ones visitors actually need.

Who Will Benefit Most from This Add-On

This add-on is a strong fit for sites where listings are not limited to a title, description, price, and contact details. It works well for automotive classifieds, real estate, equipment, jobs, services, education, rentals, local exchanges, niche marketplaces, and club directories. In those projects, users do not search only by keywords, but by attributes: condition, deal type, neighborhood, model year, experience, work format, delivery availability, number of rooms, size, brand, or service category.

WP Adverts Custom Fields is also useful for sites where different categories need different forms. The documentation describes the "Different form for each category" approach: you can create separate schemas for categories and let subcategories inherit the parent schema. This is an important feature for sites with multiple listing types. Fields for cars should not frustrate someone posting a job, and apartment rental fields should not end up in a section for selling electronics.

The add-on may not be the right fit if you want a full universal directory builder with multiple post types, maps, reviews, booking, and a large visual page builder all in one package. In that case, it makes sense to compare WPAdverts with HivePress, Directorist, GeoDirectory, or Classified Listing. But if your site already runs on WPAdverts and your goal is specifically to manage listing fields, search, and the contact form, Custom Fields remains a focused tool that gets the job done without forcing a bigger rebuild.

What to Check Before Installation and Initial Setup

Before installing the add-on, make sure base WPAdverts is already working properly. According to the WordPress.org documentation, activating WPAdverts creates pages with [adverts_list] and [adverts_add], and setup continues under Classifieds / Options. If those pages were never created, were deleted, were renamed without testing, or are not selected as the active listing pages, Custom Fields will be harder to troubleshoot because you will not know whether the problem is in the new schema or in the base WPAdverts setup.

Start by creating or checking a test listing with the default form. Make sure it saves correctly, opens on its own page, appears in the listing view, and that the contact form sends a message. If you already have a 404, a blank page, or a broken submission flow at this point, do not start configuring Custom Fields yet. In the WPAdverts FAQ, the standard fix for 404 errors on listing pages is to check rewrite rules under Settings / Permalinks and save the settings again without changing anything. That is a basic routing repair, not a field configuration step.

Permissions, Backup, and a Test Area

Form changes affect the path your user data takes through the site. Because of that, it is best to test everything on a site copy or at least on a private test page first. A safe minimum workflow looks like this:

• Make sure you have a backup of the database and site files.
• Create one test category and one test listing that you can delete later.
• Save the current pages with [adverts_add] and [adverts_list], or the corresponding blocks, so you know exactly where the new schema is being applied.
• Write down the existing shortcode values if you plan to use the form_scheme parameter.
• Check that page caching and optimization tools are not hiding form changes from logged-out visitors.

For a large classifieds site, it is worth agreeing on naming rules up front. For example, submission schemas could be named cars-add, real-estate-add, jobs-add, while search schemas could be cars-search, real-estate-search, and jobs-search. The documentation requires Form Name to be a simple name using Latin letters, numbers, and hyphens. Clear names save time once you have more than three schemas.

What to Review for Compatibility

Custom Fields depends on WPAdverts, so the base plugin must be installed and active. The official add-on page lists the minimum supported WPAdverts version, but for real-world use it is better to stay on current WPAdverts versions and keep an eye on the changelog. Recent WordPress.org entries for WPAdverts include changes related to blocks, the REST API, security, the contact form, and access controls. That does not mean Custom Fields is unsafe, but it does show that you should not ignore updates to the base plugin, especially if your forms are open to unregistered users.

If your site uses the block editor, it is important to understand the difference between the older shortcode approach and blocks. The Classifieds Search and Classifieds List documentation says blocks can choose a Form Scheme in their settings. Older shortcodes also support the form_scheme parameter. Do not mix both methods unless you have a reason to. Pick the main approach for the current page, configure it, and only then repeat the pattern on other pages.

Critical pre-launch check: the default listing submission form, listing view, individual listing page, and contact form should all work before you enable a new schema. Otherwise troubleshooting turns into guesswork.

Your First Form Schema: From an Empty List to a Working Editor

After installing and activating the add-on, the main starting point is wp-admin / Classifieds / Options / Custom Fields. The documentation shows that the schema list is empty at first, and creation starts with the + New Form Scheme button. At this stage, you are not adding a field directly to the live site. You are first creating a copy of the selected form type, which you can edit and only later set as default or apply to a specific page.

Choosing the Form Type

Your first choice is Form Type. For a listing submission form, choose Adverts Add. For the search form on the listing page, choose Adverts List. For the message form on an individual listing page, choose Contact. This is not a cosmetic setting. The type determines which fields are available, which extra sections appear, and where the submitted data goes.

In an Adverts Add form, you are modeling the listing data itself. This is where fields belong if they should be stored and help describe the item: product condition, model year, square footage, employment type, experience, service format, additional photos, or a video link if that makes sense for the niche. In an Adverts List form, you are designing filters: what users should choose to narrow the results. In Contact, you add details the seller or listing author needs in the message, but that do not necessarily need to become part of the public listing card.

Form Title, Form Name, and Default

Form Title is for people in the admin panel. It can be detailed and human-readable, such as "Cars - Submission Form" or "Real Estate - Search." Form Name is used technically, including in the form_scheme parameter, so keep it short and predictable. Default makes the schema the primary one for its form type unless a specific block or shortcode overrides it.

A good practice is to create the schema first without checking Default, apply it to a test page through form_scheme, verify submission and output, and only then make it default. This is especially important for sites where users can post listings publicly. One required field with bad validation can temporarily stop new submissions.

A Drag-and-Drop Editor Without the Illusion of Simplicity

Once the schema is created, the visual editor opens. The form is on the left, and the Form, Basic Fields, and Trash blocks are on the right. Fields can be dragged, edited, and removed. The documentation specifically notes that built-in fields can be sent to Trash but cannot be deleted permanently, while user-created fields can be deleted entirely. That makes sense: built-in fields are part of the core listing model, and deleting them outright could break expected behavior.

The visual editor makes it tempting to drag in everything that looks useful. A better approach is different. First, list the decisions a visitor needs to make while filling out a listing. Then group the fields by purpose: core data, item attributes, deal terms, supporting evidence, contact details. Only after that should you move fields into the form. The form should guide the user from simple to complex, not mirror the administrator's internal data table.

Quick Check After the First Save

1. Create an Adverts Add schema with one new optional field.
2. Save the field with Update without making the schema default.
3. Apply the schema on a test page using [adverts_add form_scheme="test-name"], or select it in the block settings if the page is built with blocks.
4. Open the page as a regular visitor and confirm the field is visible.
5. Submit a test listing and confirm the value is saved.

If that small test works, you can expand the form. If it does not, do not add more fields yet. First check the schema name, cache, add-on activation, submission page, and user permissions.

Field Types and Selection Rules: What to Add to a Listing Form

The Getting Started documentation lists ten custom field types in the editor: Header, Label, Short Text, Text Area, Dropdown, Checkbox, Radio, File Upload, Autocomplete, and Date&Time. The listing form also includes a special Account field, but it does not appear in the Basic Fields block because it can exist only once.

Your field type choice affects usability, data quality, and future search behavior. If a user can type "new," "brand new," "unused," or "like new" into a plain text input, a condition filter quickly becomes messy. If condition is defined through a Dropdown or Radio, the values stay predictable. If you need to search by a price range or a date, a text field may work, but it is better to design it with the data type and search rule in mind.

Short Text and Text Area

Short Text works well for brief values: model, SKU, contact person, neighborhood, property code, certificate number. It should not replace the main listing description. If the user needs to write several sentences, use Text Area. For large freeform descriptions, it is better to keep the standard description field and use custom text fields only for specific attributes.

Text fields are flexible, but they do less to control data quality. In search filters, use them where people naturally expect free input: contact name, brand, model, keyword. For fixed classifications, fields with predefined options are usually a better choice.

Dropdown, Checkbox, and Radio

Dropdown is a good fit for a long list where one or more options can be selected, depending on the settings. Radio works well when there are only a few options and you want them visible immediately. Checkbox is meant for multiple selections, such as "additional amenities," "lesson formats," or "vehicle options." The documentation mentions the Max Choices setting for checkbox and dropdown fields. That is useful when you have many options but the business rules require you to limit how many can be selected.

Dropdown fields also have an Empty Option. If the field is required, an empty option makes it clear that the user has not selected anything yet. But if the list is short and the first option is a safe default, an empty placeholder may just add friction. The right choice depends on risk: for "deal type," it is usually better to require an explicit selection; for "unit of measurement," a default value may sometimes be acceptable.

File Upload, Date&Time, and Autocomplete

File Upload should be used carefully. The official Custom Fields 1.3 release describes it as a field that can upload files to the Media Library or store them as regular files in wp-content/uploads/wpadverts. That gives you flexibility, but it also introduces security, file size, moderation, and storage concerns. For public forms, it is better to limit allowed file types and sizes using the built-in settings available in your version, and not accept unnecessary documents unless they are truly needed.

Date&Time is useful for events, deadlines, availability dates, property viewing times, or signup cutoffs. In search, a date only makes sense if you also define a clear comparison rule afterward: before, after, on a specific day, or within a range. Autocomplete works well for choosing from a large set of values, especially with a taxonomy data source, but it needs to be tested in the active theme and at mobile widths because the suggestion dropdown depends on styling and available space.

Header and Label as Tools for a Clearer Form

Header and Label do not collect data, but they help divide the form into meaningful sections. That matters a lot for niche listings. Instead of presenting one long wall of fields, you can create groups such as "Item," "Condition," "Deal Terms," and "Contact." Users understand more quickly why they are being asked for details, and administrators get fewer random omissions.

Do not overuse helper text. If every other input comes with a long explanation, the form starts to feel like a questionnaire. Clarify only what genuinely causes mistakes: phone format, a sample value, a file restriction, the unit of measurement, or the difference between similar choices.

How to choose a field type for a typical classifieds board

Task	Best fit	Why
Product condition	Radio or Dropdown	Values need to stay consistent for search and comparison.
List of amenities or options	Checkbox	The user may need to select multiple attributes.
Brand, model, contact person	Short Text	You need short freeform input.
Event or availability date	Date&Time	A date is easier to validate and use in search.
File, proof, document	File Upload	You need file upload, but with separate security checks.

Display Settings: How a Field Becomes Part of the Listing Page

For the Adverts Add form, custom fields include an extra Display Settings section. This controls whether the field is visible on the listing page and how it is shown. The documentation emphasizes that this section is available only for custom fields, and built-in fields cannot be configured the same way through it.

Display: When a Field Should Not Be Public

The Display setting determines where the field will be shown. The documentation lists options where a field can appear only in forms or only in the admin panel. This is an important protection against exposing more than you intended. For example, an internal moderator note, technical code, lead source, or internal flag should not automatically show up on the listing page.

Set Display deliberately for public fields: if the data helps a visitor make a decision, show it. If the value is only needed for processing the listing, keep it inside the form or the admin side. Not everything a user enters should become part of the public listing card. This is especially important for contact details, documents, personal data, and fields that could reveal more information than necessary.

Display Type: Table Row or Full Block

Display Type defines the output format. The documentation compares Table Row to how Location or Category appears on the listing page, while Full Width is compared to the description output. The rule is simple: short attributes work better as rows, while longer explanations deserve a full block.

For values like "Square Footage," "Mileage," "Employment Type," or "Condition," a table row is usually the right choice. For "Delivery Terms," "Warranty," "Additional Requirements," or "What the service includes," a full-width block works better. If you force a long text value into a table, it will be hard to read and may break the mobile layout.

Display As and the Risk of the Wrong Format

Display As lets you output the value as Text, HTML, URL, Image, Audio, or Video. The documentation warns that URL, Image, Audio, and Video should be used only when the user is entering a valid URL. In practice, that means you should not choose a media-style output for a field where users can type anything they want. First make sure the field really accepts a link in the format you expect and that the moderator understands the risk.

For most sites, it is safer to start with Text. If you need to show a link, first check how WPAdverts handles the value, whether the link opens correctly, whether extra protocols are slipping through, and whether the output looks like a spam invitation. For images and video, it is usually better to rely on built-in WPAdverts media features or a verified upload workflow rather than turning any text field into media output.

Icon and Display Style

Icon appears in table-style output and helps visually separate attributes. But the icon should reinforce meaning, not decorate every row. If the listing card has ten fields with ten different icons, the page starts to feel noisy. Icons are most useful for key attributes such as location, price, condition, date, deal format, or property type.

Display Style for multi-select fields helps present multiple chosen values. Here, you need to test against real data. Three selected options may look clean, while fifteen will turn into an unreadable cluster. If the list is often long, limit choices through Max Choices, split the field into several meaningful groups, or avoid displaying every selected value at the top level of the listing card.

Check After Configuring Display Settings

After configuring output, create a test listing with the field filled in, open the listing page on the public site, and check three states: the field is filled, the field is empty, and the field contains a long value. If an empty field leaves behind an ugly row, a long value breaks the layout, or a link looks unsafe, go back and adjust the display settings. You need to verify this on the actual listing page, not just in the admin panel.

Data Sources: One Set of Options for Submission and Search

Data Sources are one of the most important WP Adverts Custom Fields features if your site relies on many repeated values. The documentation describes a data source as a list of predefined options that can be used and reused with Autocomplete, Select, Checkbox, and Radio. The practical value is simple: you enter the options once, then connect them to both the submission form and the search form.

Imagine a classifieds board for bicycles. In the submission form, the seller chooses "bike type," "frame size," "frame material," and "condition." In search, the buyer wants to use those same options. If the lists drift apart, one person may post "gravel bike," another may search for "gravel," and someone else may see a different wording entirely. A Data Source helps keep that vocabulary consistent.

Predefined Options

Predefined Options is the simplest approach. The documentation describes the path Classifieds / Options / Custom Fields / Data Sources / Add New Data Source, where you define Title, Name, and the Predefined Options type. For each option, you can specify visible text, value, depth, disabled state, and sort order.

The value and text pair matters especially on a site you plan to maintain long term. The user sees text, while value may be what is stored in the database. If you expect future renaming, use stable values. For example, you can change the visible label from "Pre-owned" to "Used," while keeping the stored value used. That reduces the risk of breaking filters and older listings.

Taxonomy Data Sources

Taxonomy Data Sources use WordPress terms. The taxonomy data source documentation notes that it calls get_terms(), and extra arguments can be passed as query string parameters. This is useful when your option list already exists as a taxonomy: listing categories, neighborhoods, property types, brands, or service areas. In that case, the form does not duplicate the reference list, it pulls values directly from it.

A taxonomy source works well with search by category and subcategory. But it needs careful setup: if the taxonomy is hierarchical, check how nesting is displayed, whether empty categories should appear, how terms are sorted, and whether the list overloads the form. For long taxonomy trees, Autocomplete or category-based separation may be a better choice than a massive dropdown.

Callback Function as a Technical Option

The documentation describes Callback Function as a developer-oriented option. It requires a PHP function that returns an array of choices, and registration through wpadverts_custom_fields_register_data_source(). This route is useful when your options do not come from a normal list or a taxonomy, but from something like an external reference source, a separate table, custom business rules, or a more complex filter.

Most site owners will not need a callback. If the problem can be solved with Predefined Options or Taxonomy, start there. A callback adds maintenance responsibility: you have to support the code, check compatibility after updates, and make sure a function error does not break the form. Later in this article there is a safe small snippet for CSS only, not for registering new data sources, because real callback use cases depend heavily on the specific site.

How Not to Ruin Search with a Data Source

A data source should answer a user question, not mirror your internal business structure. If a visitor is looking for rentals, they care about neighborhood, price, lease term, property type, and number of rooms. They do not need a list of internal manager statuses. If you use a Data Source in the search form, make sure each option genuinely helps narrow the results.

Another trap is making the reference list too detailed. If a "brand" field contains hundreds of options, the dropdown becomes awkward. If a "condition" field contains ten nearly identical labels, people will choose randomly. Fewer, clearer options are better. A good Data Source makes the data more consistent, not the form more bloated.

Search Fields: Connecting User Input to the Listing Database

The search form in WP Adverts Custom Fields differs from the submission form not in appearance, but in purpose. The Configuring Search Fields documentation shows that the search form mirrors the structure of the [adverts_list] form, separates always-visible fields from fields shown after Advanced Search, and includes a Search section for each field. That is where you define how the form value will be used to search records in the database.

This is the most technically sensitive part of the setup. A field can look perfect and still return the wrong listings if the search rule is chosen incorrectly. Users will not see the internal mistake. They will simply assume the site has too few listings or that search works poorly. That is why every search field should be designed together with test listings.

Visible and Advanced Fields

The documentation describes a dark divider line with a drag icon: fields above it are always visible, while fields below it open after clicking Advanced Search. This is not just an interface detail. The first fields on the listing page should cover the most common searches: keyword, category, location, price. Less common filters are better placed in advanced search: material, condition, year, extra options, seller type, delivery availability.

If every filter is visible at once, the form takes up too much space and pushes visitors away. If you hide too much, people will not find the filter they actually need. A good setup often starts with two or three visible fields and a careful advanced block.

Search By: Advert Fields, Dates, Taxonomies, and Custom Fields

The documentation describes four groups under Search By: Advert Fields, Dates, Taxonomies, and Custom Fields. Simple listing fields do not require complex configuration. Dates require a comparison rule. Taxonomies require selecting the taxonomy property and operator. Custom Fields require choosing a meta field, comparison operator, and value type.

For site owners, the key is understanding where the data is stored. A listing category is a taxonomy. A custom field value is a meta field. A publication date is a post date. If you choose the wrong group, search will be either empty or far too broad. That is why it helps to build a simple mapping table before configuring the search form: "what the user sees," "where it is stored," and "which search rule is needed."

Date Search

For dates, the documentation describes the on, before, and after operators. It also shows a range pattern: two inputs search against the same date, with one setting the lower bound and the other the upper bound. That is useful for cases like "listings after a certain date," "events before a date," "available from," and "available until."

Do not add a date range if users rarely search by dates. Every extra input makes the form more complex. But if your site is centered around events, rentals, jobs, or time-sensitive offers, a date range can be one of the most useful filters you have.

Searching by Taxonomies

For taxonomies, the documentation explains the term id, title, term slug, and term taxonomy id properties. For a taxonomy data source, term id is usually recommended because it is stable and precise. The matches one or more, matches none of, and matches all of operators define what counts as a match.

In practice, matches one or more is what you usually need: show listings where at least one of the selected categories or attributes is present. matches all of is useful for multi-criteria filtering where a listing must include every selected attribute. Use matches none of sparingly, and only when the exclusion behavior will be clear to visitors.

Searching by Meta Fields

For custom fields, the documentation lists comparison operators such as equal, not equal, greater than, greater than or equal, less than, less than or equal, contains, does not contain, has one or more selected, and has none of selected. The second important decision is the value type: number, binary data, text, date, date and time, decimal number. That affects how the database compares stored values.

If price, mileage, square footage, or room count is stored as a number, use numeric comparison. If the field contains text, use a text operator. For checkbox and multi-select fields, use the dedicated selected-values operators. The wrong comparison type often looks like "search is broken," when the real problem is that the field was not configured as the right kind of data.

Practical Search Filter Test

1. Create three test listings with different values for the field.
2. Open the listing page that uses the target search schema.
3. Test the filter for an exact match, an empty value, and a value that does not exist in any listing.
4. For numbers, test the boundaries: less than, equal to, and greater than the threshold.
5. For checkbox fields, test one selected value and multiple selected values.

It is best to record test results directly in your project working document: "field," "expected output," "actual output," and "fix." That is faster than trying to remember later why a filter was configured a certain way.

Category-Based Schemas: Different Forms for Different Listing Types

Classifieds sites often break down not because they lack fields, but because they try to force everything into one form. You end up with "Mileage," "Number of Rooms," "Work Schedule," "Breed," "Lot Size," "Delivery Type," and "Years of Experience" all in the same place. Technically it is universal, but for real people it is confusing. WP Adverts Custom Fields solves that through form schemes and category assignments.

The official "Different form for each category" documentation describes a working approach: create separate schemas for adverts_add and, if needed, for adverts_list, then assign them to categories under Classifieds / Categories. There you can use Form Scheme for the submission form and Form Scheme Search for the search form on the category page. Subcategories can inherit the parent schema, so you do not have to duplicate the same setup manually at every level of the hierarchy.

Why Category-Specific Forms Work Better Than Conditional Rules in One Form

In comments on the Custom Fields 1.3 release, a user asked about conditional logic that would hide a field depending on a selected value. The developer replied that for most users, different forms based on the chosen category are enough. That is an important practical boundary. If your site is divided into clear listing types, a separate category schema is simpler, easier to verify, and more durable than a heavily conditional single form.

A category-based schema is especially useful when the form is not just hiding one field, but changing the meaning of the listing itself. A car listing needs mileage, fuel type, and transmission. A real estate listing needs square footage, floor, room count, and deal type. A service listing needs format, experience, response time, and coverage area. Splitting these into schemas is far easier than trying to control the entire set from one form.

How to Prepare Categories Before Assignment

Before assigning schemas, review your category tree. If it is chaotic, inherited forms will feel unpredictable to editors. A parent category should represent a major data type. For example, "Transportation" might use a schema with base fields, while "Cars" and "Motorcycles" could use more specific schemas if the differences are meaningful.

The documentation warns that the standard Category field should remain in the adverts_add form. If you want to prevent users from changing the category after an initial selection, the recommended approach is to configure the Category field manually: choose a fill method, enable use values, and keep only the option with the required category ID. The point of that setup is to preserve the link between the selected category and the correct form schema.

preselect_category and Separate Pages

For category-based schemas, the documentation shows the shortcode [adverts_add preselect_category="1"]. This makes the user choose a category first, after which the related form loads. The alternative is to create separate submission pages for each schema and use [adverts_add form_scheme="cars"]. Both approaches work, but they solve different problems.

preselect_category is a good fit for a single "Post a Listing" page where users choose their section themselves. Separate pages are more useful when the site directs people from a specific section, such as "Add a Car," "List an Apartment for Rent," or "Post a Job." In that case, the page already sets the context, and the form does not need to show an unnecessary extra choice.

Testing Inheritance

Create one parent category and two subcategories. Assign the schema only to the parent. Then open the listing submission flow, choose each subcategory, and confirm that the form remains correct. After that, assign a separate schema to one subcategory and make sure it overrides the parent. This lets you verify both inheritance and targeted exceptions.

Applying Schemas Through Shortcodes and Blocks

WPAdverts supports both older shortcodes and modern blocks. The documentation on applying a form scheme shows the form_scheme parameter for [adverts_add], [adverts_list], and some Authors forms. The Classifieds Search and Classifieds List documentation shows Form Scheme selection inside block settings. So before rollout, you need to decide where your form actually lives: in classic page content, inside a block, or in a mixed setup.

When to Use Default

Default is convenient if the site has one primary submission form and one primary search form. You create a schema, test it, make it default, and WPAdverts applies it automatically until a specific shortcode or block defines another one. This is the simplest path for a small classifieds board.

But default can become a problem if the site has several distinct sections. For example, you may make real estate the default, then unexpectedly see that form show up on the cars page. In a multi-category project, it is usually better to use category schemas or explicit form_scheme assignments on pages. Default should describe the general case, not the most important section on the site.

When to Use form_scheme in a Shortcode

The form_scheme parameter is what you need when a specific page should load a specific schema. The official documentation shows examples like these:

[adverts_add form_scheme="cars"]
[adverts_list form_scheme="cars-search"]

In a real project, this is useful for category landing pages, paid packages, special partner pages, and testing a new form. If a schema is not being applied, check the exact name listed under Custom Fields. A single wrong letter or space will cause the page to load the wrong form or the default one.

How This Works with Blocks

In the Classifieds Search block, the documentation describes the Search form Scheme option. In the Classifieds List block, you can also choose a Form Scheme or leave it empty to use the default. This is more convenient for editors working in the block editor who do not want to remember shortcode parameters. But the rules are the same: first create the schema, then select it in the block, then click Apply or save the page and check the public-facing result.

If a page contains both a separate search block and a list block, you need to understand how they connect. The search block can redirect to the listing page through Redirect To, while the list block shows the results. If the filters are not affecting the listings, check not only the Custom Fields setup, but the page architecture itself: where the search submits, which page contains the listing block, and which schema is selected in each block.

Practical Example: Form and Search for a Cars Section

Let us walk through an example that shows the real strength of WP Adverts Custom Fields. The goal is to build a "Cars" section where the seller enters structured data, the buyer filters listings by meaningful attributes, and the listing page shows those details without manual formatting.

Goal

You want a listing submission form for car listings with fields for "Make," "Mileage," "Fuel Type," "Transmission," "Condition," "Model Year," and "Additional Options." In search, you need filters for fuel type, transmission, condition, mileage up to a selected value, and model year from a selected threshold upward. On the listing page, short attributes should appear as table rows, while additional options should be shown as a clean list.

Preparation

Base WPAdverts is installed, the submission page and listing page work correctly, a "Cars" category already exists, and the test page is hidden from indexing or not shown in the menu. The admin panel includes the path Classifieds / Options / Custom Fields. The reference lists are already prepared for fuel type, transmission, condition, and additional options.

Steps for the Submission Form

1. Open Classifieds / Options / Custom Fields and create a schema of type Adverts Add.
2. Set Form Title to "Cars - Submission" and Form Name to cars-add.
3. Add a Header called "Vehicle Details" to separate technical fields from the base title and description.
4. Add a Short Text field for make or model if your brand reference list is not maintained separately.
5. Add a Short Text field or a numeric field, if your editor version supports numeric validation, for mileage.
6. Add Dropdown fields for fuel type and transmission, connected to prebuilt Data Sources.
7. Add a Radio field for condition if the number of options is small and should be visible immediately.
8. Add a Checkbox field for additional options and limit choices through Max Choices if the list is too long.
9. For public fields, configure Display Settings: short attributes as Table Row, additional options with an appropriate multi-select display style.
10. Save the changes with Update and test the schema on a test page.

Do not make every field required. Only the data that is essential to the meaning of the listing or to accurate search should be required. For example, fuel type and mileage matter for a car, but "additional options" is better left optional. The more required fields you add, the greater the chance that users will abandon the form.

Steps for Search

1. Create a schema of type Adverts List named cars-search.
2. Keep the keyword, category, and, if needed, price range in the visible part of the form.
3. Move technical filters below the Advanced Search divider so the form does not become bulky.
4. Use the same Data Sources for fuel type and transmission that you used in the submission form.
5. For mileage, configure search by custom field with a numeric "less than or equal" comparison.
6. For model year, configure a "greater than or equal" comparison if users are searching for cars that are not older than the selected threshold.
7. For additional options, use a multi-select operator if the field stores multiple values.
8. Create test listings with different values and verify the results.

Some ranges require two fields. For example, "mileage from" and "mileage to," or "year from" and "year to." Do not add both ends of every range right away when the site is just launching. Start with the more commonly used limit, observe user behavior, and expand the search gradually.

Verifying the Outcome

Verification should happen in three places. In the submission form, the field should be clear, should not break the mobile layout, and should show required status correctly. In the admin panel, the value should be saved with the listing. On the listing page, it should appear in the expected place without leaving blank rows. In search, the filter should return exactly the listings that match the selected rule.

For a control set, create at least three listings: one with low values, one with medium values, and one with high values. For example, mileage values of 20,000, 90,000, and 180,000. Then test the "up to 100,000" filter. The first two should remain in the results. If all three appear, or none do, the problem is not in the field label but in the search rule, value type, or the fact that the data was saved under a different field name.

A Commonly Missed Detail

If you change a field after listings have already been published, older records may not have that new value. That is normal. A filter based on a newly required field cannot honestly find older listings where that field is empty. Before enabling a strict filter, decide whether you will manually update older listings, hide the filter until enough new data accumulates, or allow empty values to remain valid.

A Safe Way to Improve Field Appearance with CSS

Sometimes the form works, but a specific field needs stronger visual emphasis. For example, you may want to highlight the required "Condition" field or make the "Additional Options" block easier to scan. In a WordPress.org support thread about CSS classes, the WPAdverts developer noted that each field row automatically gets a class in the format wpa-field--{field_name}. That gives you a careful styling hook without editing WordPress core, WPAdverts, or the add-on itself.

Below is an author-created adaptation based on that publicly documented class. It does not change the form behavior, does not touch PHP, and can be removed at any time. You can place it in Appearance / Customize / Additional CSS or in a child theme stylesheet. Before using it, replace car_condition with the actual field name of your field.

.wpa-field--car_condition {
  padding: 16px;
  border: 1px solid #d8e2ef;
  border-radius: 6px;
  background: #f7fbff;
}

.wpa-field--car_condition label {
  font-weight: 700;
}

The check is simple: open the listing submission page as a regular visitor, find the target field, and make sure the styling does not break nearby inputs, hints, or validation messages. Then submit a test listing to confirm that the CSS does not overlap the submit button, hide validation errors, or interfere with dropdown or checkbox behavior.

Rollback is simple too: remove the CSS from Additional CSS or comment out the block. Do not use !important unless you truly need it. If the theme heavily overrides form styles, it is better to inspect the CSS in the browser first than to brute-force every property override.

Working Alongside Blocks, WooCommerce, and Additional Add-Ons

WP Adverts Custom Fields rarely exists in isolation. Base WPAdverts includes the Classifieds List, Classifieds Categories, and Classifieds Manage blocks, and the documentation also describes dedicated search and listing blocks. Additional WPAdverts add-ons may handle payments, maps, authors, messaging, analytics, and WooCommerce integration. In that broader setup, Custom Fields is responsible not for payments or maps, but for the data structure of forms and search.

Responsibility Boundaries with WooCommerce Integration

The pricing-per-feature documentation describes a case where different form schemes can be linked to pricing through WooCommerce Integration. It specifically notes that the related checkbox appears only when both Custom Fields and WooCommerce Integration are active. The practical idea is this: a basic listing package may allow fewer files and fewer fields, while an upgraded package may permit more data or a different set of requirements.

In that setup, it is important not to blur responsibilities. WooCommerce handles the product, payment, and placement package. Custom Fields handles the form, rules, and fields. If a user pays for a package but sees the wrong form, check the form scheme assignment in the product data, not the field settings. If the field is visible but not saving, check the form schema. If payment succeeds but the listing does not get the expected status, that falls under payment integration and moderation, not field configuration.

Working with Authors and the Contact Form

The Authors documentation notes that when Custom Fields is enabled, you can create schemas for Author Profile, Author Search, and Author Contact. That extends the idea beyond listings to author profiles. For a service marketplace, this can be useful: the provider fills in experience, area, and work format, and the visitor searches not only by listing, but by author as well.

The contact form in Custom Fields can also be extended. The documentation says that fields added to and filled in through the contact form are included in the email sent to the listing author. That is useful when the seller needs clarifying details: preferred call time, city, contact method, or a short question. But do not turn the contact form into a second long questionnaire. The longer the message form becomes, the fewer people will send it.

Maps, Location Data, and Search

If the site uses Maps and Locations, do not duplicate location with a random custom field unless there is a clear reason. First check which fields and filters the location add-on already provides. Custom Fields makes sense when you need a separate attribute: service area, on-site visit type, delivery zone, nearest subway station, or pickup availability. After that, make sure the field names do not conflict and do not confuse visitors.

Cache, Theme, and the Block Editor

Forms and filters should be tested both as a logged-in administrator and as a regular visitor. Page cache may show an outdated form, the theme may override input widths, and blocks may have their own display settings. The Classifieds Search documentation includes settings for button placement and form styling, including separate behavior for desktop and mobile browsers. Because of that, some presentation issues are better handled in block settings or in general WPAdverts styling than inside Custom Fields itself.

How to Check Data Quality After Launch

Once the new form goes live, the work is not finished. The first real listings will show whether the fields were designed correctly. A high-quality form collects data that is useful in three places: moderation, search, and the listing page. If a field does not help in any of those places, it is probably unnecessary.

Watch for Empty Values

After a few days, or after the first batch of listings, check which fields are frequently left blank. If an optional field is almost never filled in, it may be poorly explained, buried too low, or simply irrelevant to the audience. If a required field is filled with junk data, the user probably does not understand the question or is trying to work around a requirement that feels too strict.

Empty values matter especially in the search form. A filter for a field that is filled in on only part of the listings may produce confusing results. A visitor selects the filter and sees too few matches, even though the site contains relevant listings where the new field was never filled out. Before putting a filter in a prominent location, make sure the underlying field is being filled consistently.

Compare the Language of the Form to the Language of the Visitor

A field can be technically correct and still poorly worded. For a Russian-speaking audience, "Transmission" is worse than a native-language label if it is not an exact UI label inside the interface. The same applies to any site language. In the WPAdverts admin panel, labels may remain in English, but public form labels should be written in the site language and should be easy for users to understand. The exception is technical identifiers such as field name, code-facing values, and exact interface labels.

Check Listings Across Different Page Templates

WPAdverts can display listings through older shortcodes, blocks, and newer patterns. The base plugin changelog includes changes related to blocks, detail output, the contact block, and access behavior. So after updates, it is worth checking not only the submission form, but the listing page too. Custom fields may still save correctly while looking different because of a new template or block layout.

Do Not Be Afraid to Remove Unnecessary Fields

Removing a field from a schema does not always mean immediately deleting old data from the database, but for users it does change the form and the public output. Before removing a field, check whether it is used in search, whether it is displayed on the page, whether moderators still need it, and whether your site documentation refers to it. If the field was part of a filter, remove the filter first, verify the results, and only then clean up the form.

Field Names, Values, and Long-Term Schema Maintenance

It is easy to create a new field in Custom Fields, but much harder to maintain dozens of fields after several months of active publishing. That is why field name, visible label, Data Source value, and display label should be treated as separate layers of the same system. The user sees a clear label, the administrator sees the schema, the search rule points to the stored name, and older listings may still hold values that have already been renamed in the reference list.

The official documentation requires Form Name to be a simple technical string that can later be used in a shortcode. The same logic applies to fields: the more stable and meaningful the technical name is, the easier it becomes to troubleshoot search, CSS, and legacy data. Do not name a production field field1, option_new, or test. A week later nobody will remember what it was for. Meaningful names such as car_mileage, property_area, job_type, or service_radius are much better.

A Technical Name Should Not Be Marketing Copy

It is tempting to make the internal field name look polished and descriptive, but field name is not the place for a phrase. It should be short, stable, and usable in CSS, search, and support work. The label can be "Vehicle Mileage, mi" while the name remains car_mileage. You can usually change the label with relatively low risk if it is only the visible caption. Changing the name after launch is much riskier because older values may still be tied to the previous meta key.

If you need to change user-facing wording, update the label and hint first, not the name. For example, you may realize that "Housing Type" would be clearer as "Property Type." If the underlying data remains the same, the technical name property_type can stay. That way search, output, and CSS keep working with the listings that have already been published.

Value and text in Option Lists

In Predefined Options, the documentation separates value and text. This is not unnecessary complexity. text is for the visitor, while value is useful for the system. If the site runs in Russian, the visible text might be "New," "Used," or "Refurbished" in the site language. The underlying values can stay stable: new, used, repaired. Later, you can rename the visible wording without breaking the filter behavior.

But you do not always need to enable use values. If the site is small, the options rarely change, and the filters do not depend on technical stability, plain text may be enough. Do not overengineer every field up front. Use value/text separation where the value will be involved in search, integration, export, CSS behavior, or long-term maintenance.

How to Document a Schema for Your Team

Even if Custom Fields lets you configure everything without code, the project still needs simple documentation. A table in a working document is enough: form scheme, field name, label, type, source, required status, display setting, search rule, and where to verify the outcome. This is especially helpful for editors and moderators: they can see which fields matter, why a reference list should not be changed randomly, and how to explain errors to users.

Minimal field record for WPAdverts support

Parameter	What to record	Why it matters
Field name	car_mileage	Search, CSS, troubleshooting, and linkage to older listings.
Label	Mileage, mi	A clear caption for the seller and administrator.
Type	Short Text or a numeric option if available	Determines the input method and the appropriate comparison in the search form.
Search rule	Meta field, numeric, smaller or equal	Helps explain why the filter returns a given outcome.
Display	Table Row, Text	Defines how the field appears on the listing page.

This table does not need to be public. Its purpose is to preserve project knowledge. If a new administrator asks six months later why the "Model Year" field is handled as a range in search, the answer should live in a clear document, not in chat history or someone else's memory.

Moving from a Simple Form to an Extended One Without Losing Listings

The most sensitive use case is when the site is already live, listings are already published, and the owner decides to add more structure. In that case, WP Adverts Custom Fields has to be introduced as a change to a live workflow, not as a clean new installation. New fields will appear in the form, but older listings will not automatically become complete and neatly structured. Some information will remain in the description, some fields will stay empty, and some data may need to be moved manually.

The goal of the rollout is not to "fill everything at once," but to make the transition manageable. Start by deciding which new fields are critical for search and the listing card, and which can be introduced gradually. Then choose a small set. For a car section, that might mean condition, mileage, and fuel type. For real estate, deal type, square footage, and neighborhood. For jobs, work format, schedule, and city. If you start with fifteen fields, you will end up with more old incomplete listings and more questions from users.

Plan for an Existing Site

1. Collect 20 to 30 real listings and note which data users are already putting into the description.
2. Select the attributes that repeat most often and genuinely help users search or compare listings.
3. Create a new schema without setting it as default and test it on a test page.
4. Publish 3 to 5 test listings with the new structure and verify the output.
5. Add a search form only for the fields that are already filled in on the new test listings.
6. Gradually update important older listings manually or through an editorial queue.
7. After verification, make the schema default or assign it to categories.

Manually updating older listings may feel tedious, but it gives you a valuable audit. You will see which fields actually recur, where users choose different wording for the same thing, and which values should be turned into a Data Source. Very often, this review cuts the field list by a third.

How to Communicate Form Changes to Users

If the site is active, users will notice the new form. There is no need to write a long instruction above every field. It is better to add short labels and hints only where mistakes are likely. For example, "Mileage, mi" is clearer than "Enter mileage." "Model Year" is clearer than just "Year." If a field is required, explain the reason through context: "This helps buyers filter listings."

You can also send a separate update or email to registered sellers, but the form still needs to stand on its own. Someone may arrive on the site for the first time and never read any admin announcements. If a field is unclear without outside instructions, improve the label, order, or field type.

What to Do with Older Empty Values

Empty values after a migration are normal. Do not try to fix that with a harsh required filter. If the filter excludes older listings, visitors may think the catalog is empty. A softer approach is to first show the new field on the listing card, then ask sellers to update their listings, then place the filter in advanced search, and only move it into the visible part of the form after enough data has accumulated.

If the field is critical, such as "deal type" in real estate, it is better to update older listings manually before publicly launching the filter. If the field is secondary, such as "parking available," you can keep it optional and avoid building your main search around it.

Practical takeaway: roll out Custom Fields as an editorial data migration, not as a mass field dump. Start with the most repeated attributes, then add search, then expand the reference lists.

Moderation, Privacy, and the Quality of Public Information

Custom fields can collect data that looks harmless but still affects privacy and trust. The contact form can send extra details to the listing author. The submission form can accept links, files, phone numbers, addresses, schedules, documents, or internal comments. Display Settings can accidentally expose something that was meant to stay in the admin panel. So when configuring WP Adverts Custom Fields, you need to think not only about form design, but also about the boundary between public and private information.

Separate Public, Internal, and Contact Fields

Public fields help visitors evaluate the listing: attributes, terms, condition, neighborhood, format, price, date, availability. Internal fields help administrators: internal status, verification source, moderator note, quality flag. Contact fields help communication: preferred call time, buyer question, preferred contact method. These three groups should not be mixed automatically.

In Custom Fields, that separation is controlled through the form type and Display Settings. If a value is needed only in the contact email, add it to the contact form. If it is needed only by the moderator, do not display it publicly. If visitors need it, make sure it is displayed clearly and does not reveal too much. Be especially careful with documents, addresses, and personal data.

Files and Links

The File Upload field can be useful for proofs, documents, supplemental materials, or technical files, but a public upload form always requires attention. Do not accept files just because the field type exists. Ask: who will review the file, should it be public, is there a size limit, what happens to an unsupported format, and should the file be kept after the listing is removed.

The rule is similar for URL fields. If the user enters a video link, the site needs to know how to show it safely. The Display Settings documentation allows output as URL, Image, Audio, or Video only when the value is actually a valid URL. That means this kind of output is not suitable for a freeform text field. It is better to start with text display and only upgrade the presentation after testing.

Moderator Review of New Fields

Moderators need to know which fields are critical. If the seller enters "not sure" into a Mileage field, the listing may pass the basic form, but the filter becomes useless. If "Fuel Type" contains random text instead of a controlled list, the wrong field type was chosen. If users check every option under "Additional Options," the list may be too broad or Max Choices may be missing.

For the first few weeks after launching a new schema, it is useful to maintain a simple moderator checklist: which values count as acceptable, what should be corrected manually, when a listing should be sent back to the author, and which fields can be left blank. That is not bureaucracy, it is a way to preserve data quality until the form becomes familiar to users.

SEO and the Indexability of Custom Fields

Structured fields can improve how readable a listing page is, but they do not guarantee search traffic growth on their own. Search engines care about a useful page, not a mechanical collection of attributes. If a field helps the reader understand the item, it is worth displaying. If it only repeats empty or repetitive values, it may add visual noise.

Do not add dozens of hidden or semi-public fields for SEO purposes. It is better to have a few useful attribute rows in the listing card, a strong description, proper categories, and accurate search. For niche sites, that matters more than trying to stuff the page with template-like wording.

Decision Matrix: Which Fields to Add, Display, and Turn Into Filters

To avoid arguing about every field one by one, use a decision matrix. It helps you decide where a field belongs: only in the submission form, in the form and the listing card, in the form and search, only in the contact form, or outside Custom Fields entirely. This matrix is especially useful for teams where the site owner wants to "add everything," the editor worries about form quality, and the developer is thinking about long-term maintenance.

Questions to Ask Before Adding a Field

• Does this field help visitors make a decision about the listing?
• Will users understand exactly what they are supposed to enter?
• Can freeform input be replaced with a predictable option list?
• Does the value need to be public, or is it internal?
• Will the field be used in search, sorting, or comparison?
• What happens to older listings that do not have this field?
• Who will correct invalid values?
• How will the user see an error if the field is required?

If you do not have answers for most of those questions, it is too early to add the field. Clarify the use case first. For example, "product color" may be important for clothing but useless for jobs. "Lease term" is critical for real estate but unnecessary for a one-time electronics sale. "Certification" may matter for services, but it brings moderation and privacy concerns.

When a Field Should Be Displayed on the Listing Page

Display a field if it helps compare listings or reduces the number of follow-up questions. Short attributes work well in a table layout. Longer explanations are better as full-width blocks. If the field matters only to moderators, do not show it publicly. If it contains a link or file, check the security and format first.

The same attribute can behave differently in different niches. For example, "City" is usually useful both publicly and in search. An exact street address in a private listing may be too personal. "Neighborhood" can be a good middle ground: useful enough for visitors and less sensitive than a full address.

When a Field Should Become a Filter

A field should become a filter only if visitors actually choose listings based on that attribute. Condition, category, neighborhood, price range, date, property type, and core attributes are usually good candidates. Fields that are filled inconsistently or rarely should usually stay out of search. A weak filter is worse than no filter at all: it takes up space, promises precision, and returns empty results.

Every filter needs to be verified. If a field is stored as text but you compare it as a number, search will be unreliable. If the option list in submission differs from the option list in search, users will get empty results. If the value was added only recently, older listings will not show up. That is why every filter should have a test dataset behind it.

When a Field Belongs Outside the Form

Some problems are better solved outside Custom Fields. If you need legal consent, use an appropriate site consent and policy mechanism. If you need complex booking, use a specialized module. If you need to accept payments, that belongs to WooCommerce Integration or a payment add-on, not a custom field. If you need to calculate a price from a complex formula, a normal field can collect the inputs, but it cannot replace the underlying business rules.

Custom Fields is strongest when you need to collect, save, display, and search structured listing information. If the requirement involves actions after submission, complex permissions, calculations, synchronization with external services, or legally significant consent, you should evaluate a separate add-on or careful custom development.

An Editorial Approach to Form Design: Making It Usable for Regular People

A listing form is not just a technical set of fields. It is the site's conversation with a person who wants to post an offer quickly. If that conversation is long, unclear, or requires knowledge of internal terminology, users make mistakes. WP Adverts Custom Fields gives you the tool, but form quality depends on editorial decisions: question order, labels, hints, required status, grouping, and visible outcomes.

Start with the User's Goal

Sellers want to post a listing, not fill out a database. Buyers want to find a suitable offer, not study every possible attribute. Administrators want data that is usable for moderation and search. A good form balances those three goals. It should not be minimal at any cost, but every field should justify itself through context.

For example, a "Mileage" field in a car category is self-explanatory if the unit is shown next to it. "Condition" is better as a radio or dropdown field so values stay consistent. "Features" can work as a checkbox field, but the list should be limited. A "Condition Notes" field can remain a text area, but it should not be required.

Group Fields by User Action, Not by Input Type

Do not place all dropdowns together just because they share the same input type. Users do not think in terms of input controls, they think in terms of the listing itself. For a car, start with core information, then technical specs, then condition and options, then contact details. For real estate, start with deal type, then property, location, property details, terms, and contact. For services, start with category, then format, experience, service area, price, and contact.

Header and Label help build those groups. But the section titles themselves should stay short. "Key Details," "Terms," "Additional Information," and "Contact" are usually better than long instructional headings. If one field inside the group is complicated, explain that field directly instead of putting a long paragraph above the entire form.

Required Fields as a Quality Tool, Not a Pressure Tactic

A required field should have a clear reason behind it. If users cannot submit a listing without filling something in, they should understand why the site is asking for it. Required status makes sense for key filtering attributes. It often does not make sense for supplemental information. A form that is too strict may improve the data quality of people who finish it, but still reduce the total number of submissions.

A reasonable approach is to phase in required fields. At launch, make only the core attributes required. Once users are familiar with the workflow and the catalog has grown, you can tighten requirements in specific categories. Paid or premium packages may have different requirements if your WPAdverts and WooCommerce Integration setup supports that, but the submission process should never feel punitive.

Hints and Labels on a Russian-Language Site

Exact UI labels inside the admin panel remain in English: Form Type, Update, Display Settings, Search By. But public labels should be in the site's language and easy to understand. Do not copy English terminology from the documentation into the public form unless it is a product name or an exact technical token.

A good hint answers one question. "Enter mileage in miles without spaces or extra text" is more useful than "Enter a value." "Choose up to 5 options" is more helpful than "Select additional attributes." If a hint is longer than the field itself, you probably need a different field type or a split question.

Checks After WPAdverts Updates and Theme Changes

A classifieds site lives longer than a single setup session. WordPress gets updated, the theme changes, WPAdverts changes, add-ons change, cache plugins change, the block editor changes, and the hosting PHP version changes. The WPAdverts changelog on WordPress.org shows regular updates related to blocks, the contact form, security, the REST API, accessibility, and gallery behavior. For Custom Fields, that means one thing: forms and output should be checked after changes, even if you did not edit the schemas.

Minimal Form Regression Check

After an update, you do not need to retest the entire site manually. A small regression set is enough:

1. Open the submission page as a guest or a regular user.
2. Fill in one required field, one optional field, and one field using a Data Source.
3. Submit the listing and check the success or moderation message.
4. Open the listing and verify Display Settings behavior for both a filled and an empty field.
5. Open the listing page and test one taxonomy filter, one custom field filter, and one range-style filter, if used.
6. Send a message through the contact form, if it has been extended.

This set takes little time, but it quickly surfaces the most frustrating failures: the schema is not applied, the field is not visible, required validation has changed, the search form does not affect the listing page, or the contact form is not sending the extra data.

What to Check After a Theme Change

A theme usually affects appearance more than data storage. After changing the theme, check field widths, dropdowns, checkboxes, radio buttons, error messages, the submit button, the attribute table on the listing page, and the mobile layout. If custom CSS was tied to the old theme, some of those rules may become unnecessary or harmful.

Do not start fixing things with random CSS. First check WPAdverts Default Styles and block styling settings if the page is block-based. Then apply targeted field classes only where needed. For more complex template issues, it is better to create a separate test page and gradually disable custom CSS tweaks until you isolate the conflict.

What to Check After Enabling Cache

Cache often shows up like this: the administrator sees the new form, but guests still see the old one. Or the form loads, but behaves oddly after submission because of a cached page fragment. For submission pages and the contact form, it is best to be careful with aggressive caching. If your cache plugin allows excluding form pages, test that option.

When troubleshooting cache, do not change the schema first. Open the page in a private browsing window, clear the page cache, temporarily disable JavaScript/CSS minification in your test setup, and check again. If the problem disappears, the cause is not Custom Fields but the optimization layer. In that case, the fix belongs in caching rules, not in new fields.

Troubleshooting: Common Problems with Fields, Schemas, and Search

Most WP Adverts Custom Fields problems can be broken down into a simple chain: the schema was not applied, the field was not saved, the value is not displayed, search is configured for the wrong data type, or an old page or cache is showing an outdated form. Below is a practical troubleshooting map that avoids risky actions and does not require editing plugin core files.

The New Field Does Not Appear in the Submission Form

Symptom: the field exists in the editor, but it does not appear on the "Post a Listing" page. Possible causes: the schema was not saved with Update, it was not made default, the page uses a different form_scheme, the block is set to another schema, cache is serving an older page, or the user is looking at the wrong submission page.

Start in the Custom Fields list: find the schema name and confirm the type is Adverts Add. Then open the submission page and check how it loads the form. If it is a shortcode, compare the form_scheme value with Form Name. If it is a block, open the block settings and select the correct schema. After that, clear the page cache and test again as a logged-out visitor.

The Field Is Visible, but Its Value Does Not Appear on the Listing Page

Symptom: the user fills in the field, the listing is published, but the value does not appear in the listing card. Possible causes: Display Settings is configured for form-only or admin-only use, the field is empty, it was not created in an Adverts Add schema, built-in fields may follow different output rules, or the current page template is not displaying that block of data.

Fix: open the field in the submission schema and check Display, Display Type, and Display As. For a short attribute, start with Table Row and Text. For a longer value, use Full Width. Create a new test listing after the change, because the older listing may not have stored a value for that field.

Search by Custom Field Returns an Empty List

Symptom: the filter is visible, but choosing a value makes the listings disappear. Most often, the search rule points to the wrong field, the comparison does not match the data type, or the values in the search form do not match the values saved in listings. For example, the submission form stores used, but the search form sends "Pre-owned."

Check the Data Source. If the same reference list is used in both submission and search, the chance of mismatch is lower. Then check the Search By group: a taxonomy must be searched as a taxonomy, and a custom field must be searched as a custom field. For numbers, choose a numeric comparison type; for text, use a text comparison; for multiple values, use a selected-values operator. After the fix, retest with three listings that have different values.

The Category Schema Does Not Load

Symptom: the category is selected, but the form stays generic. Possible causes: the schema was not assigned to the category, the subcategory is inheriting from the wrong parent level, the shortcode does not use preselect_category, the user can still change the category after the form loads, or a separate page is forcing a different form_scheme.

Check Classifieds / Categories: the category should have Form Scheme selected and, if you need category-specific search, Form Scheme Search as well. Then check the submission page. For a single page with category selection, use [adverts_add preselect_category="1"]. For a dedicated section page, use the exact form_scheme. If subcategories inherit the schema, test every branch of the tree.

The Form Became Too Long and Users Stop Posting Listings

Symptom: after adding fields, the number of submitted listings drops, or people start entering junk into required fields. The cause is usually not technical, but product-related: too many required questions, weak grouping, unclear labels, or fields that are not tied to any real listing value.

Fix: divide fields into required and optional. Keep only the critical attributes required. Use Header and Label for grouping. Move rare attributes into category-specific forms. If a field is useful only to moderators, do not show it publicly. If a field matters mainly to buyers in search, explain to sellers why it is worth filling in.

Field Styling Looks Broken in the Theme

Symptom: dropdowns, checkboxes, or field hints do not match the rest of the site. Possible causes: the theme overrides input styles, the WPAdverts block has its own styling settings, the field uses a 50% or 100% width in the search form, and the site CSS does not account for that structure.

Start by checking styling settings in WPAdverts and in the block if you are using Classifieds Search. Then use your browser inspector and the row class wpa-field--{field_name} if you need targeted styling. Roll back the CSS if it hides validation messages, breaks dropdown choices, or makes the mobile layout worse.

Page or Block Behavior Changed After an Update

Symptom: after updating base WPAdverts, the form or output behaves differently. The WPAdverts changelog shows that the base plugin regularly updates blocks and fixes access behavior, the contact form, and templates. That is normal for an actively maintained plugin, but on a site with public forms, updates need to be checked.

Before rolling anything back, check the changelog, the form page, the listing page, an individual listing, and the contact form. If you are using an older shortcode, see whether the documentation now recommends a modern block for your use case. If you have custom code on WPAdverts filters, temporarily disable it on a test copy and see whether the symptom disappears.

Video on Setting Up Search Through Fields

The official documentation for search field configuration includes several YouTube videos. For this guide, the most useful one is the video about searching by price, because it demonstrates a principle that transfers to any numeric custom field: create two search fields, connect each one to a value boundary, and test the outcome as a range. That directly supports the intent behind "how to configure search by WPAdverts custom fields" and helps clarify not just which button to click, but how the comparison works.

After watching, do not just repeat the price example. Repeat the method: create test listings, add a pair of search fields, choose the correct operator and value type, then verify the results at the range boundaries. The same approach works for mileage, square footage, room count, model year, and budget, but the field name and labels should match your own site.

Questions That Usually Come Up After the First Setup

Can I use WP Adverts Custom Fields without base WPAdverts?

No. This add-on works around WPAdverts forms and data. Base WPAdverts must be installed and activated first, and the submission, listing, and individual listing pages must all open correctly. Custom Fields adds field schemas, but it does not replace the underlying classifieds engine.

Should I make a new schema default right after creating it?

It is better to test the schema first on a test page or inside a selected block. Default is appropriate when the schema should apply to every form of that type. For sites with multiple categories, it is safer to use form_scheme, category-specific assignment, or schema selection inside the block.

Which fields should be required?

Only fields that are necessary to understand, verify, or filter the listing should be required. For a car, that might be fuel type and mileage; for real estate, deal type and square footage; for a job, employment format. Do not make a field required just because the administrator finds it interesting.

Why is field-based search not working the way I expected?

Check three things: does the field name match, is the correct Search By group being used, and does the operator match the data type. For taxonomy fields, use taxonomy search settings; for custom fields, use meta search; for numbers, use a numeric or decimal type; for multi-select fields, use selected-values operators.

Can I use different fields for different categories?

Yes. The official documentation describes assigning form schemes to categories through Classifieds / Categories. The submission form uses Form Scheme, and category-page search uses Form Scheme Search. Subcategories can inherit the parent schema.

What should I do with older listings after adding a new field?

Older listings may not have a value in the new field. If the field participates in search, that will affect the results. Your options are to update important listings manually, keep the field optional, avoid placing the filter in a prominent location for now, or explain that the filter works only for listings where the data is filled in.

Can I style individual fields with CSS?

Yes, but carefully. In a support thread, the developer pointed to the automatic field row class in the format wpa-field--{field_name}. Use that for small appearance tweaks in Additional CSS or a child theme. Do not hide validation errors and do not edit plugin files.

When might WP Adverts Custom Fields not be the right fit?

If you need fully developed conditional logic in every use case, a large multi-directory builder, a sophisticated map system, booking, reviews, marketplace transactions, and visual page design inside one product, compare alternatives. If your goal is to manage fields, schemas, filters, and output within WPAdverts, this add-on is right on target.

When WP Adverts Custom Fields Is the Right Choice

WP Adverts Custom Fields is a strong choice if you have already committed to WPAdverts and want to turn a generic listing form into a niche-specific data system. The strength of the add-on is not that it adds one more input. It is that it connects the submission form, search, listing page, category-specific schemas, and data sources. That connection is what makes the site more useful: sellers describe items in a structured way, buyers filter more precisely, and administrators spend less time correcting listings by hand.

Before launch, keep one simple standard in mind: every field should have a purpose. It should help publish a listing, find a listing, understand a listing, send the author a more precise inquiry, or support moderation. If a field does none of those things, remove it or save it for later. It is better to start with a short, accurate form and expand it based on real data than to build a long questionnaire from day one.

Once base WPAdverts is working, the category structure is clear, the test listings have been verified, and the form schema is well thought out, you can download WP Adverts Custom Fields and roll it out step by step: first one schema, then search, then categories, then styling and troubleshooting. That sequence reduces risk and makes it easier to see where the new setup actually added value.

The final pre-launch check is simple: create a listing as a regular user, find it through a filter, open the listing page, send a message through the contact form, and review which data the author receives. If that entire chain feels clear and predictable, the guide has done its job - it has helped you configure the product not just formally, but as a working part of a real classifieds site.