Troubleshooting

A critical error appears after updating

Fixed in 2.8.3 — update to that version or later and it will not happen again.

Versions before 2.8.3 could crash on the first page load after an update, but only on sites with a published privacy policy page. Because the update routine never finished, the error repeated on every page load instead of clearing on its own.

If a site is currently affected:

1. Connect over FTP or your host's file manager and rename wp-content/plugins/multi-vendor-quote-request to anything else — for example multi-vendor-quote-request-off. The site comes straight back up, with the plugin inactive.
2. Rename the folder back to multi-vendor-quote-request.
3. Go to Plugins → Add New → Upload Plugin, choose the 2.8.3 zip, and select Replace current with uploaded.

Nothing is lost. Quote requests live in their own database table and settings in their own option — neither is touched by deactivating, renaming, or reinstalling the plugin.

Quote emails aren't arriving

Work through these in order:

1. Install an SMTP plugin. The single most common cause. WordPress's built-in mail is unreliable and often silently dropped by the recipient's provider. FluentSMTP and WP Mail SMTP are both good, and free.
2. Check the spam folder, especially for the customer-facing emails.
3. Confirm the automation is enabled. Each one has its own on/off switch — see Email Automations.
4. On Voxel sites, check the right screen. Notifications moved to Voxel → Settings → App Events in 2.8.1. If the settings under Quote Requests → Settings appear to have no effect, that's why — they're kept for reference but no longer used on Voxel sites.

The customer dashboard is empty

The customer dashboard matches requests to the logged-in user by email address. A request submitted with a different address than the one on the account won't appear.

This is usually a guest who typed a different email than the one they later registered with. Two things help:

• Turn on Lock Name & Email for Logged-in Customers (Settings → General), so logged-in customers can't submit under a different address.
• For existing requests, correct the email on the request itself from Quote Requests → All Quotes.

Emails link to the wrong page, or the dashboard badge is missing

Set Customer Dashboard Page URL and Vendor Dashboard Page URL under Settings → Emails.

The plugin auto-detects these by finding the page containing the shortcode, which fails when the dashboard is built with a page-builder widget rather than a raw shortcode. Setting the URLs manually fixes both the email links and the unread-count badges in your navigation menu.

The vendor's city isn't showing

Start at the settings screen: with a Vendor Profile Post Type set, it shows what your vendor names currently resolve to — "Albion — Catania" if the city is being found, or just the name with a note if it isn't. That tells you immediately whether the problem is the city key or something else.

If no city is found, the Vendor City/Location Field Key doesn't match how your theme stores the field. It works with either a custom field or a taxonomy — Voxel's own "City" field type creates a taxonomy, which is a common surprise. You don't have to guess: the settings screen lists every field and taxonomy it can actually find on your profile posts, directly beneath the setting. Use one of those.

An obviously-named city field or taxonomy is picked up automatically when the key is left empty, so if your profiles have a plain city field there's nothing to configure. A general "location" or "address" field is deliberately never used automatically, since it may hold a full street address — name it explicitly if that's what you want shown.

A customer can't find their request by the number in an older email

Requests are identified by a reference such as QR-7K3M9P. Before 2.11.0 they were identified by a plain record number (#12), and existing requests were given references when you updated — so a number quoted in an older email no longer matches anything. The reference shown on the customer's dashboard, and in any email sent since the update, is the current one. Searching the admin list by customer name or email finds the request either way.

The vendor's name, city and profile link are all wrong at once

These three share one cause: Vendor Profile Post Type doesn't match a post type that exists, so no profile is ever found. The name falls back to the WordPress username, no city is looked up, and the vendor's name links to their author archive (/account/name/) rather than their profile page.

Almost always it's the slug. A post type displayed as "Partners" may be registered as partner or as partners, and only one of them works. The settings screen lists the slugs that actually exist on your site beneath the setting, and tells you when what you've entered matches none of them — use one from that list.

The vendor shows as a username instead of their business name

Set Vendor Profile Post Type (Settings → General) to the slug of your vendor profile post type — partner, for example. The profile's title then replaces the WordPress username everywhere: dashboards, quote views, and emails. See Multi-Vendor Mode.

A dashboard or button renders with stray markup

Pasting a shortcode into an Elementor Text Editor runs it through a content filter that can inject extra tags. Use the matching Elementor widget instead — Customer Quotes Dashboard, Vendor Quotes Dashboard, Admin Quotes Dashboard, or Quote Button. The widgets bypass the filter completely and add styling controls.

The floating button count looks wrong

The count reflects the visitor's current session. If it looks stale, load any page once — the badge re-syncs from the server on every page load, and a leftover count from an expired quote clears itself.

Still stuck?

Open a ticket from your account at codewattz.com. What helps most, by far, is the actual error text rather than a screenshot of the generic "critical error" page:

• Turn on debugging by adding define( 'WP_DEBUG', true ); to wp-config.php, reproduce the problem, and copy the error that appears.
• Or send the last lines of wp-content/debug.log, or your host's PHP error log.

A real stack trace usually turns a week of guessing into a same-day fix.