docfx

Sorry for the (covid) delay in responding. The issue specifically seems to center around sensei certificates.

It appears that various components for producing a dynamic certificate once a student has completed a course are coded such as to be using an server path ( /home/wpcontent/uploads/year/mo/cert.jpg ) vs a url path ( https://domain/wpcontent/uploads/year/mo/cert.jpg ).

When using aws as a external large file storage all upload files are moved out of local uploads to aws s3 storage. Url Domain requests for media files are redirected to aws but not so server paths, so reqsts to view certificates fail hard.

With thousands of students uploading their inprogress work (often 5-10 images per specific lesson) storage becomes a premium, so paying $0.04/gb for virtually unltd terabytes of space (aws) vs $0.50/gb for ltd (local server) hd space becomes germane – especially as more students come on board.

I don’t believe it to be a ADVANCED WOO SEARCH plugin issue at all. We have an enterprise server w/ multiple site installs at WPE. We’re seeing this SAME issue but we do NOT have AWS installed at all. We’re simply using a search form w/ two input fields – one to set up search and two to restrict to post type=product.

WITHOUT the 2nd parameter, if item can’t be found, it sez so w/ a item not found page. WITH the 2nd restriction, if it cant find a product w/ that name, description or tag, it immediately gets a WPE 502 ‘processs taking too long’ error. WPE is saying its accessing memory it shouldn’t and creating a segfault. They’ve suggested a plugin conflict, but this is NOT AWS, not any plugin, just a simple search form. One that degrades/fails acceptably W/O the 2nd parameter, but is getting hijacked by WPE’s rogue application security routines when the 2nd parameter is deployed.

I haven’t found a fix yet either.

Prior to upgrading a client site to woocommerce 3.0, SEARCH ORDERS worked wile SEARCH EVERYTHING active. AFTER upgrade search orders went to hell. Not only did it return ZERO results, it actually was generating a mySQL query error similar to…

WordPress database error: [You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ‘))) AND ( ( wp_postmeta.meta_key = ‘_customer_user’ AND wp_postmeta.meta_val’ at line 1]
SELECT SQL_CALC_FOUND_ROWS wp_posts.ID FROM wp_posts INNER JOIN wp_postmeta ON ( wp_posts.ID = wp_postmeta.post_id ) WHERE 1=1 AND ((())) AND ( ( wp_postmeta.meta_key = ‘_customer_user’ AND wp_postmeta.meta_value = ‘4’ ) ) AND wp_posts.post_type = ‘shop_order’ AND ((wp_posts.post_status = ‘wc-pending’ OR wp_posts.post_status = ‘wc-processing’ OR wp_posts.post_status = ‘wc-on-hold’ OR wp_posts.post_status = ‘wc-completed’ OR wp_posts.post_status = ‘wc-cancelled’ OR wp_posts.post_status = ‘wc-refunded’ OR wp_posts.post_status = ‘wc-failed’ OR wp_posts.post_status = ‘wc-credit-release’ OR wp_posts.post_status = ‘wc-credit-hold’ OR wp_posts.post_status = ‘wc-export-error’ OR wp_posts.post_status = ‘wc-shipping’ OR wp_posts.post_status = ‘wc-back-order’)) GROUP BY wp_posts.ID ORDER BY wp_posts.post_date DESC LIMIT 0, 20

Painstakingly, we de-activated/re-activated every plugin individually and SEARCH EVERYTHING v8.1.9 appears to be creating the conflict in the woo v3.0.1 search order function, (config: WP v 4.6.4, php v5.6.30 and mysql v5.6.35).

regards
DocFX

Thank you for the quick fix. Have installed v 1.4 and it appears to be now logging both methods of login correctly.

We recently upgraded two of our myriad of client sites from 3.9.x to 4.2.x and both admin panels slowed to a crawl. Both are multi-sites – one w/ 50 subsites and 1 w/ only 2 subsites. The 50+ site also had Kstats, but the smaller multisite has woocommerce installed. First thing we did was to remove Kstats – no change. Next, we tried @doug Smith’s fix to comment out the $keys = line in the wp core template.php – little to no change. So, we next tried @tibzoy’s fix to modify the query line just above @doug Smith’s fix – some improvement – yea! BUT only on some of the 50+ multi-sites – hrmmm.

We had previously spawned a new test 51st subsite, but it was flagged as unable to be network updated when we did the post upgrade network update.

So we installed @mike Jolly’s suggested query monitor plug-in. Of the numerous slow sites in the 50+ multisite, query was indicating an extremely long lag while attempting to run upgrade.php for that particular subsite.

This, although the network update had indicated that ALL the sites had been updated post upgrade to 4.2.2. We then ran a manual upgrade on the new test site – it sped up substantially in admin. Then for each subsite appearing slow, we ran a manual upgrade.php for each – each sped up in the admin side.

We moved over to the woocommerce 2-site multi-site, made the same core file changes – again no change in admin speed. Again we manually updated both subsites (again even though the network update said it had previously worked) and both subsites returned to normal admin speed. This may mirror what @jstensved had to say earlier.

At any rate, I thought I’d share our efforts in speeding the admin side of the most recent two upgrades.