Weekly update – 7 March 2025

[ryan]

Work continues on the new processwire.com website. I’ve nearly finished developing most of the modules directory this week and next week will be working on the development side of the API reference and sites directory. 

Some more good news to share is that when the new site launches, the new admin look and feel will launch as well. The website and admin share a similar design language in some areas, and I’m confident you will love them both. When we use screenshots of ProcessWire in the new site design, they will be from the new admin look and feel. It is still admin AdminThemeUikit, but with a new face that is beautiful, modern and professionally designed. I’ve been using for more than a week and it’s fantastic in my opinion. 

If for some reason you end up wanting to keep the current look of AdminThemeUikit (perhaps a client doesn’t like change), it will remain as an option too. If you are extending AdminThemeUikit or using the admin.less feature (developed by Bernhard) to custom style the admin, all of that will continue working too. What will likely be changing is that we’ll be moving the older AdminThemeDefault and AdminThemeReno out of the core and into the modules directory. I’d rather keep the core efforts focused with AdminThemeUikit, but continue to support the older admin themes as installable options.

Prior to this, most of what you’d seen in ProcessWire’s core admin and website has been designed by me (excluding AdminThemeReno). And I haven’t worked full time as a designer since 2005 or so. If I ever had any site design skills, they are long gone. So PW has always had a “designed by a developer” look. Having professional designers take over the design of both the admin and the website just feels like a major upgrade to ProcessWire all around. More than I could have guessed. I look forward to when I can share the new site design, admin look and feel, and the designers with you. Thanks for reading and have a great weekend!
 

[wbmnfktr]

  On 3/7/2025 at 10:07 PM, ryan said:

always had a “designed by a developer” look

Expand  

... but it feels like home.

[ryan]

  Quote

... but it feels like home.

Expand  

@wbmnfktr It's funny that you say that, because this is exactly what I told the designers the first time I saw what they did with the admin theme. I told them that what they did with ProcessWire feels like home. Not just home, but a nicer and more modern home. 🙂

 

[FireWire]

Boy howdy, I'm pretty excited to see this.

[teppo]

Hey Ryan!

First of all, this all sounds very promising. In my humble opinion you are vastly underplaying your own skill in terms of design, but that's also why we can trust that you'll recognize amazing design once you see it. Looking forward to seeing what the team working on the design has cooked up 😉

Now, please forgive me for jumping directly into asking for stuff, but...

I know this is small thing, but it would be quite nice if the new admin made use of CSS variables wherever it makes sense; colors, font sizing, etc. (Or provided them as an alternative for non-core tools to use, in case it is not feasible to use them for actual admin styling.)

The reason I'm saying this is that I've built various admin tools that I wanted to look like the admin theme, and since there is (to my knowledge) currently no simple way to access existing colors etc. in CSS, any non-Uikit elements I've had to "hard-code" to use current styles. This includes the default green/cyan/blue color theme, current spacing and font size practices, etc. As a result said custom elements may look out of place once the theme is updated 🙂

(Just for the record: SCSS/LESS might be an option, but that feels like a lot of unnecessary overhead and complexity where vanilla CSS would easily suffice. I'd really like to avoid that if possible, and to me it seems like CSS variables are an easy and well supported alternative.)

Additionally: it would be awesome if accessibility was a consideration while creating this new admin theme. I know it has been considered to a point in the past, but has never been a major goal. Hopefully we can push things forward in this regard in the future. If there's something I can help, I'd be happy to 🙏

[FireWire]

  On 3/8/2025 at 8:04 AM, teppo said:

new admin made use of CSS variables

Expand  

I think this approach is an excellent idea and hopefully something that will be considered. In addition to the benefits @teppo described, using CSS really open things up for JS as well where getting/setting values via scripts could make admin development very dynamic. Laying some future friendly groundwork in CSS would be a major advancement.

[ryan]

@teppo Thanks and good ideas. CSS variables sound good to me too. But want to mention that this isn't a new admin theme, this is AdminThemeUikit with an improved look and feel. There isn't any change to the underlying markup or CSS structure. The AdminThemeUikit CSS is still present so folks can still use the original look too. Longer term maybe we'll do a whole new admin theme. This does actually feel like a new admin theme when you use it, even if it's technically not. 

[FireWire]

@ryan Makes sense. Really looking forward to seeing what y'all been cooking up! I paused the other day and appreciated all the quality of life improvements that have come over the years and value them as much as the big features. Almost can't wait. It's like Christmas for adults, who are also developers.

[bernhard]

There is a long open issue for UIkit to support CSS variables but unfortunately there seem to be no efforts in that direction: https://github.com/uikit/uikit/issues/4534

[Pixrael]

Great news! @ryan, for a completely new admin project, might you consider using HTMX, or something similar? It's perfect for PHP. I've used it on a large admin project, and it works wonders with ProcessWire. I also use these libraries to complete the package:

• https://github.com/gnat/css-scope-inline
• https://github.com/gnat/surreal

[teppo]

  On 3/11/2025 at 6:36 PM, ryan said:

But want to mention that this isn't a new admin theme, this is AdminThemeUikit with an improved look and feel. There isn't any change to the underlying markup or CSS structure.

Expand  

Thanks for the clarification! Still hoping that we can make some minor improvements, though.

Loosely related, but I'm not sure if you've noticed that there is a are a couple of comments related to one recent admin change 🙂

  On 3/11/2025 at 9:34 PM, bernhard said:

There is a long open issue for UIkit to support CSS variables but unfortunately there seem to be no efforts in that direction: https://github.com/uikit/uikit/issues/4534

Expand  

That sounds a bit disheartening.

I've never actually built anything from scratch with Uikit so I'm not too familiar with its structure, and I must admit that digging into AdminThemeUikit just now made my head spin, but it looks like variables are defined mostly in one place. Is that right, and if so, would it be an option to set those based on CSS variables?

That might not work with — or rather stay in sync with — custom admin styles, though.

Of course there's always the option of somehow duplicating LESS variables to CSS variables. This way they could at least be used in modules etc.

[AndZyk]

  On 3/11/2025 at 9:34 PM, bernhard said:

There is a long open issue for UIkit to support CSS variables but unfortunately there seem to be no efforts in that direction: https://github.com/uikit/uikit/issues/4534

Expand  

I guess that YOOtheme probably will implement CSS variables with UIkit 4. Here is an open issue for ideas and suggestions for UIkit 4: https://github.com/uikit/uikit/issues/3967

  On 3/13/2025 at 8:39 PM, teppo said:

I've never actually built anything from scratch with Uikit so I'm not too familiar with its structure, and I must admit that digging into AdminThemeUikit just now made my head spin, but it looks like variables are defined mostly in one place. Is that right, and if so, would it be an option to set those based on CSS variables?

Expand  

Yes, there is one partial file for variables, but I don't think you can easily change every variable to a CSS variable. Some variables use for example darken() and lighten() which I think don't work with CSS variables. I have tried it once, for some variables it is possible but for most not.

One simple enhancement I mentioned several times over the years would be to include the CSS source map in the AdminTheme. But it seems that I am only one with this wish. 😅

[artfulrobot]

  On 3/8/2025 at 8:04 AM, teppo said:

Additionally: it would be awesome if accessibility was a consideration while creating this new admin theme. I know it has been considered to a point in the past, but has never been a major goal. Hopefully we can push things forward in this regard in the future. If there's something I can help, I'd be happy to 🙏

Expand  

💯 this

For me there's three things that come to mind immediately here:

• All text should pass at least WCAG-AA standard, and ideally should pass AAA.
  e.g. .description uses  #8d939e which only has a contrast ratio of 3.09 making it inaccessible for a lot of users. It would only take darkening it to #717680 for AA standard or #525968 for AAA standard.
• Keyboard navigation: e.g. Escape key should cancel a modal - e.g. add a field or such.
• Javascript should not break forms' keyboard nav: e.g. hitting Enter after typing filter text on the Pages list should submit the form but instead it reloads the page without your filter text(!)

But I'm looking forward to seeing the new theme, perhaps some of these have already been considered if so 🥳

Edited Saturday at 07:35 AM by artfulrobot

[ryan]

@artfulrobot

  Quote

All text should pass at least WCAG-AA standard, and ideally should pass AAA.

Expand  

I don't know much about this, but interested to learn.  Thanks for the specific examples, I will give that a try. Usually when I've got low contrast text it's because it's supposed to be low contrast text, so that it doesn't catch the eye unless you are specifically looking for it. Kind of like disclaimer text, but maybe not quite that low contrast. So I guess it's a matter of finding something that is still low contrast, but not too low contrast. 

  Quote

Keyboard navigation: e.g. Escape key should cancel a modal - e.g. add a field or such.

Expand  

Not sure if the jQuery UI modals support that or not. Also a little worried about making them too easy to close (accidental keypress). But I will look into this. Or if you already know how to make it work, please let me know. 

  Quote

Javascript should not break forms' keyboard nav: e.g. hitting Enter after typing filter text on the Pages list should submit the form but instead it reloads the page without your filter text(!)

Expand  

I'm not sure I know what this specific example is, as there is no filter text on the pages list. Is that something added by a module? There is Pages > Find (Lister) but it does retain filter text when submitting the form with enter. 

[teppo]

  On 3/22/2025 at 1:47 PM, ryan said:

Thanks for the specific examples, I will give that a try. Usually when I've got low contrast text it's because it's supposed to be low contrast text, so that it doesn't catch the eye unless you are specifically looking for it. Kind of like disclaimer text, but maybe not quite that low contrast. So I guess it's a matter of finding something that is still low contrast, but not too low contrast. 

Expand  

"Low contrast, but not too low contrast" is one solution, while sometimes it may make sense to try to figure out an alternative approach entirely; e.g. instead of making something hard to see / low contrast you might consider hiding it behind a toggle, etc. (Perhaps not the best example, but that's the first thing that came to mind.)

Overall this is an interesting point because I definitely get what you're saying, but at the same time being able to read text is a pretty big deal in terms of accessibility. And it's also one that can be considered a low hanging fruit: identifying contrast issues is easy, and it's usually an easy fix.  As a general rule of thumb if a piece of text is worth being there, it should probably be visible to all users, and that means it should have enough contrast 🙂

If you'd like to get a better grasp of these things, I would recommend checking out browser extensions such as WAVE Evaluation Tool, or Accessibility Insights from Microsoft. Both have automatic tests that are super easy to use; while they may raise some false positives and may not catch all issues, they will point you to the right direction.

 

[FireWire]

  On 3/22/2025 at 7:34 AM, artfulrobot said:

ideally should pass AAA.

Expand  

As someone who has implemented accessibility measures before, AA is the standard for public non-governmental sites serving different abilities and satisfies all legal definitions of accessibility. Adhering to AAA standards means a full compromise of the design to achieve that rating and is a rarity. These ratings are also targeted at public facing websites where legal compliance is required.

A public facing site, i.e. the site that ProcessWire manages, should adhere to the standards that apply to the audience it serves and is the responsibility of the developer. The admin has a different audience.

With the new theme having flexibility in customization, as with @ryan mentioning the availability of CSS variables in the new design in a more recent update post, higher levels of compliance could be achieved by theming. Even if CSS variables were not available, the admin them can be (and has been) modified. If there are special use cases where developers using ProcessWire must provide an experience for users or clients that need additional levels of accessibility then it would be a good place to have some community help developing themes that meet more strict standards.

Consider this- ProcessWire itself is an application used for the production of content, not consumption of content. To that end, accessibility measures designed for content consumption should not be implemented at the cost of usability or preference for it's purpose and widest user audience. If someone needs the ProcessWire admin to look like this, then I and many other users, would kindly ask that they implement a theme to accommodate that and release it to the community as a module.

  On 3/22/2025 at 2:36 PM, teppo said:

And it's also one that can be considered a low hanging fruit: identifying contrast issues is easy, and it's usually an easy fix.

Expand  

This is a good target. Adjusting shades to help with contrast would help a wide audience with minimal impact on development costs. Tabbing and escape key binding are good. Considerations at this level are general good practice.

The differences between applications (ProcessWire) and websites (a product ProcessWire can be used to produce) is a good thing to keep in mind. It would be difficult to expect the end user of ProcessWire to have the ability to use all functionality and manage a site on the back end using a screenreader and keyboard alone which is one of the goals of accessibility even at the AA level.

I say this as a person currently developing a website for a nonprofit organization that serves the Parkinson's disease community. Their site needs to be accessible (we are targeting AA) but they would never consider having the admin they work with be accessible by the people they serve.

[FireWire]

  On 3/22/2025 at 1:47 PM, ryan said:

Not sure if the jQuery UI modals support that or not. Also a little worried about making them too easy to close (accidental keypress). But I will look into this. Or if you already know how to make it work, please let me know.

Expand  

An escape key binding could be implemented with a snippet of code that looks for a modal element with a class or attribute defining it as active. So a binding that looks for that and executes a click action on the nearest close button or programmatic closing may be doable. That's a hypothetical based on instances where I've implemented it in my projects though, so just a cursory thought. I find myself reaching for the escape key often to exit windows, so it would be a welcome feature if implemented!

[teppo]

  On 3/22/2025 at 4:41 PM, FireWire said:

The differences between applications (ProcessWire) and websites (a product ProcessWire can be used to produce) is a good thing to keep in mind. It would be difficult to expect the end user of ProcessWire to have the ability to use all functionality and manage a site on the back end using a screenreader and keyboard alone which is one of the goals of accessibility even at the AA level.

I say this as a person currently developing a website for a nonprofit organization that serves the Parkinson's disease community. Their site needs to be accessible (we are targeting AA) but they would never consider having the admin they work with be accessible by the people they serve.

Expand  

Public facing part of the site is no doubt the one with biggest impact, and it's also where accessibility is most commonly a requirement, legal or otherwise. That being said, I have also come across cases where same requirements have applied to the admin interface.

I would say that it is somewhat rare requirement (sadly — in my opinion it should really be more common requirement) but not unheard of.

This also depends on what you're doing in the admin: at least some are building entire applications in the admin, which often means that there is a more varied user base, which in turn means that accessibility tends to come up more often. For an example in one project I was able to navigate around this issue by building a separate custom admin section in the front-end for the most critical features; not really something I would prefer to do 🙂

It is true that application type interfaces are more complex to do in accessible manner. Drag and drop, notifications, and editor interfaces are good examples of things that can get a bit more involved. Drag and drop is a good example, as one essentially needs to implement two methods of operation:

  Quote

All functionality that uses a dragging movement for operation can be achieved by a single pointer without dragging, unless dragging is essential or the functionality is determined by the user agent and not modified by the author.

Expand  

Anyway, long story short: I for one am not suggesting that we overhaul entire admin interface to be accessible in one huge step. That would not be feasible. One step at a time 🙂

[teppo]

  On 3/22/2025 at 4:50 PM, FireWire said:

I find myself reaching for the escape key often to exit windows, so it would be a welcome feature if implemented!

Expand  

Same! I was literally just yesterday working on some content in the admin and found myself whacking the escape key to close a modal. Did not work 🙊

[artfulrobot]

Laws and business cases aside, my points were more along the lines of: hey, with a smidgen of awareness we can make nice things that more people can enjoy using. Sure, at the extreme end it can be an enormous task that requires awareness, commitment, funding, expertise, focus groups etc. etc., but let's not make perfection the enemy of progress.

On colour contrasts, I have good eyes (fading as I'm middle-aged, but 20:20 vision with glasses) and am not colourblind. I'm part of the 80% majority in the UK who does not have a long term disability. I can afford and have chosen to spend cash on high quality screens. I love photography and art and attention to subtleties in colour. I still struggle with small, low contrast texts but at a squint I can read them, it's just not pleasant. I make websites for a living, so sometimes I just hit F12 and change the CSS, and for some sites I use a browser plugin to always add my own CSS. So even with all my privilege, this isn't a great experience. Many people don't have great eyes or expensive monitors or tech skills to edit CSS and will literally not be able to read such texts and there's just no need for this.

The WCAG standards provide guidance on colour contrasts and this is a big easy win. Meeting the AA standard on colour is such a low level requirement that most browsers have dev tool support for this built in and have had for years.

Screenshot of Firefox's dev tools showing a node from this site; I've clicked on the CSS "color" rule and it shows a colour picker that includes a contrast ratio calculation: 4.02 with a red exclamation mark and a tooltip reading: "Does not meet WCAG standards for accessible text."

Chromium-based browser screenshot of devtools: again, the CSS panel is shown and I clicked a colour and the colour picker has the contrast ratio calculated, 4.01, and text: AA: 4.5 with a red symbol meaning No-pass (this is telling you that 4.01 < 4.5), and AAA: 7.0, not passing. Lines on the chart show the colours that would be accessible against the two standards.

 

Re: keyboard accessibility: For a while I developed RSI which meant I could not use a mouse without significant pain. This was obviously very frightening for me given how I make my living. At this time I really learnt the value of keyboard accessible interfaces - they literally made it much less painful for me to operate a site (admin or front end). And disability aside, being a [neo]Vim user too means I know that it's often just a lot more efficient to use the keyboard instead of having to reach for a mouse, so these are my reasons for suggesting this.

Thanks for being open and interested in these accessibility suggestions @ryan  I think upping contrast to 4.5 (AA) would be a great first step to making ProcessWire something a lot more people could enjoy using and as others have pointed out, making an admin system that also supports 3rd party modules to make it more accessible, e.g. through use of CSS variables, also makes ProcessWire a good framework for people wanting or needing[1] to make sites more widely accessible.

 

[1]: 86% of people implementing accessibility standards do it because they feel it's the right thing to do. 8% do it for compliance reasons, 4.5% do it for business advantage, 1.1% do it for legal reasons: https://webaim.org/projects/practitionersurvey3/

[bernhard]

It would be great to have an API for keyboard shortcuts that is used across the admin and that can be used by module developers in the same way, something like

ProcessWire.on('keydown.cmd+s', ...);
ProcessWire.on('keydown.esc', ...);

Even greater with support for javascript hooks.

And maybe some kind of attribute click magic:

<div>
  1.2.3.4
  <a
     href
     pw-click-copy='parent'
     title='Click to copy IP address to clipboard'
     uk-tooltip
  >
    <i class='fa fa-clone'></i>
  </a>
</div>

Early stage ideas but these would have been helpful for many of my modules for sure.

Edit: Maybe instead of callbacks we could have attribute notation for keyboard shortcuts as well?

<button type="submit" pw-keydown="cmd+s">
  Save
</button>

 

[artfulrobot]

  On 3/23/2025 at 10:11 AM, bernhard said:

Edit: Maybe instead of callbacks we could have attribute notation for keyboard shortcuts as well?

Expand  

Or do it in a standards-compiant way?

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

 

[diogo]

  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

Expand  

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.

Expand