regisit

Sorry, but this is quite a poor response. We are suffering the exact same issue. We have enabled caching and general product list load times (by category) are much better than trying to the WOOF filter. It’s taking 10+ seconds to find just a few products with the WOOF filter when product listing by category in general is 1-2 seconds with caching enabled.

Load all products (i.e. no category search) and first page lists in 1 second. Load a category from the menu (i.e. by url) and they load in under a second. But list all products then use WOOF filter to select a category and it’s 10+ seconds.

Further, we also have general WC Ajax product search extension. Using that to search for products produces result in 2-3 seconds compared to the 10+ seconds it takes for WOOF to load filtered results.

This is not a hosting issue but an issue with the plugin. We’ve paid for this so please don’t be so dismissive and instead assist us to find out what is wrong with your plugin.

This is most definitely a bug. Update a page and immediately it gives this message. How can the backup in my browser be different when I’ve just updated it? I’ve just updated so of course the browser backup can’t be newer!

It seems to me there’s a bug that however this is stored in the local browser is not updated when the post is updated, causing it to fail a check on the reload, even though the database copy is newer than whatever the browser is holding, because I just updated it.

It’s causing a bit of a problem because users don’t know why it randomly says this for no apparent reason. The only way to get rid of it is to restore the browser backup, because no matter how many times you update it, this message just comes back.

And no, not down to div tags or non-breaking spaces.

• This reply was modified 5 years, 11 months ago by regisit.

@barnez

Like most other posters on this topic, we’re well able to understand how to configure a contact form. What we don’t need is a plugin that has been working fine for many years suddenly telling us there’s something wrong when there isn’t.

If I want to setup a form with a From address using the name/email of the person submitting the form then that’s my choice and not something that should be unilaterally decided by the plugin developer.

But anyhow, just as a test I revised a form to use the same, hardcoded site address for to/from with the form email address as Reply to: [form-email] (just a dummy field name – this is inconsequential). Yet still the validation flags this as an error. It’s not and neither is using the form email in From. So yes, this is a false-positive.

And I think from all the comments posted it’s clear that most, apart from it appears yourself, would agree this topic (as per the subject) is not resolved.

And yes, obviously the forms still work but it’s disconcerting to have false-positive validation errors flagged up all the time.

If the CCF7 developer doesn’t want to fix these errors then at least provide the option to disable validation so those of us that disagree with the way the developer has implemented the validation rules can turn it off.

@barnez – why start a new topic when this is not resolved? Marked as resolved yes, but not actually resolved.

Whoever has the power to unresolve this topic should do it. Then perhaps the CCF7 developer will take the feedback and fix this false-positive validation error.

NP – and sorry for calling you Joren! Need my glasses!!

Hi Joren,

Problem resolved! WP needed more memory!! Spotted by YiThemes support investigating why sitemap page wouldn’t build. After increasing memory [wp-config.php – define(‘WP_MEMORY_LIMIT’, ‘256M’)] I thought I’d try enabling your plugin again – and this time it worked on the main /shop/ page.

Did decide against having an “all” option though – 600+ products listed at once is not good!!

Thanks for your support,
Adam

Hi Joren,

Before plugin was installed all working fine including main /shop/ page. I added the plugin and category pages are fine but not front /shop/ page. De-activate plugin and /shop/ works again. Activate and it stops.

Same errors as above were reported on the “white” page with just define(‘WP_DEBUG’, true) set (so it displayed errors on the front end). That is, I got the WP notifies but nothing else.

I’ve since left debug on but set to log to file only. I can’t leave errors displaying on the front end – site is now live, but log file should have everything WP is reporting.

It’s a mighty strange one – no page but no Apache, PHP or WP errors either!

Tks, Adam

Hi Jeroen,

I enabled debug when I noticed this issue. All that’s logged is some notices about theme/plugins that are still using deprecated functions or haven’t been updated for WP changes. These are logged whether your plugin is enabled or not. So no clue there I’m afraid! Also enabled PHP error logging – nothing there either.

[29-Jul-2015 08:32:38 UTC] PHP Notice:  get_settings is <strong>deprecated</strong> since version 2.1! Use get_option() instead. in /home/rit0043web/public_html/wp-includes/functions.php on line 3391
[29-Jul-2015 08:32:38 UTC] PHP Notice:  wp_enqueue_script was called <strong>incorrectly</strong>. Scripts and styles should not be registered or enqueued until the <code>wp_enqueue_scripts</code>, <code>admin_enqueue_scripts</code>, or <code>login_enqueue_scripts</code> hooks. Please see <a href="https://codex.www.ads-software.com/Debugging_in_WordPress">Debugging in WordPress</a> for more information. (This message was added in version 3.3.) in /home/rit0043web/public_html/wp-includes/functions.php on line 3560
[29-Jul-2015 08:33:02 UTC] PHP Notice:  get_settings is <strong>deprecated</strong> since version 2.1! Use get_option() instead. in /home/rit0043web/public_html/wp-includes/functions.php on line 3391
[29-Jul-2015 08:33:02 UTC] PHP Notice:  wp_enqueue_script was called <strong>incorrectly</strong>. Scripts and styles should not be registered or enqueued until the <code>wp_enqueue_scripts</code>, <code>admin_enqueue_scripts</code>, or <code>login_enqueue_scripts</code> hooks. Please see <a href="https://codex.www.ads-software.com/Debugging_in_WordPress">Debugging in WordPress</a> for more information. (This message was added in version 3.3.) in /home/rit0043web/public_html/wp-includes/functions.php on line 3560
[29-Jul-2015 08:33:04 UTC] PHP Notice:  get_settings is <strong>deprecated</strong> since version 2.1! Use get_option() instead. in /home/rit0043web/public_html/wp-includes/functions.php on line 3391
[29-Jul-2015 08:33:11 UTC] PHP Notice:  get_settings is <strong>deprecated</strong> since version 2.1! Use get_option() instead. in /home/rit0043web/public_html/wp-includes/functions.php on line 3391
[29-Jul-2015 08:33:11 UTC] PHP Notice:  wp_enqueue_script was called <strong>incorrectly</strong>. Scripts and styles should not be registered or enqueued until the <code>wp_enqueue_scripts</code>, <code>admin_enqueue_scripts</code>, or <code>login_enqueue_scripts</code> hooks. Please see <a href="https://codex.www.ads-software.com/Debugging_in_WordPress">Debugging in WordPress</a> for more information. (This message was added in version 3.3.) in /home/rit0043web/public_html/wp-includes/functions.php on line 3560

Tks, Adam

The same sites work fine in other browsers, e.g. Chrome, so it’s not an issue with the sites. I can visit the widget area on one occasion and attempts to drag a widget fail, with it instead selecting the text, on another occasion it works fine. On one site I can drag the first few widgets, but not the rest.

I haven’t seen this happen before and it only *appears* to be happening on sites upgraded to 3.4.2, which is when WP seem to have decided IE9 is no longer current.

…and dragging widgets intermittently fails to work.