trident60

What data are you talking about – and how to delete it?

I upgraded to 3.4 – no change.

There is no index data to delete as it shows zero documents in the index:

A total of 0 documents are currently in your index
0 document(s) remain to be indexed

Hello,
Did you ever find a solution to this problem? I’m having a similar issue – no matter what I do I can’t delete an existing index.

When I manually delete the index, through Solr, create a new index, reinstall the plugin, reboot, etc…, WPSolr shows 0 documents in index, 0 documents to be indexed – even though I have 80K documents.

Also can’t display facets – do you have that problem too? ??

Rob

I spoke too soon…lol

It worked on my test server but not my production server.

Which is very strange since the test server was built from an image of the production server and is virtually the same exact thing.

Back to downgrading WordPress it seems.

Just FYI – if anyone else is having this problem – there is a workaround that can be done easily by just commenting out a line in a template file – here is the original post with that fix – and despite it’s title this issue is not just a Woocommerce issue – it’s a WP issue – and I know that because I’m not running Woocommerce – or any type of commerce package – just a barebones blog.

https://www.ads-software.com/support/topic/woocommerce-extremely-slow-after-wordpress-42-update?replies=41

Just scroll down to Doug’s solution, on the first page, and it worked perfectly for me. It is a temporary as it does disable the custom fields dropdown menu…but that’s a lot easier to live with than not being able to create new posts and pages and use your plugin administration!

Hi Lorro,

Just wanted to post this workaround that was in that other thread you posted for me.

This issue is definitely impacting many people and, despite what many say, this is not soley a Woocommerce issue.

So if anyone else out there is having this issue with WP 4.2.2 this is a “workaround”, and be aware that you are editing a WP core file (just commenting out a line – but I would download a copy of the original file prior to editing – just to be safe). I’ll just post this info from the other post:

There still may be some tie into WooCommerce, though. That query is used for the custom fields metabox. It populates the Name dropdown menu for when you add a new custom field. On my site I’m seeing a bunch of WC SKUs in that menu, which I didn’t expect. They are all in the form of [SKU: 12345]. So maybe a site with a lot of products would be affected more.

There has been some recent trac ticket activity regarding this issue. #32361 was closed as a duplicate of #24498, which has been hanging around for a couple years.

Each of those tickets have different solutions. I tried both and they significantly reduce the load time for me. However, the one in #24498 eliminates the dropdown menu completely, so there may be problems with it.

If you don’t care about that menu for adding a custom field, you can remove the database query completely and speed things up. Normally, you wouldn’t want to be editing WordPress core files, but this is just for a temporary workaround and testing purposes. All you have to do is comment out line 680 of /wp-admin/includes/template.php, like this.

//$keys = $wpdb->get_col( $wpdb->prepare( $sql, $wpdb->esc_like( ‘_’ ) . ‘%’, $limit ) );

@doug Smith
@mike Jolley

Doug! How did you ever come up with that solution? It works for me too. I couldn’t even create a new post, page, have the admin operations of my plugins were so slow I wasn’t even able to work with them.

I use that workaround you came up – comment out line 680 in /wp-admin/includes/template.php – and now the plugins are all “normal” speed – being very fast. The other things – add new page/post – are usable but still slow. They went from 70-100 seconds down to 10-20 seconds.

I have no Woo installed at all. Nothing Woo, I’d removed all my plugins, and nothing had an impact. Fairly certain this is a WP issue – do you know if it’s being worked on by anyone at WP as it is not related to just Woocommerce.

Thanks Doug – lifesaver man!
Rob

Yes – that was it!

Thank you again for your quick reply!

Rob

Hi Lorro – nope, nothing wrong with the data or the db. It’s just how big it is…2.3 million rows, 225K images, 525mB of postmeta data mainly because I have many custom fields. And, this wasn’t built over time, this database came directly from Google – it’s very clean and it’s been optimized.

Like I said, it was running fine for a long time with no issues at all…at one point it was even 50% bigger. And the front end works perfectly. I’ve put the db on a fresh install of 3.9 and it works fine.

But thanks for that thread – I just posted on there as well!

Rob

Hey Everyone,
Actually, I’m having the same problem and I don’t use Woocommerce…I don’t even run an e-commerce site.

Here my original post –
https://www.ads-software.com/support/topic/wp-backend-is-very-slow-almost-non-functioning?replies=4#post-7039460

– and it started with 4.2, not 4.1, I have a mirror running fine on 4.1. I’ve removed every single plugin, exported the db and installed on an older version of WP and it works fine.

Does anyone know if WP is aware of this – working on it? It seems pretty widespread.

Rob

Hey Lorro,

Thanks for the tip!

I hadn’t actually checked the size…but, while it’s pretty hefty at 1GB, it’s all my posts. And I’m running MariaDB – which is blazingly fast compared to Mysql – and I wasn’t having this problem a month ago.

Just FYI for anybody else that might have an idea…I took a server image from 5 weeks ago, created a new VM with it, and it worked fine – until the WordPress updates. So for those that say the updates are not the cause…;)

Hmmm….okay…that’s what I was hoping for…

But ??

I’m not seeing any difference in search time results. When I query MySQL it’s very slow – about 60-75 seconds. When I use the search widget with the Indexer running and everything re-indexed, it still takes the same amount of time.

Any ideas why?

It should be about about .5-1 second – that’s the speed when I query the Elastic server (it’s also what I was getting with Solr) so it’s almost as if the plugin is being bypassed somehow.

Thanks!

Hello, thank you – I installed and indexed with no problem.

Just to be clear, this plugin is just for creating an index – it doesn’t replace WP-Query, correct? So I still need a way to actually access and search the index?

Hello,

I updated, edited the facet options by selecting only categories, tags, and two custom fields.

Again, only the “tags” displayed right under “ALL”.

It almost seems as if “ALL” is hard-coded and that’s why nothing else, but “tags”, is showing.

Getting these errors in my Apache log…

[Thu Jun 04 03:22:23.603570 2015] [:error] [pid 30700] [client xx.xx.xx.xx:60240] PHP Warning: Invalid argument supplied for foreach() in /var/www/html/wp-content/plugins/wpsolr-search-engine/class-wp-solr.php on line 341, referer: https://healthitlink.com/category/fitness-home-use/android/free-android/calculate-monitor/

[04/Jun/2015:19:01:19 +0000] "GET /wp-content/plugins/wpsolr-search-engine/css/style.css?ver=4.2.2 HTTP/1.1" 304 258 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +https://www.google.com/bot.html)"

66.249.65.65 - - [04/Jun/2015:19:01:27 +0000] "GET /wp-content/plugins/wpsolr-search-engine/css/bootstrap.min.css?ver=4.2.2 HTTP/1.1" 304 259 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +https://www.google.com/bot.html)"