Update Patternfly from v3 to v5

[Venefilyn]

With Patternfly now approaching GA for v6, it occurred to me Copr makes use of Patternfly v3 still based on the UI. Are there plans to adopt the newer Patternfly versions?

There are some difficulties converting Copr repo to v4 and up due to the fact that there is no pure-JS component anymore as it dropped the bootstrap dependency going from v3 to v4. That means no interactions work out of the box with the HTML components of Patternfly v4 and up

There is a possibility to use https://github.com/patternfly/patternfly-elements as it allows for interactions out of the box. Otherwise one could adopt React within Copr. Though that might be too much.

To make the process smoother, once the plan is set to migrate we could update the styling of Patternfly v3 to match v4 and up. That way the gradual migration won't be visible to the users. IIRC there was something for this usecase in Cockpit @martinpitt, do you have a link for that?

[martinpitt]

Right, PF4/5 necessarily require React. This is rather annoying, and I wish PF elements would be a bit further along. That said, it does work, and in my view it's definitively the future. If the current components are sufficient for you, then by all means use them instead of introducing React.

In cockpit we indeed did that migration by re-styling PF3 to look (mostly) like PF4:

• https://github.com/cockpit-project/cockpit/blob/ac9ad17ce7f5dca4607fa61551988a752a7f559e/pkg/lib/patternfly/patternfly-overrides-variables.scss
• https://github.com/cockpit-project/cockpit/blob/ac9ad17ce7f5dca4607fa61551988a752a7f559e/pkg/lib/patternfly/patternfly-overrides.scss

and then ported pages one by one to the real PF4. But that really happened on a per-iframe granularity (completely isolated), we never tried to mix PF3 and 4 in the same page -- or perhaps we tried, and saw it burst in flames. This all happened many years ago, and I don't remember many details about it any more, sorry. But I do remember that it was a huge pain, and that was with already having React.

[nikromen]

Hi, thanks for the issue.

First, I'd like to clarify - do we need to migrate from PF v3 to v5, or is it more of a nice to have? One key concern for us is that we have users who have JS disabled, and since PF v4 and above rely on React, this could break the frontend page for them, which would be a blocker for us (it might be good to find out exactly how many such users there are :D)

Additionally, our frontend is primarily built with bootstrap. If we need to drop PF v3, it'd be easier for us to replace PF v33 entirely with bootstrap. Is there a specific need/(beginning of) movement for Fedora/RHEL products to maintain a consistent appearance, such as using PF templates? If so, migrating to align with this would make sense.

We'll likely be able to remove PF v3 on our own, but we currently lack the capacity to handle the full migration. If you're open to contributing or submitting a PR, it'd be gratly appreciated and we would be happy to collaborate :)

[FrostyX]

it might be good to find out exactly how many such users there are :D

Probably. Somebody could do a survey (or something) unrelated to this specific issue but for Fedora in general.

But I think we can safely assume it is a nontrivial amount. While the idea of disabling JavaScript is preposterous in this age of modern web, it is not uncommon in our small Fedora bubble. Also, the percentage of fundamentalists with disabled JavaScript might be in single digits, but there will be a lot of people who has JavaScript enabled but prefer if websites use it only when necessary

[martinpitt]

do we need to migrate from PF v3 to v5, or is it more of a nice to have?

From our perspective, entirely the latter. It's not prone to security issues, it's just that if you have trouble with a widget, you are entirely on your own, upstream won't help you with that old version any more. The only things to consider are:

• are some look&feel consistency between products such as Foreman/Satellite, OpenShift, console.redhat.com, Cockpit etc. (but COPR isn't much of a RHEL product)
• Later PF versions are much more accessible

But if "runs without JS" is a concern, then PF4/5 are out. Even PF elements requires JS (just not React) to register the custom components, and of course their internal implementation.

[praiskup]

are some look&feel consistency between products such as Foreman/Satellite, OpenShift, console.redhat.com, Cockpit etc. (but COPR isn't much of a RHEL product)

Speaking for the Fedora Copr instance, it would be awesome if there was some Fedora-oriented look&feel consistency effort.. don't we have some?

[Venefilyn]

Speaking for the Fedora Copr instance, it would be awesome if there was some Fedora-oriented look&feel consistency effort.. don't we have some?

That is something I brought up with PatternFly team, which should be easier now that PF6 is around the horizon. Since PatternFly is used in a lot of places it makes sense to get the Fedora look and feel there

But for the general gist for the style can follow https://gitlab.com/fedora/design/team/logos/logo-meta/-/blob/main/brand-book-new-1.pdf?ref_type=heads

[praiskup]

It would be nice to have a link to the Fedora "look & feel" tracker, once it exists.

[nikromen]

Based on our recent planning discussion, we currently feel that dedicating time to this task may not be the best use of our resources. One of the main considerations is that PF4/5 relies on JS, and at this point, we’re not experiencing issues with PF3, which we’re currently using. While we recognize the website may appear outdated, a redesign is beyond our current capacity. However, if there’s a broader initiative from Fedora to ensure a more uniform look across services, we would certainly reconsider this.