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!

Hello ProcessWire forum, I am sharing a new PW install developed for artist Laskfar Vortok, which uses the ProFields module, Rockfrontend, RockDevTools, MarkupRSS, and can even display its contents without Javascript enabled (for low-power devices and browsers). It includes a project archive, simple and straightforward project pages, project category pages, and a CV which utilizes a Repeater Matrix for adding and organizing its constituent elements. All of the contents for this page were imported from a legacy WordPress site using a methodology which I describe in detail here & here. Essentially, the contents were ingested from WordPress REST API endpoints (post data, images, tags) routing them to appropriate destination custom fields within PW. A mostly seamless migration, which necessitated some minor manual adjustments and tweaks. Many greetings, and thanks again for the amazing flexibility of ProcessWire.

This one's been a long time coming, but this week we launched a site for the UK charity INQUEST who provide support for families involved in state related deaths. This was part of their 40th Anniversary and the site showcases significant milestones and events from their archive over the last 40 years. There's an interactive timeline, case studies and oral histories. Even given the difficult subject matter we're really pleased with the result: Behind the scenes, the modules we used were mostly the usual suspects, Tracy Debugger, ProCache etc. Also RockFrontend specifically for the ajax routing (would love that as a separate module @bernhard ) which we used with HMTX in various places. Not sure we really needed to use HTMX on this one but hey, it is very handy. One module we made use of which we hadn't used before was @Richard Jedlička's PDF fieldtype so that we could generate thumbnails of PDF documents. There are a lot of historical documents on the site and having the thumbnails generated automatically was really handy. The site seems to have gone down really well. And we actually had a launch party - it's been years since that happened... https://history.inquest.org.uk/ Oh, and it does very nicely in Lighthouse and gets A+ in Observatory as well 🙂

Some time ago, I learned you can add the "download" attribute to a link to force a browser to download the file when its clicked, like this: <a download href="my-awesome-file.jpg">Download</a> What I didn't realize until today is that you can actually specify a filename as a value for the download attribute like this which will automatically use that filename instead!: <a download="my___awesome___file.jpg" href="my-awesome-file.jpg">Download</a> This is incredibly convenient because it means if I want a user to download the same exact file 3 times but with specific filenames for each, I can just do this: <a download="my___awesome___file-1.jpg" href="my-awesome-file.jpg">Download 1</a> <a download="my___awesome___file-2.jpg" href="my-awesome-file.jpg">Download 2</a> <a download="my___awesome___file-3.jpg" href="my-awesome-file.jpg">Download 3</a> Furthermore, as you can see, I am using a triple underscore which ProcessWire cleans up and changes to a single underscore, as well as other changes (such as lowercasing everything) when uploading to a pagefile field. I want my filenames to be exactly as I upload and I know there's ways to prevent ProcessWire from doing that, but using the download attribute in the way I described works perfectly for my use case.

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.

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

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

It seems to work if you allow edit access on the parent template in the normal way via the PW admin... ...and then disallow editing on the parent template in a hook to Page::editable() $wire->addHookAfter('Page::editable', function(HookEvent $event) { /** @var Page $page */ $page = $event->object; $user = $event->wire()->user; // Return early if PW has already determined that the user is not allowed to edit if(!$event->return) return; // Don't allow users with the "editor" role to edit pages with the "colours" template if($page->template == 'colours' && $user->hasRole('editor')) $event->return = false; });

Did this thread cursed me? (jk) Monday first hour and I have a site that's going through very odd gateway timeouts 🤣 EDIT: Indeed, server load! PHP hits hard, always have a cache layer! 😄

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/

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.

@protro I use this module with htmx and it works nicely. It's pretty easy to do and it can all be done in HTML without handwriting JavaScript or parsing JSON. Here's a simple example. It should work, it may need tweaking but the concept is accurate. <!-- Your search form --> <style> .search-box { position: relative; } .search-indicator { align-items: center; display: flex; inset: 0; justify-content: center; opacity: 0; pointer-events: none; transition: opacity .3s; } /* Style your AJAX indicator as you please */ .htmx-request .search-indicator, .htmx-request.search-indicator { opacity: 1; pointer-events: auto; } </style> <div class="search-box"> <form hx-get="the search URL here" hx-target="#search-results-container" hx-disabled-elt="button[type=submit]" hx-indicator=".search-indicator"> <input type="search" inputmode="search" name="q" placeholder="What would you like to find?"> <input type="submit" value="Search"> <div id="search-results-container"> <!-- Search results will load inside this div --> </div> </form> <div class="search-indicator"> <span>Searching...</span> </div> </div> hx-get tells htmx to request the page from the URL you provide hx-target tells htmx where to put the markup that it receives back from the AJAX request, it accepts any CSS selector hx-disabled-elt directs htmx to disable the submit button during the request to prevent people from clicking the button multiple times, it accepts any CSS selector hx-indicator isn't required, but tells htmx which element to add the .htmx-request class while the request is in flight and then remove it when the results are loaded for a nice "loading" display. It accepts any CSS selector On the search page all you have to do is render the results that will appear inside #search-results-container, just markup. This is a rough example, but just illustrates how simple it can be. You'll have to tailor this to your needs. You can probably use markup that the SearchEngine module generates, but I haven't used that before myself. <div class="search-results"> <?php if ($searchResults->count()): ?> <ul> <?php foreach ($searchResults as $result): ?> <li> <p><?=$result->title?></p> <a href="<?=$result->url?>">View Page</a> </li> <?php endforeach ?> </ul> <?php else: ?> <p>There were no search results for "<?=$input->get->q?>"</p> <?php endif ?> </div> That's the only markup you need. You'll probably need to do some additional work to make things like paging happen, but it's all doable. I cobbled this together based on some code I've already written so it's just a starting point and probably needs some tinkering. Here's a handy reference of htmx attributes that will let you do anything you need.

Good question. It has to do with an order and production management system I'm developing. Imagine you ordered a blanket with a personalized design, like a family photo of your choosing, and your order is for 3 of them. That's a print-on-demand product that has to be ultimately manufactured by a fulfiller. A person in the fulfiller manufacturing company will get this order and see it as 3 separate "production jobs" (not one production job with a quantity of 3 -- it's done this way because each manufactured product has to have specific status tracking and other data associated with it), but since it's the exact same product and design, the artwork that needs to be printed (a jpg or png) is actually the same across all 3, and they all point to the same file (won't get into the details of how it's all structured, it's very complex). However I also designed the system so that an employee can understand a production job just by looking at the filenames of the artwork files they downloaded from the manufacturing system, which is required because after they download that file, it has to go through special ripping and printing software. The filename format would be like this: [manufacturer-location]___[provider]___[ship-by-date]___[product]___[production-job-id-x].png That "x" at the end is represents the number based on the quantity of that exact personalized product. A realistic example would be like this based on the quantity of 3 blankets that were originally ordered: losangeles___somebigecommercesite___2025-03-28___blanket-60x80___123456-1.png losangeles___somebigecommercesite___2025-03-28___blanket-60x80___123456-2.png losangeles___somebigecommercesite___2025-03-28___blanket-60x80___123456-3.png So going back to the download attribute and custom filenames, that original file may have been originally called 123.png (where '123' is the id of repeater the artwork file belongs to since that repeater has a single-file field), but when it is downloaded through the interface by a person in the manufacturing facility, it will download as losangeles___somebigecommercesite___2025-03-28___blanket-60x80___123456-1.png, -2, thanks to the download attribute. Those downloaded files can then easily be loaded into a ripping software and the worker won't need to "think" about which ones had multiple quantities since that is fully expressed as individual files.

Modernism Week is a nonprofit organization dedicated to celebrating and providing education about midcentury modern architecture in Palm Springs, California- the epicenter of the modernist architecture movement. The 10 day event takes place in every year in February and features over 200 unique activities that draw 125,000 people from around the world. At Modernism Week you can tour iconic homes and neighborhoods, attend a cocktail party at Frank Sinatra's house, see live music, watch films, and attend engaging lectures. The organization also engages in preservation efforts to keep historic buildings and landmarks protected for future generations, as well as providing scholarships for students pursuing degrees in architecture, preservation, engineering, and design. https://modernismweek.com Tech Alpine.js htmx Tailwind CSS For a full list of technology, software, members of the web team, and a list of thanks to module developers who made this site possible, view the humans.txt file here. I posted a deep dive into the behind the scenes features and application development that handles automation and extensive use of powerful ProcessWire features over on this forum post. It was a pleasure to work with ProcessWire on this project and its amazing API and features made it all possible.

I think for this specific "hierarchy" you might benefit from looking at AdminRestrictBranch and if it doesn't exactly fit your needs you'll get some ideas for hooks within it's code, although I understand you are new to ProcessWire but from the looks of your project you're in for a ride! Keep in the touch and welcome to the forums! So you might benefit from having various roles that fit the "branch" where you want to work on.

I've just made some update on the module. I added some usefull settings to the module, so you can now select row and seat order (left or right or Up or Down) I also added the seat design option. To view seats as square or as simple actual css seat. And you can now change the Labels for Row and Stage For displying seats on frontend, use: <?php $seatingModule = wire('modules')->get('TheaterSeating'); echo $seatingModule->renderFrontendSeatingChart($page); ?> If you don't see the css seat icon on frontend add this JS to your template. <script> document.addEventListener("DOMContentLoaded", function() { document.querySelectorAll(".seat").forEach(seat => { if (!seat.querySelector('.left-armrest')) { const leftArmrest = document.createElement('div'); leftArmrest.classList.add('left-armrest'); seat.appendChild(leftArmrest); } if (!seat.querySelector('.right-armrest')) { const rightArmrest = document.createElement('div'); rightArmrest.classList.add('right-armrest'); seat.appendChild(rightArmrest); } }); }); </script> Hope you like it 😉 R Download here: TheaterSeating.zip

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!

From the page you linked to:

You can use FieldtypeConcat, or do it with a hook. https://processwire.com/modules/fieldtype-concat/ // Merge First and Surname for Title and Name if($page->template == 'some-template') { // Don't change name field if page is going to trash if(!$page->isTrash) { // If the fields that make up the title are populated if($page->first_name && $page->surname) { // Set the title $page->title = "{$page->first_name} {$page->surname}"; // Sanitize the title as a page name $name = $event->wire()->sanitizer->pageName($page->title, true); // Set the page name while making sure it auto-increments if there is a sibling page with the same title $page->name = $pages->names()->uniquePageName($name, $page); } } }

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 🙊

@elabx There are several methods to use Vite or Alternatives with ProcessWire. @wbmnfktr's suggestion is one of them. You can make certain checks in your vite.config.js file and implement this within your config file as well. You can send extra parameters and check these parameters in your config file to perform operations accordingly, for example: npm run build --my-parameter=tinymce. You can also use Dotenv and create multiple environment files like .env-tinymce, .env-frontend, .env-another-style, and then pass a parameter to your build script: npm run build --env=tinymce. After that, you can do what you want inside your vite.config.js file. When you install this module you will have simple vite setup under site/templates directory. There is an .env file, we use this file for live reloading.example .env file also you can use it for your needs.

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!

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 😉

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 everyone! Finally I have time to post a detailed developer walkthrough for PAGEGRID. I have the feeling that many people don't know how flexible PAGEGRID actually is as a developer tool. I think this is mainly due to the fact that most videos are showing the no-code features of PAGEGRID. But since these features are completely optional and PAGEGRID has a lot more to offer, I've put together a video walkthrough to show you exactly what I mean. My hope is that it'll give you a clearer picture of how PAGEGRID can fit into your projects and help you decide if it's the right tool for you. Please take a look at the video below! I think you'll be surprised at what PAGEGRID can do. PAGEGRID's core concepts (video summary): Your markup: Unlike many other site builders PAGEGRID gives you complete control over the markup and structure of your frontend. You can use PAGEGRID to build specific sections or parts of your custom coded website or you can use it as a full-blown site Builder that can work without any coding. Everything is a page: PAGEGRID items are ProcessWire pages that are defined through native ProcessWire templates and fields. Control what clients can edit: PAGEGRID offers an intuitive editor experience that's easy to learn for clients. Editing and design features can be controlled through ProcessWire’s native roles and permission system. Your CSS: You can use your code editor to write CSS or you can bring your own CSS framework. PAGEGRID makes no assumptions about your CSS code. And it’s not just for Grids, display properties like Flexbox, Block or Inline-Block are also supported. Nesting: A powerful feature of PAGEGRID is nesting and while this feature is completely optional it's quite useful for a lot of cases. You can define a block as a container and can define what kind of templates are accepted for the children. This can be used for layout purposes or to group items together, another example might be a slider or gallery block that the user can add items to or basically any repeatable content that you might want to put inside a block. Developer walkthrough: Developer Documentation: https://page-grid.com/docs/#/developer/ How to create a custom block: Documentation for creating blocks: https://page-grid.com/docs/#/developer/blocks Try PAGEGRID for free PAGEGRID is not free. However, you can try PAGEGRID on your local machine or on a test server as long as you need to make sure it is the right tool for your next project. … and when you’re convinced, buy your license. Installation PAGEGRID (FieldtypePageGrid) is listed in the modules directory, you can install it like any other module. See the install guide for more information. Recent Updates (2025) Performance improvements (markup cache integration) (march) Quick add feature (february) Symbols and Patterns (january)

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!

You're right. The problem is on my side. I have another hook Errormessage::render to add the font awesome icon on the errors. Problem solved.

No, this could not be a reason, because you are also using these lines of code to manipulate the classes: $checkbox->getFieldWrapper()->setAttributes(['data-uk-grid', 'class' => 'uk-grid-small']); $checkbox->getLabel()->wrap()->setAttribute('class', 'uk-width-expand'); This methods are working in the same way as the getErrorMessage() method. I cannot tell you, why getFieldWrapper() and getLabel() works, but getErrorMessage() not. As written before, in my case everything works as expected. If you cannot find the cause, please use the hook method to get your desired result.

Take a look at the form field class file (https://github.com/juergenweb/FrontendForms/blob/main/Formelements/Inputelements/Inputfields.php). There you can see that an inputfield consists of various parts (wrappers, label, error message, success message, description, notes,..) Every element can be grabed an manipulated via a get....() function getLabel() getErrorMessage() getSuccessMessage() getDescription() getNotes() getInputWrapper() getFieldWrapper() Maybe this is not well documented inside the docs, but now you know it 😉

Hello @PWaddict Instead of using a Hook for adding the grid class to the error message, you can also use the following: $checkbox->getErrorMessage()->setAttribute('class', 'uk-width-1-1'); Best regards

Thank you @Juergen Here is the final code in case anyone wants to use the grid (UIkit) on a checkbox: $checkbox = new \FrontendForms\InputCheckbox('checkbox'); $checkbox->setLabel('My Checkbox Label'); $checkbox->setRule('required')->setCustomMessage('My custom required text'); $checkbox->getErrorMessage()->setAttribute('class','uk-width-1-1'); // Add uk-width-1-1 to prevent the text displayed as part of the grid $checkbox->getFieldWrapper()->setAttributes(['data-uk-grid', 'class' => 'uk-grid-small']); $checkbox->prepend('<div class="uk-width-auto">'); $checkbox->append('</div>'); $checkbox->getLabel()->wrap()->setAttribute('class', 'uk-width-expand'); $form->add($checkbox);

Hello @PWaddict You are absolutely right - the position change will not taken into account. I have fixed this now. Please replace the following file: https://github.com/juergenweb/FrontendForms/blob/main/Formelements/Inputelements/Inputfields.php After that the position change should work, but please give me a feedback if everything works now as expected. After that I will bump up the version of FrontendForms. To get the desired markup, you have to do something like this: $form = new \FrontendForms\Form('inputfieldtest'); $form->setMinTime(0); $form->setMaxTime(0); $form->setMaxAttempts(0); $form->setErrorMsg('Ouups! There are some errors.'); $form->setSuccessMsg('Congratulation! There are no errors.'); $form->appendLabelOnCheckboxes(true); // set it here to true or in the backend config // add checkbox $checkbox = new \FrontendForms\InputCheckbox("checkbox"); $checkbox->setLabel("Checkbox Label"); $checkbox->getFieldWrapper()->setAttribute('class', 'uk-grid-small'); $checkbox->prepend('<div class="uk-width-auto">'); // add div before the input $checkbox->append('</div>'); // add closing div after the input $checkbox->getLabel()->removeAttribute('class')->wrap()->setAttribute('class', 'uk-width-expand'); // wrap the label element $form->add($checkbox); $button = new \FrontendForms\Button('submit'); $button->setAttribute('value', 'Send'); $form->add($button); if($form->isValid()){ print_r($form->getValues()); // do what you want } // render the form echo $form->render(); Take a look at the checkbox element. I have done some manipulations to add some classes and extra divs. I guess you are using the UIKit markup and if so, I think you also have to add the data-uk-grid attribute to the form if you are using grids (but not sure). I think you can image how it could be done to get the desired markup at all. If you have problems, please post the complete code for the form . Best regards

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

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!

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?

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.

Thanks for posting this, I was about to as something similar. I'm not sure the “Unique” status is a good fix to what I'm after doing. It looks like a hook per @Robin S‘s code would do the job nicely. I love PW. One thing I do think would be nice though for a future version would be for the core to offer some of the data integrity features of a rational database but managed through template and page settings: Something to mimic CASCADE and RESTRICT so that in a page reference, for example, you can restrict it being deleted if another page references it Make a field (of fields) unique as above

@FrancisChung Thanks for writing this tutorial, but I'd suggest changing the title. You're describing functional or integration tests and not unit tests. Unit tests try to test the smallest units of software with as few external dependencies as possible (e.g. a method or a class). Testing browser output is possibly the largest testable unit of a website. I know that these names are almost never used 100% correctly, but I think in this case it would really make sense to correct the terminology.

$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(); }

Another thing you can do is hook Pages::added (only called for new pages, not when re-saving existing ones) and in your hooked function set the page name to the page id, which is already part of the page at that point.

This is the nature of how the ajax uploading works, as it triggers a page save (though saving only the field you upload to). One way we could solve it is to add a status field to the file/image fieldtypes, giving them a way to identify a file as unpublished. Not sure how simple it will be to implement, but this is one of the things I've had on my list for awhile. If it comes up more often, I'll definitely bump it higher up the priority list.