NOTICE: PHP message: PHP Fatal error: Unparenthesized

[dawidmachon]

Hi,
PicoCMS not working with highers PHP versions (in my case 8.0). Error which I reciving:

NOTICE: PHP message: PHP Fatal error:  Unparenthesized `a ? b : c ? d : e` is not supported. Use either `(a ? b : c) ? d : e` or `a ? b : (c ? d : e)` in /var/www/html/vendor/twig/twig/lib/Twig/Node.php on line 42

As far as I found, PHP 7.4+ changing this:
https://www.php.net/manual/en/migration74.deprecated.php

I think, this should be fixed because older versions are comming to end of life.

or maybe I missed something, and someone could help me.

Thanks for amaizing work!

[mayamcdougall]

Hello there! 👋🏻

(For our reference, this is a "duplicate" of #584.)

There's currently a pre-release build Pico 3.0.0-alpha.2 available that fixes this issue. This alpha has only minor changes, to support updated versions of our dependencies, and should be safe to use in production.

You're absolutely right that this needs to be fixed asap. You're not the only person to be bitten by this lately. 😓

Give that build a try and see how it works for you. Thanks for your patience, and for your interest in Pico. ❤️

---

@PhrozenByte, this has gone on a while already, and it's only getting more common. I've got two suggestions:

1. If it's still not ready, we should temporarily pin this information in the readme or somewhere else easily visible.
2. If you think the dependency related changes are good enough, this should be converted to a 2.x major point release. I know it's not ideal, with the dependencies changing, but I feel like at this point it's got to be either do a point release or sacrifice the 3.0 version number to this update and bump your additional plans to 4.0.

Please leave the issue open this time. Since it's a user facing problem it's not really "solved" until people stop getting bitten by it.

Keeping an open issue lets people know "we're aware of this, here's a workaround".

[dawidmachon]

Thanks for reference and link for alpha version. Pico CMS is treasure across different flat file cms. Simple, clean, fast. Do we know any 'release' date for stable 3.0?

[mayamcdougall]

Pico CMS is treasure across different flat file cms.

It really is. 😁

Don't know what I'd do without it.

Do we know any 'release' date for stable 3.0?

I don't, unfortunately. @PhrozenByte would have to answer that one, since he's the main programmer on Pico. I know he hasn't had a lot of time lately to work on it, and I'm not sure where he's at with development.

That's why I've suggested above maybe doing an interim release based on the dependency changes alone. I know he usually likes to save major, potentially breaking changes for big updates (like a 3.0 release), but I'm seeing it be an issue more and more here and that's only going to increase.

[PhrozenByte]

Sorry for the late response, unfortunately I'm drowning in work lately. I guess we can make v3.0.0-alpha.2 stable v3.0.0 (it must be v3.0 due to breaking changes in our dependencies) and postpone #535 to Pico 4.0... Will try to find some time to actually do this.

[dawidmachon]

@PhrozenByte - I've using 3.0.0 Alpha from last 2 weeks without problems, but its 'simple' usage and learning twig etc there only. I almost throw away Pico when this php not working, when I downloaded the latest version. I think this projects needs more influx of newcomers so 3.0.0 is needed.
From my side, I will try to update two themes which was already ported to be good example of Pico in real usage ;)

[mayamcdougall]

Sorry for the late response, unfortunately I'm drowning in work lately.

No worries from me on this. Hang in there. ❤️

Also, don't ever feel pressured to "address all the things" at once. If you've only got time to look into one Issue or two, don't feel like you need to make time to tend to everything.

I try to hold down the fort in the meantime, after all. 😉

postpone #535 to Pico 4.0...

I mean, some of the minor things could possibly be labeled as 3.1, 3.2 if they're not breaking changes. Maybe a staged rollout of smaller features would work better with your limited availability anyway. I know working up toward a big release feels nice... but speaking from experience it also can get daunting quickly.

Suddenly you've got this huge todo list of things you don't have time to finish blocking your release. 😫

But, I mean, I'm one to talk. I'm almost always in the bad habit of working on multiple things at once, then having to manually pick which lines I'm ready to commit. 😂

Will try to find some time to actually do this.

Sorry for the pressure. 😅

PHP 8 is popping up more and more though. 😔

[bjarneds]

Any news for an official release of this fix?
Currently, I've "downgraded" a site I manage to PHP 7.4 to avoid this problem, but my hosting provider only allows this for a limited time.
I know you've said that 3.0.0 alpha.2 is safe for production, but it just feels wrong with alpha in the name.

[mayamcdougall]

@bjarneds, the "alpha" version is perfectly safe to use in production. The only changes in it are dependency versions and version number strings. Unfortunately, no further work was ever done on that branch. If you're feeling uneasy about it, you can compare the changes here on GitHub to see what I mean.

---

@PhrozenByte No worries, but it's time to tackle this problem. This is my second time writing this comment because my browser ate the first one...

I guess that's an excuse to be concise for once. 😣

My recommendation is that we merge in only the dependency changes (or rather, just change them fresh and ignore the alpha branch), and package that as "Pico 2.2".

I know you don't like "breaking" changes in a minor version, but at this point, it's a bug fix. Pico is no longer compatible with current PHP. We can have an upgrade note highlighting the newer PHP requirement.

I don't think it warrants a "3.0" release, and I think labeling it as one feels disingenuous since there's literally no other changes.

I'm going to put a note in the readme about PHP 8.0 for now.

I can try to take care of the "2.2" version bump as well if you like that idea. I don't know how any of your CI stuff is set up right now (can it automatically build new release packages? etc), but I could at least set up a pull request with the file changes for you, since it's all a bunch of string updates.

Let me know how you want to proceed with this. Don't stress over it, but something has to be done soon. I know it's not ideal, and not how you wanted to handle it... but it's also not the end of the world.

Just leave a quick "Yes, go ahead and do that", and I'll take care of what I can for you. ❤️

[mhzawadi]

Hello 👋🏼

Any news on a PHP8.1 picoCMS release any time soon? I have some sites in my nextcloud instance that I now cant use as I have updated to PHP8.1 for speed, I have the v3 alpha running over at www.horwood.biz and its been fine. Mind you I do have a very slim install.

More than happy to help where I can

[fearedbliss]

Hey all, Just adding in here that I've also ran into this problem since I had to upgrade from PHP 7.4 to PHP 8.2. (FreeBSD has dropped PHP 7.4 for security reasons). I've upgraded to Pico 3.0.0 Alpha 2 as instructed above and everything is working great.

I do agree that we'll need to make a compatibility release at the bare minimum, no other additional features are needed other than making it still run with modern PHP.

Thank you :).

[nsherzog]

Hi. I'm running PHP 8.1.6 and I downloaded Pico Alpha 3.0-alpha2 as directed. I'm still seeing errors running default (non customized) files:

Deprecated
: Return type of Twig\Markup::count() should either be compatible with Countable::count(): int, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in
/blog/vendor/twig/twig/src/Markup.php
on line
35

Deprecated
: Return type of Twig\Markup::jsonSerialize() should either be compatible with JsonSerializable::jsonSerialize(): mixed, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in
/blog/vendor/twig/twig/src/Markup.php
on line
40

Deprecated
: Return type of Twig\Node\Node::count() should either be compatible with Countable::count(): int, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in
/blog/vendor/twig/twig/src/Node/Node.php
on line
161

Deprecated
: Return type of Twig\Node\Node::getIterator() should either be compatible with IteratorAggregate::getIterator(): Traversable, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in
/blog/vendor/twig/twig/src/Node/Node.php
on line
166

Deprecated
: Optional parameter $callable declared before required parameter $arguments is implicitly treated as a required parameter in
/blog/vendor/twig/twig/src/Node/Expression/CallExpression.php
on line
116

[PhrozenByte]

Set error_reporting in your php.ini to a value recommended for production servers, e.g. error_reporting = E_ALL & ~E_DEPRECATED & ~E_STRICT.

[lloydsargent]

I’m going through and addressing all the deprecation warnings: some of these are just trivial to fix. Others, not so much. I plan to move this to my private repository until Pico is finally released as not-alpha.

I’m HOPING to finish my changes today. Pico Alpha-2 worked fine on my local machine, but the permissions were all wrong (for files and directories) so once I moved it to the real system, it tossed up the dreaded FORBIDDEN. That was annoying.

I don’t know about anyone else, but I tend to keep my system limited as much as possible and would REALLY PREFER if all user content were under a single directory (including plugins). That would simplify upgrades.

TBH I have had ZERO luck with Composer. It’s literally faster for me to download a release and move my content over. As such, what can I get rid of regarding Composeer?