WooCommerce: Replace “Add To Cart” with “Ask” Form for Custom Products

When you Google the phrase “replace Add to Cart WooCommerce” (or any variants thereof), there are a lot of SERP’s suggesting the same way of hiding/not displaying the Add To Cart button. The idea is to remove the “woocommerce_template_single_add_to_cart” action.

Replace “Add to Cart” for Custom Products

However, in my case, I wanted to do this for only certain specific products. I have products that are marked as “Custom”, i.e. not stocked products. These are products that can be customized as per the customer/client. They usually take 6-8 weeks from order to delivery. The idea for the landing pages for these “Custom” products is not for them to make the purchase outright, but get them to contact the store owner. This way, the process of designing the custom product can be taken offline.

How to Designate a Product as “Custom”

The first step is to identify the products as “Custom” in WooCommerce. Following this guide by Remy Corson, I added a Checkbox under the General tab in the Product Edit Screen. When this Checkbox is checked, it means that the Product is “Custom”.

"Custom" product
“Custom” product

As you can see in the image above, this product is defined as “Custom”.

Next up, we have to hook into the correct action for marking all “Custom” products as not being allowed for Purchase. We will use the is_purchaseable() hook for that purpose.

Alternative CTA for “Custom” Products

I wanted a form to take the place of the “Add To Cart” button. In my case, I use Contact Form 7 for my forms. I just added a small form specifically for the purpose of this CTA. The visitors will see this form in place of the Add to Cart button. The store owner receives an email containing the lead.

We are simply checking if the Product is “Custom”. If it is “Custom”, we will set it as being non-purchaseable. This will hide the “Add To Cart” button for such “Custom” products.

Full Code Listing

Here is the full code. Notice that 2 other custom fields were added. You do not need those, so you can easily delete the relevant lines of code.

Questions/Comments? Type away in the comments below.


WordPress: JigoShop Conflict of “From” header

Being new to WordPress, I had another challenge this week. It appeared that no matter what “name” was entered by the users on a form, the email sent (as a result of the form submission) was always “From : <Blog Name>” instead of “From : <Actual Name of User>“. In fact, all emails (regardless of plugin) would originate “From: <Blog Name>”.

Initially, I assumed the problem was simple in that the form was somehow hard coding the “From” field and it was just a matter of finding the right piece of code within the Contact Form 7 plugin and replacing it.

After 3 hours of the debug-code-test-repeat cycle, I was nowhere closer to solving the problem. I am not a WordPress guru so I was afraid of delving into the WordPress core code. So I started looking through the code for Contact Form 7 plugin. I placed debug statements (PHP error_log) on the interface between Contact Form 7 and the WordPress core code. Specifically, we are talking about the WordPress “wp_mail()” function.

You can specify headers to the “wp_mail()” function, so I verified that Contact Form 7 was sending these correctly. That meant the problem was NOT within Contact Form 7.

One thing within the WP core code confused me: how and what did the filters do? The wp_mail() function was invoking the filters ‘wp_mail_from_name‘ and ‘wp_mail_from’ before calling the core PHP API to transmit the email. Instinctively, my next step was to look for references to any such filters by any plugins. I found quite a few references to this ‘wp_mail_from_name’ filter. While all other plugins seemed to be using the filter only for their exclusive purposes, one plugin, notably JigoShop, was adopting a different route. The call to “add_filter(‘wp_mail_from_name’, ….)” was not matched by a complimentary call to “remove_filter()”.

That means the WordPress core code would always be setting the header field according to the ‘wp_mail_from_name’ function handler set by JigoShop.

Bingo, I had found the problem! Sometimes, you get so excited about finding the problem that you absorb it in all with pleasure. Its an elated feeling to have found out the answer after several hours of debugging.

A couple of days later, I still do not know what is the correct resolution to this problem. I have posted on the JigoShop forum, seeking a solution. So far, it seems a few other folks have encountered the same issue previously.

I also posted on the WordPress forum for both Contact Form 7 plugin and the JigoShop plugin. I hope to hear back from some experts on what should be the proper resolution.

If I am understanding correctly, JigoShop should only nestle calls to ‘wp_mail()’ between ‘add_filter(‘wp_mail_from_name’…)’ and ‘remove_filter(‘wp_mail_from_name’)’. This way, the JigoShop emails are still sent from the correct “From” field, while still not affecting the rest of the plugins.

Here is my post on the Contact Form 7 plugin forum at WordPress and here is my post on the JigoShop Plugin forum at WordPress. Last, here is my post on the official JigoShop forum on the site.

Update 02 August 2013

I just heard back from one of the development team members at JigoShop. The good news is that they did acknowledge the conflict. More good news is that the fix is simple, just as I had proposed above i.e. to have ‘add_filter()’ and ‘remove_filter()’ around each call to ‘wp_mail()’.

The official fix will be included in the next JigoShop release.

If you were waiting for bad news, sorry to disappoint you…there is none!