michael.orlitzky

v7.4.28 at the moment

I think it’s a result of define('FS_METHOD', 'direct'); in wp-config.php. I commented out a call to request_filesystem_credentials() in classes/class-ip-location-block-file.php and after that, I can activate the plugin.

(NB: the database download still doesn’t work after that, but I was able to move the database into the expected location manually. The “Settings” page still can’t see the database I put there, but if I try to look up my own IP address, it does work.)

Version 2.9.8. It was installed a long time ago and has been upgraded several times. I’ll send the system info via the contact form.

@dangoodman I suppose you aren’t able to hook into the form and prevent the user from leaving one of the dimensions blank?

I agree that a dimension of zero is nonsense for a physical object, but a PHP warning is alerting the wrong person. In our case, the warning is seen by the system administrator, while the person who entered the dimensions into the website is just one customer of many and is not notified at all.

Ultimately I think the plugin is defaulting to zero when the field is blank. As a result, I rank the possible solutions (best first)…

(1) Don’t let the user leave the field blank
(2) Let the user leave the field blank, and change it to zero explicitly
in the code so no warning is thrown.
(3) Leave everything as-is

I realize that in some cases, with everything the way it is, the PHP warning will find its way to the right person. So in those cases it may help… but I nevertheless don’t think it’s a good design decision to explicitly allow something (blank fields) and then raise warnings about it later.

We have this same problem. Since the “edit product” form allows the individual dimensions to be empty, would it be possible to have the plugin explicitly convert the empty string to (integer/float) zero? That would eliminate this warning.

I’m not sure why it’s failing to get the setting (I have the same problem), but I think part of the issue is that get_settings() can return the empty string as a last resort; whereas the should_load_* functions are expecting a null if get_settings() fails.

The new version looks good, thank you!