ollycross

Thirding this. I have also submitted a support ticket.

The error:
Deprecated: Unparenthesized 'a ? b : c ? d : e' is deprecated. Use either '(a ? b : c) ? d : e' or 'a ? b : (c ? d : e)' in /var/www/html/assets/plugins/caldera-forms/classes/core.php on line 3732

The offending code:

$entry_id = !empty($wp_query->query_vars[ 'cf_entry' ]) ? $wp_query->query_vars[ 'cf_entry' ] : isset($_GET, $_GET[ 'entry' ]) && absint($_GET[ 'entry' ]) ? $_GET[ 'entry' ] : null;

The fixed code:

$entry_id = !empty($wp_query->query_vars[ 'cf_entry' ]) ? $wp_query->query_vars[ 'cf_entry' ] : (isset($_GET, $_GET[ 'entry' ]) && absint($_GET[ 'entry' ]) ? $_GET[ 'entry' ] : null);

• This reply was modified 4 years, 6 months ago by ollycross.

Hey Paul, can confirm this is fixed using Shield 9.

Nice work!

Cheers Paul

Hey every little helps, right? That would be great!

Thank you again for your help!

Reading around the issue, the offending code has been patched in V1.42.3; the 1.x releases are compatible back to php 5.5.

Maybe it would be possible to update to the latest 1.x release, until such a time as Shield 10 is released?

https://github.com/twigphp/Twig/commit/d0550b7a68d44551e3cae0aae5a6cf9180aec37e

https://github.com/twigphp/Twig/commits/v1.42.3

I understand, 5.4 support is becoming more and more of an issue across a lot of projects.

We suppress all errors on production, but I’d prefer not to do this in development as it might mask issues in our own code, or those of direct dependencies that we can update. This deprecation is particularly problematic as it seems to be triggered every single time a template is called. On a site which makes heavy use of templates this makes the amount of noise unworkable.

Anyway, thank you for coming back to me. I’ll see if I can set up some kind of selective error suppression until such a time that it can be fixed upstream.

I was seeing this issue as well, since update to v14.0.

It seems I had DB_COLLATION (incorrectly) set to utf8 in my wp-config.php. 14.0 includes a DB migration which explicitly sets collation on the Yoast tables, so the incorrect collation entry was causing this to throw an error.

The error message is a little unclear as to what has actually gone wrong, as it implies a table creation error.

I removed the constant and allowed WP to use it’s default collation, which seems to have worked fine. I guess I could also have explicitly set it to utf8_general_ci / utf8mb4_unicode_ci.

If you are having this problem, and you know that your DB user has permission to create / edit tables (if you managed to install WP in the first place this is probably the case), check your wp-config.php file to see if you have a DB_COLLATION constant set.

– If set, try removing it.
– If not set, try adding one, either:
— define('DB_COLLATION', 'utf8_general_ci');
— define('DB_COLLATION', 'utf8mb4_unicode_ci');
Depending on your version of MySQL / WordPress.

Ah yeah I see your point, fair enough. Oh well, thank you for coming back to me. Keep up the good work!

v20200407.0.0 ??

Thank you!

That’s great, thank you for the speedy help!

Olly

Hi Mary Anne,
Yes they are appearing again now.
The response headers from the Cloudfront server which was serving the fonts now contain – maybe this was this issue? I don’t think they were there yesterday.

Access-Control-Allow-Methods:GET, HEAD
Access-Control-Allow-Origin:*
Access-Control-Expose-Headers:ETag
Access-Control-Max-Age:2000

Either way, fixed now!

Cheers,
Olly

HI Mary Anne,

I am also seeing this problem with Chrome 44.0.2403.125, but not Firefox 39.0 or Safari 10.10.4 on the same computer.

The developer console in Chrome suggests that it is a CORS issue – I get this message in the browser console:

Font from origin ‘https://dsms0mj1bbhn4.cloudfront.net’ has been blocked from loading by Cross-Origin Resource Sharing policy: No ‘Access-Control-Allow-Origin’ header is present on the requested resource. Origin ‘https://newsandviews.zurich.co.uk’ is therefore not allowed access.

Cheers,
Olly