Support » Plugin: GigPress » Parse error in Gigpress update febr.01

  • Resolved oglikap

    (@oglikap)


    I am using gigpress on several sites for almost 5 years. Never had any problem until today. After gigpress automatically updated to 2.3.25 [2021-02-01] these started to go blank and I recieved mails about technical errors. The error includes this message:

    Parse error: syntax error, unexpected ‘else’ (T_ELSE) in (…)/wp-content/plugins/gigpress/admin/shows.php on line 288

    For me the solution was a quick and dirty one: I just deleted the line manually and the sites were up and running again. But there has to be something wrong with the code in that new version 2.3.25!

Viewing 13 replies - 1 through 13 (of 13 total)
  • Just cleaned up same here. I went with “mv gigpress /somewhere-outside-wordpress”.

    Looks like the preceeding “if” block is missing the “?php” to denote PHP.

    I believe you can configure PHP not to require it, likely what the author has done, allowing them to release code that doesn’t parse.

    diff oldshows.php shows.php
    286c286
    < <? if ( ‘deleted’ === $scope ) : ?>

    > <?php if ( ‘deleted’ === $scope ) : ?>

    php oldshows.php
    PHP Parse error: syntax error, unexpected ‘else’ (T_ELSE) in /home/simon/gigpress-broke/admin/oldshows.php on line 288

    php shows.php produced no such error.

    Thread Starter oglikap

    (@oglikap)

    That’s the error, obviously! I should have seen that myself, but I panicked with 3 websites going blank and 2 kids home. Thanks!

    Still a bug, I think

    Yes, I also pinged the WordPress plugin email address, suggesting this is a class of error that should be caught before release. Slightly surprised it wasn’t.

    As far as I know short tags are both enabled by default and deprecated now.

    This was the closest I found on a quick look…
    https://wiki.php.net/rfc/deprecate_php_short_tags_v2

    There is no good answer if the ini settings mustn’t change the language other than to remove short tags as they are incompatible with other languages and mark-up, so if you do anything but remove them you risk silently breaking more than removing them. Either way developers need to avoid edge cases and address all warnings, I’m working on a test suite for my own plugin which would have spotted this, clearly need to pull my thumb out and get it released.

    • This reply was modified 2 months, 1 week ago by SimonRWaters.

    +1

    I have reverted to 2.3.24 for now.

    Cheers.

    Plugin Author András Guseo

    (@aguseo)

    Hi @plittlefield @simonrwaters @oglikap

    Thanks for flagging that. I’ll see if we can do something about it.

    Cheers,
    Andras

    I have 20 sites down due to this error and a lot of upset clients – I hope you get this fixed quickly because we depend on GigPress!

    Thread Starter oglikap

    (@oglikap)

    Fix is working, András, thanks!

    Plugin Author Scott Kingsley Clark

    (@sc0ttkclark)

    I just released a fix to address this particular PHP compatibility issue with certain environments. Look for GigPress 2.3.35.1 as an available update you can snag.

    Plugin Author Scott Kingsley Clark

    (@sc0ttkclark)

    To be perfectly transparent here —

    The issue here was the PHP <? short tag usage which on some environments works fine, but as of PHP 7.4 triggers deprecation notices. My test environments unfortunately had short tags enabled so I never saw the errors everyone was reporting. Many production servers have it disabled which affected those of you who replied here.

    As a result of the feedback, I reviewed all usages of short tags and fixed them — which was luckily just this one occurrence.

    Thank you all for your patience here, I’ll be sure to keep an eye out for contributions that contain the old syntax in the future.

    THANNNNNKKKKKK YOUUUUU!!!!! All good. : )

    Moderator Ipstenu (Mika Epstein)

    (@ipstenu)

    🏳️‍🌈 Plugin Review Team Rep

    Yes, I also pinged the WordPress plugin email address, suggesting this is a class of error that should be caught before release. Slightly surprised it wasn’t

    Hi, I’m from the plugin team, and I wanted to point out a couple things that we told @simonrwaters in email.

    We absolutely DO tell people don’t use short-tags. But that happens in your initial review. We do not review each and every release of every plugin (you’d have about 50 plugins if we did that, not 90k+). We don’t auto-flag this in SVN checks because it has far too many false positives at the moment, but it’s on the radar of automated commit rejections we’d love to do.

    So the fact that Gigapress is not a ‘brand new’ plugin means this is outside what we check for, and it’s 100% on them.

    Fixed, thanks!

    Plugin Author András Guseo

    (@aguseo)

    Awesome! Thanks for reporting back @plittlefield!

Viewing 13 replies - 1 through 13 (of 13 total)
  • You must be logged in to reply to this topic.