thowden

Hi,

Similar issue for me. Installed this plugin, activated. Latest WooCommerce and all up to date. WP 6.6.1 with back-end at Flywheel. So it should not be a WP or server issue.

Select Add a Supplier and enter data, hit Submit and get a 404 page not found error. Supplier is not saved.

Try looking at Inventory page and I get the “There has been a critical error on this website. Please check your site admin email inbox for instructions.” …..

The plugin sounds like it would be very useful, but this is just time wasting.

Tony

Hi,

Same.

Test process. Use the Export option to export a single Product.

Without changing anything in that file, try to Import it and get the invalid file message.

No need to provide a test file, you have one in your own setup.

I spent a good 4 hours this afternoon, trying lots of options relating to the content of my invalid import which worked fine last week.

I have tried 3 computers / browsers, etc. just to make sure it was not something in my setup.

Tony

Updated to latest version. Tried it but then realised that the default settings I had for order by SKU were removed. Resetting to use SKU order is working as expected with 5 pages in the correct sequence.

Thanks for the prompt fix.

Extra Info:

Bulky Filter -> Settings set/saved to Sort by SKU.

Selecting the SKU column in the filtered list switches ASC/DESC but only for the 20 lines of that page not the 7 pages of the filtered list.

Filter list has a single keyword in the Title field.

Hi Keith

Thanks, it confirms that it was a server-side issue rather than within the WP site itself.

In a browser inspect console I could see a 403 error on wp-admin/loadstyles.php.

The solution for me was reviewing the CPanel WordPress Toolkit for the specific site and re-running / recycling (disable / re-enable) all the settings. It appears that the security settings via WordPress Toolkit were corrupted in some way.

cheers
Tony

Hi

Came across this post as I have the same issue as the OP. I tried with wp-cli as a last resort, but as with the OP the core_updater.lock entry is NOT in the wp_options table.

Using wp-cli as suggested here and elsewhere fails:

wp option get core_updater.lock
Error: Could not get ‘core_updater.lock’ option. Does it exist?

I am still looking for a solution or to identify the issue. The one thing I do know is that the common fix relating to the core_updater.lock is not the answer.

What have I tested ? Check my blog post wordpress-another-update-is-currently-in-progress and if I do find an answer I’ll update it here too.

cheers
Tony

Hi All

Found it!

Our MainWP system is behind a firewall. I was adding the public IP address for the MainWP dashboard server, but the MainWP outbound IP was presenting to the MainWP Child site as the firewall external IP address, which Bad Behavior detected as a hack attempt.

Adding the firewall IP to the BB whitelist allows it to work.

cheers
Tony

Hi

Just agreeing with this comment. Still trying to work out why.

BB has a whitelist option which we have set to theoretically allow the MainWP Dashboard IP address to access the MainWP Child site, but with BB activated there is no connection. Disable BB and it all works as expected.

Hi

It would be more polite if the message went away when clicking Dismiss, given that is the purpose of the Dismiss option.

Ok, finally working. The last piece of this puzzle was the open_basedir setting in my server. This restricts cURL
PHP Warning: curl_setopt() [<a href='function.curl-setopt'>function.curl-setopt</a>]: CURLOPT_FOLLOWLOCATION cannot be activated when in safe_mode or an open_basedir is set in absolute_path/wp-content/plugins/g3client/client.php on line 72
This was showing as an error in the G3Client settings page as
Could not connect to Gallery3: Found (http status code: 302)
I was able to modify the httpd.conf for Apache and that allows the cURL option to work for this plugin.
Not sure what you would do without httpd access and restrictive practices of some host providers where open_basedir is not optional.

Hi

Ok, I think I have this fixed.

cURL is installed and working, but due to an oversight in my dns setup my test box did not know the alias that I was using for the site.

Testing cURL at the command line made it obvious.
# curl -v https://devsites.mydomain/mysite/gallery/index.php
results in

* getaddrinfo(3) failed for devsites.mydomain:80
* Couldn't resolve host 'devsites.mydomain'
* Closing connection #0
curl: (6) Couldn't resolve host 'devsites.mydomain'

adding the correct host entry to the local server dns resolved this issue and provided the correct responses.
Now for the next issue….

I have the same error with connecting to menalto Gallery 3.

Could not connect to Gallery3: failed to connect to Gallery3 (http status code: 0)

The URL is correct as I can test it directly within Firefox
https://devsite.mydomain/gallery/index.php/rest/

I can access and get an XML response that appears complete if I try to access as per the test instructions from the Gallery Wiki on Browsing Rest

I’ve used the Guest account (setting guest rest enable to 1) and I created another user called ‘rest’ and tried with that Rest Key as well.

<digress>I am getting a CURL error in the log
PHP Warning: curl_setopt() [<a href='function.curl-setopt'>function.curl-setopt</a>]: CURLOPT_FOLLOWLOCATION cannot be activated when in safe_mode or an open_basedir is set in absolute_path/wp-content/plugins/g3client/client.php on line 72

But I think this is a separate issue. I can change the setting on line 72 from True to False and while that stops the CURL error there is no change in the ‘Could not connect’ message. I expect that this CURL function is only required for Gallery sites that are remote to the WP site but would appreciate a confirmation.</digress>

I have also tried the Gallery 3 WordPress Plugin from Heiv but I get the same error. Which suggests that it is not a plugin issue as much as a server config issue, but where to look?

Any help appreciated. I am using WP 3.1.2 Network config on Linux.

cheers
Tony

Damn, but that was a long-winded process.

googling for this error ends up with a mountain of irrelevant threads, inconclusive discussion, and unanswered questions.

The issue is that the prompt for the username and password that should happen automagically cannot occur due to the rewrite rules.

The rewrite rules are to look for a valid directory or file and if it is not a valid directory or file then redirect to the index.php which is what happens as the htpasswd AuthConfig process is not a valid file or directory <digress>(apparently – umm, so what is it? like is there another rewrite rule that would avoid this? obscure Apache voodoo)</digress>

The fix is to create a valid file as an ErrorDocument directive for a 401 or 403 error (Authorisation errors) and have this at the top of the .htaccess file so that Apache will return a valid file flag and therefore allow the AuthConfig prompt to occur.

Edit your top level .htaccess above the section for #Rewrite for WordPress

ErrorDocument 401 /myerror.html
ErrorDocument 403 /myerror.html

if you dont want to put this dummy file in your site root then add the path to the filename

ErrorDocument 401 /[path_to_file]/myerror.html
ErrorDocument 403 /[path_to_file]/myerror.html

Then just create an empty file with that name in the appropriate path.

The references that I used were:
https://www.scratch99.com/2008/10/password-protecting-the-wp-admin-folder/
https://developedtraffic.com/2007/05/27/wordpress-admin-password-protection-404/
https://textpattern.com/faq/173/password-protected-directories-with-htaccess
https://www.ju-ju.com/2006/03/17/wordpress-404-error

I’ve also put a more structured answer in my blog.
https://howden.net.au/thowden/2011/03/wordpress-404-error-password-admin-directory/

Sub folder.

The order does not appear to make any difference.

The rewrite rules are in the root dir .htaccess while the password check is in it’s own file in wp-admin sub dir.

If I do the password setup manually the same thing occurs.