2.0.4 breaks compatibility with php 5.6

  • Boldair Développement

    (@boldairdeveloppement)


    3 years ago

    Hello,in a recent update in 2.0;4 the use of the null coalescing operator breaks compatibility with php 5.6 (and breaks the site incidentally)

    I have a bunch of sites living on a server that is stuck in an old php version, 5.6, the sites can’t be migrated elsewhere because my customer is contractually forced to use their company internal hosting provider. And the company internal hosting provider is not upgrading php versions on this server (flats out refuses to. Yeah I know, we’ve all had to face stupid corporate IT but i assure you this one is near the op of the moronic category).

    Nonetheless, the problem lies in /wp-content/themes/oceanwp/inc/third/class-gutenberg.php on line 313 to 318 :
    the code that breaks is this :

    $headings = get_theme_mod('headings_typography')['color'] ??  $default_color;
$post_title =  get_theme_mod('blog_post_title_typography')['color'] ?? $default_color;
$heading_h1  = get_theme_mod('heading_h1_typography')['color'] ?? $default_color;
$heading_h2  = get_theme_mod('heading_h2_typography')['color'] ?? $default_color;
$heading_h3  = get_theme_mod('heading_h3_typography')['color'] ?? $default_color;
$heading_h4  = get_theme_mod('heading_h4_typography')['color'] ?? $default_color;

    the ?? ioperator only appeared in php 7.0

    replacing those lines with this :

    $headings    = isset(get_theme_mod('headings_typography')['color']) ? get_theme_mod('headings_typography')['color']  :  $default_color;
                $post_title  = isset(get_theme_mod('blog_post_title_typography')['color']) ? get_theme_mod('blog_post_title_typography')['color']  :  $default_color;
                $heading_h1  = isset(get_theme_mod('heading_h1_typography')['color']) ? get_theme_mod('heading_h1_typography')['color']  :  $default_color;
                $heading_h2  = isset(get_theme_mod('heading_h2_typography')['color']) ? get_theme_mod('heading_h2_typography')['color']  :  $default_color;
                $heading_h3  = isset(get_theme_mod('heading_h3_typography')['color']) ? get_theme_mod('heading_h3_typography')['color']  :  $default_color;
                $heading_h4  = isset(get_theme_mod('heading_h4_typography')['color']) ? get_theme_mod('heading_h4_typography')['color']  :  $default_color;
                $heading_tag = get_theme_mod('ocean_single_post_heading_tag', 'h2');

    Fixes the problem.

    The Worpress core itself is supposed to work with legacy environment from php 5.6.20+
    (see https://make.wordpress.org/hosting/handbook/handbook/server-environment/#php) although of course they strongly advise against it. In any case I’m quite stuck here, i’ve got about 9 sites on this server all running with OceanWP theme.

    For now I’ve reverted the change with the code above and disabled automatic themes updates (but I really don’t like to keep old version, i try to jkeep the sites theme and plugins up to date even though I can’t do anythin about the PHP version)

    Do you think you could restore the php5.6.20 compatibility ?

Viewing 2 replies - 1 through 2 (of 2 total)
  • Abhishek

    (@abhikr781)

    3 years ago

    Hello,

    I can understand your concern but the issue but WordPress has set the minimum PHP threshold to 7.2 in 2020: https://wptavern.com/wordpress-bumps-minimum-php-recommendation-to-7-2
    OceanWP has changed the recommendation for the minimum required PHP version months ago, and it’s unrelated to the current theme version.

    In this matter only updating the PHP version is the solution.
    You can share the above URL with your host provider, to show the minimum requirements have been changed and ask for PHP to be updated to any 7.2+ version and everything will be fine.

    Thread Starter Boldair Développement

    (@boldairdeveloppement)

    3 years ago

    Hello @abishek

    Well I can’t say I’m surprised by that reply, even though in this instance it’s not my host provider.

    To give you some context, my customer is a subsidy of a big french publisher, that publisher has an internal IT service that acts as the host provider for the entire corporation.

    My customer are contractually obligated to use them instead on any other hosting service. They also charge my customer hefty fees for about anything, be it the hosting or changing a slash in a virtual host configuration file (they did that just last wee in fact, I’m not kidding, there was a misspelling or a ‘//’, instead of ‘://’ in a Content-Security-Policy, they charged something like 5 hours for the correction)

    And this IT service has flat out refused to change the PHP version on this server. It’s not ‘Give us a good reason, and we will charge you but we will do it’, it’s ‘No way ever will it happen good sir’.

    I’ve had dozens of headbutting with these guys other the years, but they just don’t budge, even when so obviously wrong.

    So I’ve been living in dread of the day where the PHP 5 compatibility would finally be broken on these 9 sites by some plugin or other, because I cannot change hosting on them, and I cannot have the server’s PHP upgraded.

    Turns out its the theme with 5 lines to show off how good and nifty the coder who wrote them is, but that have not any real benefit to the efficiency of the theme itself. Well that was bound to happen sooner or later. I’m finally caught between a rock and a hard place and bout to be crushed 🙂

    Now i will have to disable the updates on those themes on the sites, crossing fingers that they don’t have some XSS vulneralbility in the latest working version, and hope for the best.

    Well thanks for you time anyway.

Viewing 2 replies - 1 through 2 (of 2 total)
  • The topic ‘2.0.4 breaks compatibility with php 5.6’ is closed to new replies.