bootle

Thanks for taking the time to look at it, that encouraged me to have another go at hacking the CSS in dev tools and this time succeeded.

Not entirely confident of my CSS, but it did the trick and not hackish.

As you say, looks like a theme issue.

FWIW this made the theme work well:

@media only screen and (max-width: 530px) {
.content-sidebar-wrap {
margin-left: 0;
margin-right: 0;
width: 94%;
}
}

(premium donation on its way, super thanks!)

• This reply was modified 4 years, 6 months ago by bootle.

I’ll wait for it to go core though, thanks for the heads up!

Thanks, slowly getting my head around what blocks (Gutenburg) can do ??

Excellent advice, will do that, and you’ve taken my knowledge up a notch!

Except I used CSS to make a nice background colour, in line with the theme, for the block, to make it stand out from the rest of the page. So having a separate block means more messing with CSS to make the two appear to merge. As the functionality is in the [tag] version I think it should be in both. Time to try it as a tag then…

For the plus (paid for) version, the fix is very simple. Line 2162 should be changed from:

public function calculate_shipping( $package ) {

to

public function calculate_shipping( $package = array() ) {

Thanks to Vishal above – I simply diff’d his fix to the free version, to find the change, and applied same change to the plus version. Vishal has confirmed on another thread that this is the change.

For the plus (paid for) version, the fix is very simple. Line 2162 should be changed from:

public function calculate_shipping( $package ) {

to

public function calculate_shipping( $package = array() ) {

Thanks to Vishal above – I simply diff’d his fix for the normal version vs the original version, to find the change, and applied same change to the plus version.

Thanks – the other rows were completed, so I went ahead and did the deletes as given (on local), then ran Order Search Repair and it fixed up all 1960 orders. DB shows expected new fields, and searches work for the ones it couldn’t find before.

Then backed up and migrated live to local again, and did it same on live. Worked perfectly.

A million thanks!

Super, your help is very much appreciated. Just got back home and looked at _billing_address_index

At a certain point, the data changes to contain only the users (or customer’s) full name (i.e. two, three or four words separated by spaces). Am running latest WP and WC.

Is there a simple SQL I can run that will clear/drop all _billing_address_index so your plugin can get to work?

phpmyadmin is showing for a search of meta_key _billing_address_index:

meta_id post_id meta_key meta_value

110237 4051 _billing_address_index Axxxx Mxxx Hxxx Mix Hair & Beauty 63…

113703 185 _billing_address_index Hxxx Hxxxxx

Note how the early post_id has a _billing_address_index of just two words.

Hi there! Thanks for the plugin. I found it worked and then…

I have a local setup and a live setup. First I ran it locally, it was fine, I could search for orders from 2014 that my client was complaining about. Then I used WP migrate pro (+migrate media) to copy the live site to local, and ran again. It immediately completed with zero orders processed. Strange – so I deactivated the plugin, reactivated it – no change. Uninstalled and re-installed, no change. Looked for any files hiding info, none found.

So I bit the bullet, backed up live separately, and ran the plugin on live. No orders processed, could not find the 2014 order (though definitely there).

Deactivated all plugins apart from woocommerce and order search repair (on local), no change.

All very strange, as it worked perfectly on the first thing I tried. I also used it on another woocommerce installation and it worked perfectly.

Yes, I tried many others. Finally I settled on the “official” version on the woocommerce site, i.e. https://www.woothemes.com/products/stripe/ which is relatively expensive but works with IE9 – something that was an issue for my client (unfortunately still lots of people using old browsers, especially elderly people).

On my machine, the full path is:

/home/colin/www/voakesfreefrom/wp-content/plugins/wp-find-your-nearest-premium/includes/admin_panel_FYN_options.php

Hope that helps!

Hi – the author gave this reply to the same question (from me) a few days earlier. This worked for me and he said a new version will be coming. In my case, it only affected the localhost install.

hmmm… what happens if you replace line 225 in /includes/admin_panel_FYN_options.php

require_once(‘countrycodes.php’);

with

global $countrycodes_array;

?

Works a treat!

Foxed as to how ??

Tested on remote server too, seems fine.

Seems to be fine on remote machine, but would like to setup locally first.

Came across this for the same reason – the docs clearly state th=”false” in the options tab. How about updating plugin to use either? Great plugin, use it all the time, on many sites!