tomkerswill

We’re seeing the same error on some calendars.

We’ve had issues with WP running out of memory when the calendars are enabled, so we’re wondering whether this is related…

Hi kmchow

Thanks for the message. The file the Ronald mentions is in the directory for this plugin. So the first step is to install the plugin. Then take a look at your WordPress installation using a SSH or an FTP client, and go to wp-content/plugins/woocommerce-hide-checkout-shipping-address/js

Now take a backup copy of the javascript file you find there (hide-checkout-shipping-address.js) and then edit the file to make the changes that Ronald mentions above.

If you don’t have FTP access, then you can also edit the file in the backend admin console of WordPress — but FTP is usually safer (although for a .js file it shouldn’t matter).

Tom

Perfect – that works great. I did a few modifications to target individual fields and it all works really seamlessly.

Thanks once again,

Tom

Hi Ronald,

Thanks once again for this. The code you linked to works well, but there’s a massive advantage of your plugin over this. WooCommerce doesn’t dynamically update the address field code when changing shipping method. So if the user changes shipping method on the checkout screen, the address won’t be dynamically shown or hidden at that point. The only way to really do that is to use javascript, which your code does really well. So the code above is good for static changes only; yours is better because it dynamically shows and hides the shipping fields.

If you ever do get a chance to add in support for billing fields, I think that would be absolutely great. I’ve had a look at the JS code, but it looks like it could be fairly tricky to do…

Thanks once again,

Tom

Hi Ronald,

Sorry for the delay. Ah, that’s great – thanks for the pointer! I’ll have a play…

Tom

There’s a typo in the example code, which would have caused a syntax error. The fix is to add a quote before override_address_fields:

REMOVE THIS
add_filter(‘woocommerce_default_address_fields’, override_address_fields’);

ADD THIS:
add_filter(‘woocommerce_default_address_fields’, ‘override_address_fields’);

Hi Merv,

That’s great – thanks so much!

Tom

Hi! Further to my last message — we’ve tracked it down to an issue with the shortcode syntax and the tabs are now displaying. Many thanks!

Thanks so much for the help on this so far! We’re using the following shortcode:

[listing_search search_house_category=”on” post_type=”property,rental” search_price=”on” search_bed=”on” search_bath=”off” search_car=”off” search_other=”off” search_id=”off”]

However, we’re not seeing these tabs. We’ve done a fair bit of styling, but I’ve checked the HTML and I can’t see anywhere that the tabs are being generated. Here’s the link to where we’re displaying the form:

https://79.170.44.113/amcomanagement.co.uk/

Any help appreciated!

Hi! Thanks for the help so far – just wondering if you’re able to send through an example of the shortcode that will give these tabs. The shortcode we’re using doesn’t seem to generate these tabs at all….

Thanks in advance!

Tom

Thanks – please can you let me know what shortcode parameters were used to achieve this?

On the search form we have, we don’t seem to be able to get these tabs to appear.

Also, is there a way to have these as dropdowns rather than as tabs?

Thanks

Tom

Hi Mandy,

Ah – that’s really good news!

Tom

Okay – I’ve got a workaround for making this work with regions outside the US.

This can be fixed short-term by changing line 152 in wp-amazon-web-services-master/classes/amazon-web-services.php

FROM:

$args = array(
‘key’ => $this->get_access_key_id(),
‘secret’ => $this->get_secret_access_key()
);

TO:

$args = array(
‘key’ => $this->get_access_key_id(),
‘secret’ => $this->get_secret_access_key(),
‘region’ => ‘eu-west-1’
);

… Obviously this would need to be added to the admin interface instead of being hardcode here – but adding the region in does fix the problem, and images can now be uploaded to S3.

I guess an enhancement is to either add a “region” dropdown to the admin interface, or – better still – detect the region from the chosen bucket automatically.

Tom

Ah – yes, I’ve found the bug, I think.

In the plugin, the S3 endpoint is hardcoded to:

s3.amazonaws.com/BUCKETNAME

… which is “path-style syntax”. The s3.amazonaws.com only works for US buckets. For other regions, it has to be changed – for example, for an EU bucket, it should be:

https://s3-euwest-1.amazonaws.com/BUCKETNAME

So I think that’s why it’s not working for my EU bucket.

Another alternative (which works with all regions) is to change the syntax to use endpoints like this:

wordpress-media-mywebsite.com.s3.amazonaws.com

… Which should work for all regions.

I think that, in order to work with all regions, the code needs to be updated to work with domain-type URLs like the one above.

Tom

Hi TraciBunkers

Re: CloudFront.. Yeah, not using it at the moment (might look at that later) – but you’re right, I’m pretty sure it shouldn’t matter, because the problem happens before I get to that point.

Re: the error log… Ah, good idea! I don’t know why I didn’t do that before. The error is illuminating… And I wonder if this is happening because I’m using an EU bucket, rather than the default US one? The error I get is:

Error uploading /srv/www/mywebsite/releases/20140306132721/wp-content/uploads/2014/03/Fullscreen_07_03_2014_16_29.png to S3: The bucket you are attempting to access must be addressed using the specified endpoint. Please send all future requests to this endpoint: “wordpress-media-mywebsite.com.s3.amazonaws.com”., referer: https://mywebsite.com/wordpress/wp-admin/media-new.php

I guess to delve into this further, I should try and look at the code and see what endpoint it’s trying to use… Or see whether it’ll work with a US bucket…

Tom