Dom

Update: version 1.1.0 is now available and addresses an issue that might interest you.

If you are on the free version, the upload field could stay hidden on products
because of a product/category restriction inherited from the Premium visibility
rules — a setting that the free version does not expose, so it could not be undone.
That is fixed: after updating, fields are shown on all products again.

If instead you are running the Premium version with an active licence, nothing is
broken on your side: the restriction is intentional and you can change it yourself
under Visibility → Product/Category restriction, by selecting “Visible for every
product”.

Either way, if something still does not work, let me know here and I will look into
it.

Hi,
Let me clear up the timeline first, then give you something concrete to try.

First, some context: the two-year period you describe goes back to the previous CodeCanyon version of the plugin — the WordPress.org release is recent. In all that time I never received a report about this from you. Had you reached out, I would gladly have looked into it, and I still will.

Attaching uploaded files to orders is the plugin’s core function and works on the large majority of installations, so a permanent failure like the one you describe usually points to something specific to a given setup rather than to the plugin itself.

There is one cause I see fairly often: some third-party plugins alter the normal WooCommerce checkout flow, and as a result the upload plugin is never notified that the checkout was completed — so the files are never associated with the order. It works everywhere else, and silently fails on that one site.

In the meantime, here is something concrete you can try right now: go to Settings → “Checkout – Files to order association method” and switch it to the other value. In a good number of cases that alone resolves it.

If it doesn’t, I am genuinely happy to help. Please get in touch through the proper channels — either this support forum, or https://vanquishplugins.com/support/ — with a few details about your setup (a debug log is ideal). With that I can usually pinpoint the cause quickly.

Fixed

Hi,
Thanks for reaching out, and sorry for the trouble — I understand the timing is tight with your Monday opening, so let’s get this sorted quickly.

The good news: since the pages work again as soon as you deactivate the plugin, this is almost certainly a single, identifiable error (a PHP conflict or a fatal on the product page). A debug log will usually let me pinpoint it straight away.

Could you enable logging and send me what it records? Here’s how:

1. Edit your site’s wp-config.php file (in the WordPress root folder). Just above the line that says /* That's all, stop editing! Happy publishing. */, add these three lines:define( 'WP_DEBUG', true );define( 'WP_DEBUG_LOG', true );define( 'WP_DEBUG_DISPLAY', false );(WP_DEBUG_DISPLAY is set to false on purpose, so your visitors won’t see any error messages while the shop is live.)
2. With the Vanquish plugin active, open one of the product pages that breaks. This makes WordPress record the error.
3. Open the file wp-content/debug.log and copy me its contents (or just the last section, from the moment you loaded the page).

If the debug log shows nothing related to the plugin, the issue may be in the browser instead. In that case, please also open the broken product page, press F12 to open the browser console, and copy me any errors shown in red under the “Console” tab.

You can reply here or — if it’s easier to attach the log file — open a ticket here and attach it directly: https://vanquishplugins.com/support/

Once you’ve turned debugging on and captured the log, feel free to set those three lines back to false (or remove them).