Two better error descriptions

[Nico Knoll]

Hey,

there are two error notes at the moment which happens quite often (first thing: it's not a bug in the system):

The first one is if you use something like $page->images->first()->size(300)->url and haven't uploaded an image yet and everything breaks until you upload one. I think it would be nicer to just return nothing if debug mode is off.

The second one happens if your php version is to old and sounds like this: "Parse error: parse error, unexpected T_PAAMAYIM_NEKUDOTAYIM". But you won't know that it's just you're php version is to old because of this hebrew word. Maybe you could catch this error and just show a custom "Please update your PHP version to at least 5.3.8" or something similar.

[ryan]

The first one is if you use something like $page->images->first()->size(300)->url and haven't uploaded an image yet and everything breaks until you upload one. I think it would be nicer to just return nothing if debug mode is off.

I'm not so sure about this one because that particular call without an if() statement around it to check if there are any images would be a code error that needs to be fixed. If the error were allowed to continue, the problem might never be fixed. However, if the error were to be suppressed, then it would have to do that by returning some other image. But what image should it return? That should be up to the developer, so we've actually added the option to have it return a default value (image) when no images are present, and this was added specifically for the type situation you describe, where you want image fields to always be "populated" with something even when they aren't. This was added in 2.5 and present on both stable and dev branches and visible on the Image field settings (Setup > Fields). 

The second one happens if your php version is to old and sounds like this: "Parse error: parse error, unexpected T_PAAMAYIM_NEKUDOTAYIM". But you won't know that it's just you're php version is to old because of this hebrew word. Maybe you could catch this error and just show a custom "Please update your PHP version to at least 5.3.8" or something similar.

I agree that's a crazy error message that is always a source of confusion. The installer performs all the PHP version checks, but of course if someone moves a site from one server to another and skips the installer, then they might not see the PHP version error message. I'm not sure that PW should be doing a PHP version check on every page load (or maybe it should, have to think about that one a little more). When you saw that particular error message, do you recall where it was originating from (file/line)? If I can isolate the block of code that produced the error, that would be my preference, but if not I suppose a PHP version check on every execution may be necessary. 

[LostKobrakai]

Regarding the PHP Version issue. How about a check everytime a superuser logs into the backend. Superusers are the ones who should get notified and you don't login nearly as often, as you load a page.

[Nico Knoll]

@LostKobrakai: You don't even get this far if this error happens. 

@Ryan: I think you could check if the root url changed and then run a version check. That should catch most of the cases. And I think it's already implemented somehow if you activated "Markup/HTML" with your textarea inputfields, isn't it?

[LostKobrakai]

Thought it would be an error you "randomly" get on some sites, not immediately.

[Nico Knoll]

And one more error could be that if there is a problem to connect to the database ProcessWire shouldn't only say "Error logged..." but "Unable to connect to database. Error logged..." or something like this.