diogo

Oh wow, Soma, glad to have you back here! My mind just went way back now 😄

Thanks for reporting @monollonom! It seems like our small animation on the logo, breaks the page in Firefox. While we don't figure this out, I removed it from firefox with @-moz-document url-prefix()

Not as nice, but at least the page works.

Edit: the animation works for Firefox now 👍

Chris Ferdinandi has a valuable opinion on the subject. I would love to agree with him, but I honestly don't know if I can afford to https://gomakethings.com/training-your-replacement/

While you're at it, check his others posts and subscribe to the newsletter, he is a very insightful guy 🙂

@AndZyk just sent a fix for this to Ryan. 

@markus-th In my view there's no reason to be confused, there's a disagreement on the strategy, that's all. Your position doesn't confuse me, I understand it perfectly, I just don't necessarily agree that it's the best path.

Also notice that I carefully worded that sentence to convey that this is only one of the aspects that we discussed. It doesn't mean that it was the most important one and it doesn't mean we discarded other targets. We still think the site will convince developers to go deeper and discover PW. What we did, in that aspect, is not much different from what greatly successful tools aimed at developers are doing. From the top of my mind, see Next, Astro and Svelte

Thanks you for your opinions and suggestions, they are very welcome!

We can always count on this community for engagement 👍

One aspect that we discussed, and that I don't think Ryan mentioned, is that Jan and I had several clients express concern about the tool after visiting the previous website. PW has some recognition among developers, but zero recognition among non technical potential clients, who we need to accept PW as our CMS suggestion. That's also one of the reasons of having "CMS" and not "CMS/CMF" front and center.

Design decisions will never please everyone, we were aware of that and decided to go bold anyway. Hopefully it will prove to have been the right decision 🙂

On 8/12/2025 at 7:10 PM, adrian said:

I also think you might have missed a key marketing point - "headless"

That could be a fun animation to make 😆
Seriously, though, I think we discussed this at a certain point. Not sure why we dropped it, maybe because being headless in PW is a possibility and not a feature, while all the other things on the homepage are inherent to PW. The GraphQL plugin could certainly be on the modules area in the homepage, though.

@markus-th I had this on my list, but somehow didn't get to doing it. Yes, it should be an easy fix.

11 hours ago, stehlo said:

@jploch @diogo @ryan

Running after numbers whilst going against the current user base – that is a trap, which many have fallen into.

Masses are not making sane decisions; therefore, sacrificing the unique quality aspects of a niche product by trying to appeal to "others" or "all" tends to lead to "neither" and "none."

Releasing a grossly unfinished and cross-browser incompatible subproduct, completely neglecting minority browsers, as a default version is not the best idea. Ryan's original themes do not make this mistake.

Tagging three people on your post must mean you really wanted to be heard. Why such an unhelpful post, then?
If you want to vent your frustration, at least put a minimum effort on it.

1 hour ago, markus-th said:

To make elements visually easier to grasp, I use the option to adjust the colors in the item headers.

Unfortunately, this no longer works with the new theme.

This should be a fairly easy fix. Thanks for reporting it!

2 hours ago, bernhard said:

But I try to be more constructive with my feedback in the future.

Thanks

@adrian hm, after your other message, i thought Tracy panels should be over everything, and dropped the z-index of the dropdowns and the nav to accommodate for that (i think 98 and 99, but not completely sure). But if you want the dropdowns to be over the panels, i would need to separate the numbers more. I can’t really imagine how that would work though, don’t you need the nav to trigger the dropdowns? Or am I seeing it wrong?

Ah, also, I’m happy to isolate the fixed menu and command palette css and js into modules that can be used with the original theme.

Thank you for taking the time to write these insightful answers @jploch!

On vacation, and only with the mobile, is hard to keep up with the thread, i feel like I’m getting way behind and missing a lot of stuff.

I just want to respond to a  post from @bernhard that I had in mind, but couldn’t find to quote. It’s concerning the look of the UIkit buttons. If I took your request out of context, it was not intentionally, and probably because I didn’t understand your question. I just copied the examples from the UIkit documents, and pasted them directly inside a process module, and they got styled accordingly. Just like with the UIkit alerts previously, whose style I added to our CSS, I honestly thought that’s what you wanted.

 Please just let me know if I was way off in my understanding.

Ah, almost forgot about the toggles vs checkboxes. Independently of what is decided concerning the usage of toggles, our css selector is clearly too aggressive and id trying to turn, into toggles, some checkboxes that should be left alone. We’ll need to fix that.

Funny, just before submitting, i noticed this 😆

@adrian i maintain that we can tweak the variables for scenarios like yours. I don't see the default theme as highly customisable, and that's not the intention. For that we have Less. In my view, the default theme should be easily customisable, to a certain extent, for those who don't want many changes and also don't want to use Less.

I'll be on vacation for a week, so I won't be able to discuss changes with Jan and Ryan in the next days. For now you can change the color of the menus with:

.pw-dropdown-menu {
	--masthead-active-color: var(--masthead-text-color);
}

This changes the --masthead-active-color, but only inside the menus. For everything else, it remains how it is defined in the :root. The theme itself defines variables only in the root, exactly so that defining variables in other elements always overrides them without using !important.

17 hours ago, bernhard said:

Could you please share some information how we as module developers can make our modules work with the new style? It might sound easy for you or the style authors or any CSS ninja out there, but it might not be easy for backend-focused devs. In this specific case I'm wondering:

• How can I make the headlines show up properly in dark mode? Which color would I set? Which css variable would I use?
• How can I make buttons like "today" and "left / right" at the top right look like all other buttons (like publish, for example)?

Regarding the buttons I'm quite confused for a long time and it might be the right time to mention it now: Many buttons use "ui-button" as class. As far as I understand this was the class coming from jQueryUI and with the old style this was giving it some rounded corners (compared to default uikit buttons). Then UIkit was added to the mix and from that time on I thought we can use "uk-button uk-button-primary" to style our buttons. At least to get matching colours. That meant that anybody using admin.less to customise their backend and changing the primary color saw a button in the primary color.

In your specific case, you would style the headlines with

color: var(--text-color, #000);

This will use the text color of the light or dark theme, and default to black, if the variable is not present.

For the "today" and "left / right" buttons you can use

background-color: var(--button-background);
color: var(--button-color);

// and for the hover state

background-color: --button-hover-background
color: --button-hover-color

Adding

<button class="uk-button uk-button-default">normal button</button>
<button class="uk-button uk-button-primary">primary button</button>

styles the buttons correctly for me

17 hours ago, bernhard said:

Now we have another layer on top. A style using CSS variables, overriding UIkit, which overrides jQueryUI. This might be wrong - I don't yet understand how all of them play together and which layer overrides another, but I think you get my point and I'm happy to be corrected or get an explanation of how these layers are supposed to work together.

May I also ask for some help or explanation how we can deal with that to provide good and reliable modules? What classes shall we use for which elements of the UI?

It's true that this is a skin on top of Uikit, and we inherit the decisions of Uikit to style every single element individually instead of inheriting colors. This means that you can use Uikit elements, but that their colors will aggressively try to override ours. This works well in most part for light themes, but, in your case it is breaking on the dark theme. There are two things we can do simultaneously to mitigate the problem:

1. switch to a dark uikit base for the dark theme.
2. override the uikit color with our variables for at least their most important components.

For now, the most reliable way to style markup that you add to the admin, is to do what I described before for your calendar.

@ryan thanks for doing this work!

For process modules, I want to point out that you can use variables like this

color: var(--text-color, #000);

This will use the light/dark color from the new theme, but default to black if the variable doesn't exist and, therefore, work on the current theme also.

14 hours ago, adrian said:

Also, as I mentioned in the other thread, along with changing the text color away from pure black, I still think another very important tweak is the color of the dropdown menu items - I still think they need to be the same color as the top level menu items when not selected. At the moment it looks like all submenu items are selected because they are the same color as the selected top level item. All items (top or dropdown) should be the lighter color unless it's the current page.

I tend not to agree with this. The submenus have a completely different feeling than the main menu, since they are boxed and stacked vertically and allow for a much stronger marking with the background. The size of the font is also smaller and denser, and it's readability would suffer more with a lighter color. Also, unlike the main menu, the links in the submenus are not even marked with the active class, since many of them don't even represent pages, but actions.

15 hours ago, adrian said:

@ryan - thanks for the option to disable toggles, but would you consider reversing it because as @bernhard and I pointed out, there are too many situations in 3rd party modules where toggles are just broken so I think the default should be checkboxes still. Also, keep in mind that the inputfield type is called "checkbox(es)", not "toggles".

There seems to be a strong reaction against the toggles, and some good arguments. Although I would argue that, comparing to the light switch situation (referred on a blog post linked in the other thread), our toggles on and off states are unequivocally clear because of the use of muted vs strong colors. @jploch and I really like how the toggles look like in the theme, but are not insensitive to the requests. We'll discuss possible solutions with @ryan.

12 hours ago, adrian said:

Sorry to keep going, but we desperately need more css vars. --blocks-background controls the color of so many things it makes it effectively useless. It impacts the top nav, the actual field blocks, the color of button text (what's with that?), the page list actions hover bar, and probably more.

I personally made a point in keeping the number of css vars low. I'm totally open to tweaking them, and adding a couple more, but I will definitely not add a bunch more. The idea of these variables is to allow users very easily create a different feeling to the admin, by only changing a few colors. Having few variables and making them depend, by default, on other variables, allows you to completely change all the colors with defining only 5 or 6 variables. You are correct that changing the background also changes the button text, the reason is that, like this I know for sure, that whatever colors you chose, there will be contrast between the background of the button and the text even if you don't define the (--button-color) variable yourself.
 
For a complete change and control of the admin theme (not only colors), I would say it's better to with the original theme or AdminStyleRock and LESS. Again, this doesn't mean that we can't tweak the variables to account for cases like in your example.

12 hours ago, adrian said:

--muted-color is also used for the page list action links but these should be highlighted, not muted. But regardless of what you think they should look like, they definitely shouldn't be tied to the same color as hidden pages. And is there a reason it's --muted-color and not --muted-text-color?

There's no special reason why it's --muted-color and not --muted-text-color. 

In our opinion, the most important information on pages list is the the name of the the pages, and the most important action is to find the page you need to work on. The action buttons are always the same, and so, it's much easier for you to find the one you want to activate, then looking for the correct page on the list. Most of the time you will even be clicking "edit", which is the first one to the right of the page name. That's a very automated process. Also, in our case, "muted" does not mean unreadable. We want the hidden pages to be as easy to find as the non hidden pages, and easier to find than the action buttons. For us, using a softer color makes it softer to the eyes that a string of words appears from nowhere when you hover the pages in the list.

Again, I'm willing to tweak the name of the variables to make them clearer, and even add a couple more variables to the list, but I wouldn't be happy to add a bunch of new variables and make the system more complex.

Hey all! This won't be a complete response to everything that was raised in this thread yet. Just wanted to quickly drop some notes before they vanish my mind 🙂

I will start by the end though, since it was @ryangorley mention that brought me here. You're completely right about how a clear communication of objectives helps everyone to accept the inevitable subjectivity of design (yes, I believe that, even with very defined objectives, design is still highly subjective). @jploch and I planned to write a blog post detailing, not only our thought process, but also a detailed description of how to customize the new design. We didn't have the time or headspace to do it but, with Ryan, we decided to launch on the DEV branch anyway, so this discussion and bug finding could happen as soon as possible. I now believe that this blog post wouldn't have answered most of the questions that people are raising, so in hindsight I think launching early, even with it's shortcomings, was the right choice. I would also like to remind everyone that, as Ryan referred multiple times, this is not a new theme but a skin on top of the uikit theme (it's ok to call it a sidegrade, although we consider that some aspects of it are definitely upgrades).

Again, we accept and expect that not everyone will genuinely like the new theme more than the current one. Those people will have a natural resistance to this change, and there's not much we can do about it, either than respecting (the biggest sign of respect is that the current theme will stay in the core, with an easy switch). For others the resistance will stem from a feeling of "lost opportunity", in thinking that this will inevitably be the ProcessWire theme for the next multiple years. We discussed changes much more profound than these, but those would take time and would certainly not involve the community, if done in closed doors. So we decided to go with the more "superficial" and quick solution. The goal is for it to work in this moment, and to welcome new users who may come with the new site with something more coherent with what they'll find there. Those bigger changes, and others, can still happen as much as they could before.

To finish. Meanwhile I sent Ryan a few small corrections based on things pointed out throughout the whole thread. Hopefully they will make it soon enough to the DEV branch. Thank you all for testing, giving your opinions and finding these bugs 🏆

Hi all 👋

Just dropping in to thank everyone for your input and to acknowledge that I read through the thread. I don't have time to respond at the moment, but will do as soon as possible.

7 hours ago, artfulrobot said:

Or do it in a standards-compiant way?

https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/accesskey

From the page you linked to:

Quote

Accessibility concerns
There are numerous concerns with the accesskey attribute:
(...)
Because of these issues, it is generally advised not to use accesskeys for most general-purpose websites and web apps.

You can also use the admin.php file to load any css file (you can find it in the templates directory), for instance an admin.css file next to it. You just need to add the line $config->styles->append($config->urls->templates . "admin.css"); right before require($config->paths->core . "admin.php");

You mean, type them in a text area with the spaces, like in the example above? Seems like it would be a pretty complex PHP script, but possible, I guess...

If you don't mind to write something closer to the html code, it would make it really easy. You could simply wrap the notes in an element by making them bold, and make each line a paragraph:

EI'll take you Dfor a rGideB

EOn my gaDrbage tGruckB

BOh noA

And then just add something like this to style it.

p {
  position: relative;
  margin-top: 1.5em;
}

strong {
  position: absolute;
  bottom: 1em;
  color: red;
  font-weight: inherit;
}

Or, if you need exactly the html code from above, do a str_replace in a text formatter  from "<strong>" to "<span class='chord'>" and so on...

Hetzner is quite cheap and reliable, and they make it easy to change PHP configurations. I also like their transparency with prices and communication. The control panel is admittedly not very attractive or intuitive, but we can't have it all, can we? 🤷

@MrSnoozles sorry, I have to correct myself here. I should have written that MariaDB and MySQL are generally interchangeable. There are different features since the very beginning, but they are very specific. It seems like, though, MySQL 8.0 has some bigger differences.

Concerning JSON functionality. For what I understand, the difference is how JSON is stored on each of them. MySQL stores JSON as binary objects, and MariaDB as strings, but the functionality is (again) generally similar.

12 minutes ago, MrSnoozles said:

@ryan The module sounds very cool. Does it support MariaDB too or only MySQL?

MariaDB and MySQL are interchangeable 🙂