Dominic

Ok, after a little debugging, I saw that the new read_status column was not added to the custom table on my installs. Without that column being present, I’m guessing the DB insert operations fail.

Once I manually created the column, the plugin works again.

Maybe there’s a bug in the upgrade code that’s supposed to detect if the column needs to be created?

Thanks for the quick reply. Yeah, I was looking at the init hook as well, but it may not be necessary to change that one if you conditionally load the class. Of course, changing it shouldn’t hurt either. ??

Just wanted to say thanks to @codeforweb for the SELinux tip. That was exactly my problem.

Hi @johndcoy,

Personally, I don’t really need the Smart Button features and I currently have them disabled for this exact reason. But, from the prominent deprecation message I get the impression that the old button will be going away soon. So, I wanted to see if we could maintain this one aspect of the original button in future versions.

Thank you,
Dominic

Hi @johndcoy,

Thanks for the quick reply. Yes, that’s what I mean. Before the Smart Button transition, only the text of the button was changed. It still looked like a regular submit button integrated with the theme of the page. This was also consistent with the behavior of other payment gateways. Each gateway simply changed the text of the button to reflect what will happen when the user clicks it.

Now, the entire button is changed. I realize this can be seen as a minor thing, but the checkout page is the single page on the site that requires the most trust and confidence from the user. And, to be presented with a submit button that doesn’t match the theme of the site can jeopardize that trust.

Does that make sense?

Thank you,
Dominic

That seems like a good approach. I will keep an eye out for updates.

Hi @dmchale

Thanks for the quick reply. I’m actually using some custom permissions, so if there was a hook there, I would just hook a function that returns current_user_can('...').

Using roles could be a nice feature as well, but you might wind up having to add an admin interface for that, and it’s pretty great how short the plugin is now. Just my two cents. ??

Dominic

Just to follow up. It looks like WC()->customer data is now being populated in the current master branch on GitHub (version 1.1.3, unreleased as of now). From my initial testing, it looks like this resolves the problem on my site, but I’ll wait a bit before I say that for sure.

For reference, I believe this commit solved it.

• This reply was modified 8 years, 3 months ago by Dominic.

I’m experience this as well. I’ve been looking at the code, and I think the problem boils down to the WC()->customer address information not being set.

In my case WC()->cart->show_shipping() returns false on the order review page because I have the option to require an address for shipping set. The show_shipping() method then checks for the following information: WC()->customer->get_shipping_state() && WC()->customer->get_shipping_postcode(). Both of those function return false (leading to no shipping options being shown).

If I allow shipping without an address, I get one shipping method from my USPS shipping plugin, but no other options. I believe this is because the shipping methods have no customer information to go off of and so they return nothing. If I dump the WC()->customer variable on the review order page (where the customer is supposed to select a shipping method), all of the values in the $_data property are blank except for country which I think is just defaulting to my shop’s home country.

It appears that the PayPal Express plugin is not populating the WC()->customer object with data returned from PayPal and that’s why we’re running into this. I’m not familiar enough with the code yet to propose a solution, but I’m hoping someone who is can help.

Hi ekta,

Thanks for looking into this. You might want to take a look at the basic PayPal plugin’s implementation here:

https://github.com/woocommerce/woocommerce/blob/2.6.4/includes/gateways/paypal/includes/class-wc-gateway-paypal-request.php#L76

I am no longer able to reproduce after updating to WC 2.6.4 and PayPal 1.1.1. Thanks for following up. I guess this one resolved itself.

I dug a little deeper into this. It seems that on the default “All Orders” admin screen, WooCommerce queries for posts with the shop_order post type and one of their custom wc-* post statuses. Since, this plugin sets the post status for orders to publish the query returns no results. As a quick fix, you can run SQL like this:

UPDATE wp_posts SET post_status = 'wc-completed' WHERE post_type = 'shop_order' AND post_status = 'publish'

Thanks for the quick follow up and, as always, the excellent plugin.

Thanks for the response.

Point taken, but Jetpack is still thousands of lines of code and extremely popular. That makes it an attractive target for hackers that I don’t want on my sites. Mistakes do happen.

Hi Sam, thanks for incorporating that header check. I took a look at the latest source, and I think there might be a small formatting error.

In the PHP $_SERVER variable, the CF-Connecting-IP header is presented as $_SERVER["HTTP_CF_CONNECTING_IP"]. So the array_key_exists check won’t find it. See this SO answer.

Sorry, I should have made that more clear in my original post.