Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Pico 3.0 #535

Open
wants to merge 81 commits into
base: master
Choose a base branch
from
Open

Pico 3.0 #535

wants to merge 81 commits into from

Conversation

PhrozenByte
Copy link
Collaborator

@PhrozenByte PhrozenByte commented Mar 29, 2020

Since the issues with our old dependencies kinda got out of hand lately (see #528, #534 and 8a44584), it's time to kick-start development of Pico 3.0 🎉

Major changes are going to be updated dependencies (Twig 3.0+ and Symfony YAML 5.0+) and lifting the requirements to PHP 7.2.5+. We definitely won't implement all of #317, but rather focus on lazy page discovery and loading. We definitely won't overhaul Pico's event system now, neither will we implement caching or i18n support with Pico 3.0 (maybe with Pico 3.1? 🤔).

We'll also think about changing Pico's Markdown parser. Unfortunately Parsedown's development process got very unreliable lately. However, there's a lot to consider - not just BC, but also performance-wise (Parsedown is by far the most performant Markdown parser I know). Thus there's no decision made yet. Other opinions are very welcome on this topic! Also see e.g. #576

Pico 3.0 is a major release, thus it will break BC. As always, Pico's official PicoDeprecated plugin (Pull Request) will do its best to maintain BC. However, be warned, we'll explicitly drop all pre-v1.0 and v1.0 behaviour that affects performance.

As always, feedback is highly appreciated! ❤️


Ideas


Release of Pico v3.0.0-alpha.1

Since the mentioned issues are affecting live installations already, I decided to release a intermediate Pico v3.0.0-alpha.1. This release upgrades Pico's dependencies to Twig 2.12, Symfony YAML 3.4, Parsedown 1.7.4 and Parsedown Extra 0.8.1 for now (requiring PHP 7.0.8+). Both are still officially supported and are basically drop-in replacements, since they maintain BC on a best-effort basis ("best-effort" means "should work for most users", there can still be issues for some users). Pico v3.0.0-alpha.1 is meant as a fast solution for all people experiencing the issues mentioned above.

Feedback about Pico v3.0.0-alpha.1 is highly appreciated, especially regarding issues! 👍


Related links


Major changes

  • Require PHP 7.0.8+
  • Update dependencies: Twig 2.12, Symfony YAML 3.4, Parsedown 1.7.4 and Parsedown Extra 0.8.1; this is just an interim step, we'll update to Twig 3.0+ and Symfony YAML 5.0+ later

Resolves #528, Resolves #534
Fixes #602, Fixes #603, Fixes #608, Fixes #623

Pico now depends on Twig 2.12, Symfony YAML 3.4, Parsedown 1.7.4 and Parsedown Extra 0.8.1.
```
* [New] Kick-start development of Pico 3.0
* [Changed] Require PHP 7.0.8+
* [Changed] Update dependencies: Twig 2.12, Symfony YAML 3.4, Parsedown 1.7.4
            and Parsedown Extra 0.8.1; this is just an interim step, we'll
            update to Twig 3.0+ and Symfony YAML 5.0+ later
```
Use AbstractPlugin::getPico() instead (e.g. `->getPico()->getConfig('my_config')` instead of `->getConfig('my_config')`).
Use Pico::getConfig('themes_url') instead.
@dajare
Copy link

dajare commented May 3, 2020

If you are considering alternatives to Parsedown (and its Extra), you could have a look at Markdown-it, although I don't know how well its technologies integrate with Pico's environment. I've become familiar with it on the TopAnswers.xyz platform, where it seems to be performing well.

Since Pico depends on PicoDeprecated, and PicoDeprecated depends on Pico, a chicken-egg-problem arises: When pushing a new tag for Pico, GitHub Actions will try to build this new release by downloading the matching version of PicoDeprecated from Packagist. Since we didn't release a new version of PicoDeprecated yet, this will fail. So we need to push PicoDeprecated's tag first. Doing so yields GitHub Actions trying to build PicoDeprecated's new release - by trying to download the matching version of Pico from Packagist, which doesn't exist yet.

Thus builds will always fail - unless you push both tags at the exact same time, and unless you send some prayers that GitHub Actions delays building until Packagist picks up the new releases. The simplest solution is not to use GitHub Actions to publish new releases, but letting the user to do it instead. With this changeset this is as simple as `make publish version=v3.0.0`. The 'deploy-release' GitHub workflow now just updates the website and is triggered by publishing the GitHub release, not the tag. This additionally allows the user to perform some manual tests before publication.

The build script now depends on GitHub CLI (`gh`), see https://cli.github.com/. You must setup authentication first (`gh auth login`).
@mayamcdougall
Copy link
Collaborator

Ooo, some "art". lol. 😉👍🏻

Feels like a good time to mention that I also noticed the credit you added to yourself at the bottom of the Default Theme. 😉

Very well deserved, lol. I don't have any issue with it, I just noticed it a while back and wanted to be like "Aha, I see what you did there!". 😂

@PhrozenByte
Copy link
Collaborator Author

"CI is ready" was a bit premature, we kinda had a little chicken-and-egg situation with automatically building Pico and PicoDeprecated: Pico depends on PicoDeprecated to build, and PicoDeprecated depends on Pico to build. Fixed with 60d0f54. Builds might still fail if tags aren't pushed at the same time, but that's no big issue because one can simply manually start the workflow another time, check the result and then manually push a new release with make publish. Also see 81c2172

I overwhelmed myself a little working on the Themes at first, so I've been taking it slower this week. It's not difficult, just time consuming. sweat_smile

No worries, it isn't ready for release yet anyway 😉

Heck, I get overwhelmed with it sometimes and I don't even have that many other obligations. It's mostly just awkward at times.

❤️ 👍

Should probably have a proper discussion on it at some point, but the overview is this: We've got a few themes that are really more of frameworks than Themes (Boney, Bootstrap, Bulma, etc). But, like everything else, they've never been updated. Bootstrap, for example, is based on Bootstrap 3.0.

If it's this old and you can't reach anyone to inform the dev that the theme needs an update, we should remove it. I'm fine with removing more-or-less broken, or heavily outdated themes (and plugins, even though we didn't merge the wiki yet) which are no longer supported by their respective devs. You shouldn't feel obligated to do their work for them, if they don't want to update their themes, simply remove them.

I did have the realization though: So what you really mean is, every Theme that's ever followed our instruction to borrow from the Default Theme will have issues? 🤦🏻‍♀️

Unfortunately yes 😒

It's also good that Pico doesn't offer any kind of auto-updating, so nothing's going to break without warning. As far as breaking updates goes, it should be pretty tame. The biggest issue is going to be everyone who's created or customized their own Theme.

So, everyone 😆 But yes, it shouldn't be a big issue for most users. I assume that a lot users will stick to Pico 2.1 at first, at least until their respective web hoster drops PHP 7 support. The biggest issue is that we likely loose a lot (abandoned) themes. However, personally I don't value abandonware much 😉

Ooo, some "art". lol. wink👍🏻

Feels like a good time to mention that I also noticed the credit you added to yourself at the bottom of the Default Theme. wink

😉

picocms/picocms.github.io#54

This is what I've got so far. No need to merge yet unless you think I got it perfect in one go, lol. joy

Just let me know what you want changed.

It's up on GitHub Pages for now, but I'll be switching GH Pages back to my Docs Rewrite branch once we're done. wink

I'll review the changes there.

dkyme and others added 5 commits August 14, 2023 10:58
replace strlen in readPages() with variables
* Added functionality for sorting pages by nested meta values.

* Additional variables removed.

* Added comment to the config template file about the possibility to access nested metadata with a dot as separator for sorting.

* Added entry in the changelog about the possibility to access nested metadata with a dot as separator for sorting.

* Changelog and config template adapted according to the suggestions.

* Added old entry back in the Config template.
fix Wrong config keys in discoverPageSiblings #675
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment