End-of-life, project status and Pico's future

[digitalinferno]

This isn’t a roadmap (Pico has been officially declared end-of-life), just a quick checkpoint for those still orbiting (like me) the Pico ecosystem.

Dependencies from the 3.0 dev branch:

"php": ">=7.2.5",
"ext-mbstring": "*",
"twig/twig": "^3.3.8",
"symfony/yaml" : "^5.4.3",
"erusev/parsedown": "1.7.4",
"erusev/parsedown-extra": "0.8.1"

I don’t have the skills to take over the project, but just for the sake of what if I try to upgrade something and see if the world is still out there, here we go. If you're experimenting, forking or sharing knowledge this could help shape your next steps, or maybe not.

• PHP 8.1 seems to work fine with the current codebase. Some cleanup might be needed, but nothing dramatic.
• Twig 3.x already requires PHP 8.1; upgrading to the latest 3.x version looks doable and mostly pain-free.
• Symfony YAML 5.4 (currently used) is still in extended support (only securety fixes) until 2029 thanks to a sponsorship. Eventually, jumping to 6.4 LTS would open more modern features and a newer horizon (active support until 2027), but it could also be a shot in the dark.
• Parsedown may be outdated (and for sure abandoned), but for now, it still gets the job done. Sometimes the old but gold mantra is exactly what you want.

Not so bad.

[PhrozenByte]

Thanks @digitalinferno for this summary :+1: I'll rename and pin this issue, it might be helpful for others to assess Pico's current state.

I just want to throw in a few notes (not just as a response to you, but some general notes) myself, too:

Referring to the README.md:

You can try the last v3.0.0-alpha.2 release, or use the pico-3.0 branch. They are as stable as the last "stable" releases, but just didn't make it through the release process before development was abandoned.

The only issue with #535 (i.e. the pico-3.0 branch) is that it didn't go through the release process, i.e. the code is ready, it's just that the changes are (partially) undocumented and that the code lacks (probably just some) testing. And the CI pipeline is broken. That's why PRs like #706 don't help much: Such PRs are basically just incomplete versions of #535 with the exact same issues. Pico is a well-established project, thus tagging a new major release (#706 would be a major release, too, because it includes basically the same breaking changes as #535) comes with a minimum guarantee of support (this also includes e.g. documentation) and testing.

Pico 3.0 currently just lacks this minimum guarantee of support and testing. That's why users with existing websites (i.e. a working setup) and developers (i.e. users that can fix issues on their own) can keep on using the pico-3.0 branch, including upgrading to it. That's totally fine, because we can assume that these users know what they are doing and thus don't need more documentation and testing than #535 already provides. There are no definitive reasons (like security issues) that would dictate switching to something else, so if existing users want to keep using Pico, they can. Such users simply don't need a tagged version for that.

It's just that things will break at some point in the future: The pico-3.0 branch should work fine with any PHP 8 release, even though it wasn't tested with PHP 8.2 and later. But since PHP rarely adds breaking changes with minor releases, it should remain possible to make Pico work with a loosened error_reporting. We'll see what happens with PHP 9, whenever its development starts.

Pico's history just repeats: Pico was in the same state 10 years ago, so I decided to take over the baton back then. I simply can't (nor want to tbh…) do that any more. So, if someone wants to take over the baton, I'm very happy to help with that. I agree that upgrading the dependencies again would be a good thing (thanks again for summarizing that, I absolutely agree with your assessment), but IMO that's really not the issue, it's what comes after that.

[digitalinferno]

Thanks again for your thoughtful and open reply, it's truly appreciated.

From your notes, it sounds like the current pico-3.0 branch is a solid foundation for anyone looking to experiment or potentially take the project further. At this point, I’m considering two possible paths, depending on whether there’s any community interest:

• If even a small group of people is interested, I’d be happy to explore the idea of a community-maintained branch, starting from pico-3.0. The goal would be modest: keep dependencies up to date, ensure compatibility with modern PHP versions, and document the existing features. Just enough to help current Pico users keep their projects alive a bit longer and perhaps pave the way for a new maintainer (or several) to eventually step in.

• If no such interest emerges and it turns into a more personal endeavor, then a soft fork (likely under a different name) might make more sense. In true open-source spirit, it would just be one variation among others and anyone would be welcome to build their own vision from it.

If anyone is curious or interested in participating, please do so!

[mhzawadi]

Hello

I still use picoCMS and cant find an alternative, the only other option I found is now 5 years old.

How can I help get this up to date and maintained?

[digitalinferno]

@mhzawadi if you're happy with your current setup, there's no need to look for an alternative, Pico is rock solid. However, if you're searching for a specific solution/tech/whatever, the best alternative IMO is Grav. Alternatively, feel free to open a new issue here, we can try to accommodate a solution.

[mhzawadi]

@digitalinferno thanks for the info, what I'm looking for is an update to the latest PHP and OS. As pico gets more out of date my docker image gets more out of date and becomes a security risk, then I have to way up the risk against the use case.

I have looked at a lot of alternatives to this, all of them require changes to markdown files and how you publish sites.

Pico is unique in its simplicity, I can get a site up in minutes and start added content after. To this end getting pico working on PHP 8.4 would be amazing

[PhrozenByte]

I'm still running multiple old websites with Pico 3.0.0 alpha 2 on PHP 8.2, the only necessity is to disable E_STRICT and E_DEPRECATED error reporting. PHP 8.2 receives updates till 2026-12-31. Even though I haven't tested it, I don't really see a reason why it shouldn't work on PHP 8.4, too.

However, if that's not enough info for you to get it working with PHP 8.2+ (i.e. you need this "minimum guarantee of support, documentation, and testing" I was talking about in https://github.com/picocms/Pico/issues/716#issuecomment-2789216140; if you have some dev at hand, you might ask them, it's rather simple for a dev to get it working), I'm afraid to tell you that Pico unfortunately reached its end-of-life.

Please don't run it with an unsupported PHP version, that's a huge security risk. Not because of Pico, but this old PHP version.

I agree with digitalinferno that Grav is an excellent alternative. It's not as simple as Pico, that's true, but it still is comparably lightweight and does a great job. But yes, you'll need to change things.

[herwigfelix]

Hi.

I am just saying that i am really wanting to help contribute to this. The main reason is that Piko puts out websites that look decend but are also completely accessible, and this in a really simple way of building. How ever, due to this almost non existing activity under this issue i am affraid that there is no longer any community interest. What bothers me the most about contributing to the official repo is the fact that the pikocms.com website seams to be really out of date. For example this is not mentioning the end of live of Piko anywhere. I am affraid that when i update the main repo in any form, the website will stay the same. And for some weird reason when you google piko cms, at least here in germany, the first thing you find is not the github but the website. If the maintainer of the website is also here they could comment on it. I will still scan the php code now and do some testings. I might also create a fork if helping to contribute to the official repo proves to be a challenge.

[PhrozenByte]

What bothers me the most about contributing to the official repo is the fact that the pikocms.com website seams to be really out of date. For example this is not mentioning the end of live of Piko anywhere.

The same notice one finds in the README.md can also be found on the website's download page. The website's sources can be found in the picocms/picocms.github.io repo.

[picocms]

Hi. Still here and happy to help with any updates to the site. Currently, it's pointed to the repo that PhrozenByte mentioned above.

[digitalinferno]

due to this almost non existing activity under this issue i am affraid that there is no longer any community interest.

There is still interest... but I believe it is a fact that most users/devs who rely on Pico's code do so for personal use and may not be in a position to take on the commitment of maintaining a project (even a small one), as this requires time and energy. I created a fork with several "improvements" (based on the Pico4 todo list), but I haven't found the time to publish it yet... which is why I understand it's not an easy task.