Stephen Sherrard

If you want to view this content, you need to buy any product.

If you want to view this content, you need to buy any product.

No, your understanding is not correct. Disabling payment is completely independent of shipping. There is a separate setting where you can disable shipping calculations for Wholesale Customers. Has nothing to do with whether or not payment is disabled.

The main purpose of disabling payment for Wholesale Customers was so that their orders can be treated as a “Purchase Order” where they don’t need to pay for an order until you are ready to ship, or whatever your payment terms happen to be for B2B sales. It’s quite common in B2B sales to not require payment at the time of order. The “Wholesale Pending” status was added later as an easier way for you to pick out the wholesale orders that haven’t been paid for in your list of orders. Also, that status was added since if you check the option to disable payment, the wholesale orders would be set to the “Processing” order status by default, as if payment was already completely (which it has been according to the WooCommerce logic, since no payment was required at checkout). So, the “Wholesale Pending” status was added to also bypass that default WooCommerce logic.

Also, in one of the more recent updates, the “Wholesale Pending” order status was added to the WooCommerce list of statuses where customers are allowed to pay from their “My Account” page. So, if they are not required to pay at checkout, and you enable the Wholesale Pending order status, then if they go to their My Account page and view their orders, any orders that haven’t been paid yet will have a “Pay” button next to them. Clicking that button will then take them to the checkout page where they can pay for the order with whatever payment gateway you have active (this has been tested and works with this “Pay” button even though you have payment disabled in the wholesale settings).

If you want to disable shipping for Wholesale Customers so that shipping charges are NOT automatically calculated at the first checkout (where no payment is required), that can still be done. Then you can edit the order at any time and add shipping charges manually if you prefer to do it that way for some reason. At this time, it appears that you need to change the order status to the regular “Pending”, or some other status to be able to add shipping or other charges to the order, as the “Wholesale Pending” status does not appear to allow you to edit or add any items in the order (I will look into changing that in a future update, so you can edit the order). If this is what you are trying to do, I tested it by making an order which was set to Wholesale Pending by the settings, then I edited the order, changed the status to regular “Pending”, manually entered a shipping charge, then set it back to “Wholesale Pending” (just to test). Then, when I went to the My Account page and click on the “Pay” button for that order, the shipping charge I manually entered was still there (even though shipping is still disabled in the wholesale settings). So, you can do things this way if you want, or you can have shipping automatically calculated but still bypass payment at the original order checkout. Either way works fine.

Sorry, yes, I updated that field to the 300 size after you original post, and did not see the follow up post you had where you had changed it to 500 before I released the update.

This can already by done, although in a bit of an indirect way. Many people are already using the item details field for things like this. When setting up tasks, check the “Details Needed?” checkbox, leave the “Details Required?” box un-checked if you don’t want to force them to enter something, and then change the “Details Text” to whatever you want, such as “Comments” in your case.

The last update also increased the size of the database table field that stores that field from the signup forms since other people have been using it to collect more than just simple item details.

Bumped up to Varchar(300) in version 2.0.3
Posted form fields will also have slashes stripped when redisplayed after error.

If you want to view this content, you need to buy any product.

Thanks for reporting the issues.

Regarding #1, the database tables are set up during activation, using the WordPress dbDelta command, so it will only modify the tables if it detects a change from what is in my code versus the existing table format. Not sure if it will downgrade back to a smaller varchar size or not without testing. I know that I have increased the size of some fields in the past, and it has detected that change and updated the tables accordingly, but I haven’t tried going back the other way (making fields smaller).

Those fields were never intended for storing large amounts of text when I first programmed it, since they were mostly used for school staff lunches to indicate a specific dish the volunteer was providing. I could probably bump up the size to what you have it set to in the next release without negatively affecting any current installs.

#2 is easy enough to fix with stripslashes. Thanks for the heads up on that.