plugger2

And should have said: WordPress is 4.1

Well, to be fair, you should at least try to describe what aspect you thought was HORRIBLE! Otherwise, your “review” is pretty much worthless.

Also, before telling everyone “Nobody buy this product!”, since it does come with a satisfaction guarantee, it might be fairer to see how your guarantee claim goes, and if it is as expected, then people have little to lose trying the products out for themselves, and see if they also think it is HORRIBLE!

Yes?

Keep us updated. We are all interested in informed views. But the information to typing quotient in your post so far is HORRIBLE! LOL.

I’m surprised no one from woo has picked up on this — do they actively monitor this channel very much? It may be a bug in just the theme I’m using, or actually part of woocommerce, but in any case, it is both reproducible in Firefox 21.0 and IE10, so whatever it is it isn’t browser specific.

I’ve just cleaned my hacked version up a bit and now it plays nicely with a (non-hacked) version of BWS Captcha. I had to revert the filename and directory names as contact_form.php and contact-form-plugin respectively. (I had changed these to be bws_contact_form.php and bws-contact-form-plugin, but BWS Captcha couldn’t find these without being modified itself.)

All working quite nicely! Just tested the attachment feature, no problems.

The only other custom modification I did was to prepend an identifying text string “[mydomain.com] ” before the contact message subject string, so I can easily see it came from the contact form and site when it hits my inbox. This might also be a useful future option to be rolled into an official release (the prepend string is just hard-coded in the php file the way I’ve done it… have to redo it with every upgrade.)

Anyway, it would be good to get the shortcode conflict with woocommerce resolved. [woo_contact_form] and [bws_contact_form] would be much better ideas all around.

Actually, I just experimented with hacking the bws contact form to change the shortcode to [bws_contact_form], and yes, the conflict is now resolved — it’s working properly.

I had to change the captcha.php as well to work with the hacked contact form plugin, but (hacked) captcha works with (hacked) contact-forms-plugin.

What I did was pretty quick and dirty (mostly global search and replace). Perhaps the author might consider doing a proper fix to resolve the conflict?

Sounds very plausible. I wonder if there is a simple way to change the shortcode for this plugin to, say, bws_contact_form. (It would be better branding, anyway.)

Thanks for helping to track this one down.

I’m having exactly the same issues. I’m wondering whether another plug-in is causing a conflict? I’m using woocommerce, with the resort theme, and the jetpack is installed (although I’ve disabled the jetpack contact forms, but to no effect, AFAICT.)

Update on “inactive product sort listbox” bug: The bug doesn’t show in IE10, but it does in Firefox 21.0 (Windows 7 x64).

It does seem to be a bug specific to the “resort” theme; as a test I tried clicking on “shop” in the “canvas” demo, and the product sort list box worked OK under Firefox 21.0.

Which is all I’m going to say about that bug. Now how can I simply make the (sometimes) problematic product sort listbox go away entirely? As I mentioned above, I tried inserting

remove_action( ‘woocommerce_pagination’, ‘woocommerce_catalog_ordering’, 20 );

into

public_html/wp-content/themes/resort/functions.php

but to no effect…

The woothemes product add-ons extension I was looking at was only released about a week ago:

https://www.woothemes.com/products/product-add-ons/

whereas the gravity forms extension was released in Dec 2011:

https://www.woothemes.com/products/gravity-forms-add-ons/

Perhaps you are using of a different woothemes plugin or extension? When were you using it?

BTW, anyone know why woothemes decided to bring out their own product add-ons extension after they had already written the product add-ons plugin for the gravity forms? Is the new woothemes extension faster (if less powerful) than the gravity forms solution? (If so, I might be interested in checking it out.)

Interestingly, the list box gets “unstuck” when the responsive theme (“resort”) detects the screen width to be too small to display the menu, and it shows the menu button instead. Then the list box is usable. But when the screen width is increased back to “full display” mode, the list box goes inactive again. So that aspect may be actually be a bug in the “resort” theme.

Edit: Actually, this bug is evident even in the “resort” demo page

https://demo2.woothemes.com/?name=resort

so I think that nails that as a theme bug!

I’d still like to be able to make the product sort list box go away though… I really don’t have enough products to justify, and it’s potentially a bit annoying since it doesn’t work as it should all the time anyway.

Also tried it in

public_html/wp-content/themes/resort/functions.php

in case that’s actually where you meant, but also to no avail. (Pasted it into the “custom functions” section, just before “the sky will fall in” msg.)

I’m using gravity forms + gravity forms product add-ons, which works OK, my only reservation is that it seems a bit s-l-o-w to update a price when an add-on option is selected or unselected for a product on the product page. You see a spinning “hourglass” icon appear for a few seconds while it is thinking about how much $3 + $2 is (!), and it kind of worries me that under load this might bog a system right down that is not on high-end dedicated hosting. Have to try it out and see, I guess.

I appended this line of code to the file:

public_html/wp-content/themes/resort/includes/theme-functions.php

after all the function definitions but just before the “end of file” comment, but the sorting drop down list box persists. The list box is also stuck at “Default sorting” — I can’t change the selection.

I’m using woocommerce 2.0.10, “resort” theme. Should this still work with this version, or is there a different fix?

Also, I might mention that on the order received “thankyou” page, the cart indicator in the menu is still showing the number of items in the cart as the number of items just paid for, rather than zero. Which is also incorrect of course, but is consistent with the items still showing in the widget sidebar cart display.