More PHP Errors

These are actually just warnings, not errors. But they may well indicate a problem.
I see two issues here:

1. The “assert” statements are mainly used for debugging, and should not be active on a live site. Something in your setup seems to be setting the PHP environment variable ASSERT_ACTIVE to true, even though EntryWizard sets it to false.

2. The code is finding unexpected values for some PHP variables like upload_max_filesize and post_max_size.

Do you have a .htaccess file that could be setting some of these variables? If you have no idea what that is, you may need help from your hosting company.

Does the plugin actually work, despite the warnings? If it does, do some careful checking on how uploads of large files and large numbers of files is handled. If there is nothing breaking there, you may be able to ignore the warnings, although having asserts executing in a live environment is likely to slow things down a bit.

Thanks for the prompt reply.

I’ll have a look round now I know what I’m looking for and get back with any findings.

OK, I’ve spent some time trying to bottom this.

It turns out that the only significant difference between my test server version (which works) and my hosted version is that the configuration variables max_file_uploads, upload_max_filesize and post_max_size are all specified in a format like 25M whereas on my hosted system they are specified in bytes (both seem to be legal and are strings).

As I read it (and I’m no PHP coder) when you parse them in ewz_to_mb you split $sizestring into the leading numeric part and the trailing text part. When you feed in a string containing only numbers, the $mat array has undefined content (I guess), hence the error.

I have tested this by changing my php.ini to the ’25M’ format and the error goes away. Maybe the majority of hosts use this format so the problem hasn’t popped up?

So the error is cured for me now, still can’t track down what is turning the Assert statements on, doesn’t seem to be php.ini or htacceess butI’ll continue looking.

Thanks very much indeed for taking the time to check this out.

1. On careful examination of the wp loading order, I see that I unintentionally ended up calling the maxnum… code BEFORE assert checking is disabled.

2. I assumed the .ini values were in their default format.

I’ll try to fix both issues for the next release.