Leaderboard

Like last week, I’m still working on all the same things: PW site, client stuff here and there, and even the HVAC stuff. They replaced our heating/air systems on Wednesday, but not everything is working quite as it should, but that’s another story that's still ongoing. A couple weeks ago folks were asking about CSS variables/properties for the new AdminThemeUikit look. I’m not that familiar with that part of CSS yet, but luckily the people coming up with this design are. And it turns out they are indeed using CSS variables/properties for this. I think this means you’ll be able to override them with your own colors, perhaps in the AdminThemeUikit module settings, or with a CSS file, I’m not yet sure, but will find out more in the next week. I’ve seen a few different color schemes specified using it, and they are really nice. Thanks for reading and enjoy the weekend!

Hi all (yet again)! I'm still at it with some new buttons added, now up to 28 in total. New buttons include Form, LightboxGallery, Map, and CalloutImage, as well as a reverse color CalloutImage. Happy building! 😎

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. 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.

💯 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 🥳

Add a 2nd build file that only uses parts of your CSS/less. / ├── dist │ ├── backend.css │ └── frontend.css └── src ├── _index-backend.less ├── _index-frontend.less └── less ├── blocks.less ├── buttons.less └── ... In the build file you only import those parts you need/want in the backend or WYSIWYG editor, while the frontend will have everything. // _index-backend.less // we only need the buttons in the backend @import "buttons.less"; That's how I structured my .less/.sass/.scss files.

Back when I started this thread I tried multiple ways, modules, and custom exports. From JSON to AppApi to GraphQL and everything in-between. I still use basic JSON in some projects or just grab what I need via HTMX nowadays. I pull in only simple data via JSON I might need on build time or fully rendered HTML with HTMX in my AstroJS projects. Whenever I start a new project and need a MVP-like skeleton of it, I go with static content in Markdown/MDX in AstroJS, later on I'll migrate to 100% ProcessWire in most cases. It just works, I feel home, know how to handle stuff, have everything I need and with ProCache, LoginRegisterPro, and FormBuilder I can keep everything on my server and don't need things like Supabase, Neon, FormSpark or whatever. So to finally answer your question: no, not anymore

Hey all! I've been creating new block/widget buttons for the current project I'm working on and wanted to share them in case they may be useful to others. They're SVGs intended to complement the style of buttons that come with RockPageBuilder. This post has been updated with a link to a Github repository containing all of the buttons currently available. New buttons have been added. Existing buttons have have been tweaked for quality and consistency. Download from or fork the Builder Buttons Github repository Rather than keep this post up to date with every button that is added, visit the Github repo to see the most current example and download/clone buttons for use in your projects. Buttons include: Accordion Announcement Articles Audio Bios Call To Action Card Over Image Code/Embed Events Image Image Carousel Image Mosaic Image Roll List Lists Products Reviews Video Weather Preview (not in order of list) If you find them useful, let me know what you think!

Hi there, I've gone with pagegrid for a client site, and it's been working pretty well. I really like the ease that my clients have modifying content themselves, it makes processwire work for the kind of hands on client that i'm working with. But I'm having a issue with the home page- I keep getting a gateway timeout on the edit page. No other page has this issue. The issue has been present for a 2-3 days now. Anyone have any idea what might be causing this/ has anyone experience the same thing? If it were a personal site I would just wait and see, but as i'm on a slight deadline, I figured i'd reach out and see if anyone has advice. Thanks!

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 Amen to that! I think I like your approach here. I also think I may experiment with using Astro as the application and making PW available for build time data retrieval via 127.0.0.1:port# and the same PW instance available via a subdomain for post-page load endpoint requests and other tasks if needed. For reference, there are a few articles discussing this sort of approach using Wordpress headless.

I'm a bit short in time right now so I might have to write a follow-up to give you a real and more complete answer here. But in the meantime - a short summary: each and every client/side project of mine get's a click-dummy of the final product to see how it could work out, what's needed and so on. I use Astro JS for that as it's super flexible to work with, I can deploy it somewhere at Netlify, Vercel, or Cloudflare. Each commit is a new build. I can share it with everyone - frontend and backend-wise. It's more or less just HTML, CSS, JS - some parts of it might have a TailwindCSS or AlpineJS flavor but still super basic. And the big plus: ALL build steps (TailwindCSS, AlpineJS, ...) are already in place. If needed I can connect it to an API to fetch articles, news, or whatever kind of data to make it look more real or to go super fast - especially when migrating from WordPress where there is a RestAPI or GraphQL almost always in place already. For sideprojects I connect to api.domain.tld, grab JSON and render out either pages or just parts of the project on-build. for side projects in very early stages that would be the state for the next 3 to 6 months to see if the project get's some kind of traffic - for client projects this is the base to start the real work. from there I take all the component and move them from .astro to .twig - the difference is so minimal I could use Regex to make the changes most of the time. feeding all layouts, components, partials, blocks, however we want to call those code snippets into ProcessWire is pretty easy, when you know where things have to go and most of the time you only change the parts that define the source - so from a JS fetch() to a $pages->find('...') - and of course you have to build out the ProcessWire backend stuff, hooks, automation, and whatever you need or want. Some would say there are a lot of unnecessary steps in this process and they could be right, but I prefer to test projects early on and hate to look at Figma files or Illustrator screenshots. So there is that. I always worked that way and that will probably never change. On the technical site you have think about 2 systems running side by side. Astro JS on Netlify, Vercel, Cloudflare or a VPS with NodeJS and ... lots of other stuff ProcessWire with database and everything it needs on a sub-domain. You could fit everything onto one server but it can be quite painful to get this up and running so I use a regular hosting provider for ProcessWire and one of those mentioned above for Astro JS. The output is, most of the time, 100% static and build on-demand with data and content available at that moment. You could make it more dynamic with AlpineJS or HTMX but only for small parts, and not for articles and news - as those wouldn't exist within the static build. As this turned out to be broader as expected please feel free to ask about more details where needed.

Hey @FireWire great thank you! I see some blocks that seem to be regular fontawesome 4 icon buttons, like the one with the map or with the calendar. You are aware that you can use any fontawesome icon for the buttons via the "icon" property of the block? Or are your blocks different?

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 🙊

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: 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 🙂

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!

"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.

Thanks @markus-th and @wbmnfktr. You've given me good feedback to consider. I had an issue today with the headless WordPress site I referenced above that has me thinking about this differently. In short, the WPGraphQL plugin broke from an update and I decided to try converting what I had over to REST with Claude AI. In addition to a lengthy prompt I fed it JSON of all of the custom fields and GraphQL queries I was using on the site. That worked really well and only required minor fixes to completely rebuild what I already had. ProcessWire has great documentation, has been around for a long time, and can export templates and fields in JSON format. I just need structured data of each page, nothing wild. I'm going to see how well the machine can generate what I need and if it seems repeatable. If anyone cares I can post how it goes. If you're tired of the "LoOk aT WhAt i MaDe wItH Ai mOm!" posts, then I'll keep it to myself 😉

Have you checked your server load? This is my most common case for this timeouts.

@Robin S - you are great. That's fantasticially helpful. I don't think I've used findRaw before but it worked a treat. According to Profiler rebuilding the markers has gone from 31 seconds to 0.3 secs: It took me a couple of goes to convince myself it was actually rebuilding the markers and not pulling from cache - but it is!

If you already have a python script that should be quite easy to do with the help of AI In PW just create a textarea field and make sure to let it use a monospace font so that you can properly paste/write your lyrics. (you can do that in /site/templates/admin.less) Then just grab that content and use your PHP method/function that your AI wrote for you and generate the html that you output on the frontend. PS: Nice idea also by @diogo 🙂

Awesome, thank you! This works perfectly and I have never allowed images in RTE fields, so I'm safe here 🙂 Thx for the note! I have added this as a tweak to RockAdminTweaks: https://github.com/baumrock/RockAdminTweaks/blob/dev/tweaks/General/RemoveVariations/RemoveVariations.php

$pages->findRaw() will be helpful here. It's hugely faster than $pages->find() and easier to work with than SQL queries. You could do a couple of searches and connect the resulting data by repeater page ID. Example: // Ensure PagePaths module is installed so that URL is available to findRaw() $shop_data = $pages->findRaw("template=shop", ['title', 'url', 'locations'], ['nulls' => true, 'flat' => true]); // Here you could also get other fields from the repeater pages as needed $location_data = $pages->findRaw("template=repeater_locations, check_access=0", ['location'], ['nulls' => true, 'flat' => true]); $shops = []; // Loop over the shop data and get the lat/lng for each location, matching by repeater page ID foreach($shop_data as $id => $item) { $data = [ 'title' => $item['title'], 'url' => $item['url'], 'locations' => [], ]; $location_ids = explode(',', $item['locations.data']); foreach($location_ids as $location_id) { if(!isset($location_data[$location_id])) continue; $data['locations'][] = [ 'lat' => $location_data[$location_id]['location.lat'], 'lng' => $location_data[$location_id]['location.lng'], ]; } $shops[$id] = $data; } db($shops);

Hey @TomPich, I don't know if you gave it a try, but I just did. Although I was able to get the button to work after manually modifying InputfieldTinyMCEConfig.php, I wasn't able to get it to actually work using the default interface of a Textarea field's Input config for TinyMCE fields. As the Accordion plugin is not an external plugin, there doesn't seem to be a simple way to use the UI of the field's Input config settings to enable the accordion. I played around a bit, and did get it to work, but after saving the injected "accordion" (details/summary elements), the HTML of those elements got stripped via HTMLPurifier, so there's another problem. Turning off HTMLPurifier allowed it to work, though I'm not sure if you'd want to do that. There's another recent topic where someone is attempting to adjust HTMLPurifier a bit. Currently, it seems that to get the Accordion plugin to work until/unless the core TinyMCE module is updated to include it, you'd currently have to migrate your customized settings via the field's UI into a custom JSON that overrides what you have set via the field UI. Example "Custom Settings JSON" (PW default + accordion): { "plugins": ["anchor", "code", "link", "lists", "pwimage", "pwlink", "table", "accordion"], "toolbar": ["styles bold italic pwlink pwimage blockquote hr bullist numlist table anchor code accordion"] } After playing around with the accordion interface, I don't find it quite as intuitive as some other elements, but it does work.

A very quick and easy solution would be to add css like this to your admin.less file: li.Inputfield_tmp2 input { margin-top: 30px; } Before: After: You need to adjust the field names in your css though.

$rf = "repeater_field"; //repeater field name $pt = "basic-page"; //page template name foreach($p->$rf as $r){ $np = new Page(); $np->of(false); $np->template = $pt; $np->parent = $page; foreach($r->fields as $f){ $np->$f = $r->$f; } $np->save(); }