Leaderboard

New Figma to PageGrid Importer From design to production in no time, with the new Figma to PageGrid Importer. At our studio, Konkat, we do all our design work in Figma because it lets us move and iterate quickly alongside our clients. While AI is great at spinning up generic, cookie-cutter layouts, true professional value lies in creating websites genuinely custom-tailored to a client. For that level of work, pure text prompts simply don’t offer the layout precision you need—writing a description will never match the intuitive control of direct visual input. But as any developer here knows, turning a finished design into a live, client-editable website usually requires a lot of manual layout replication before you can get to the core development. Even though PageGrid is already a massive speed upgrade, manually recreating a canvas layout element-by-element is still a time-consuming assembly phase. It eats up hours better spent on deep development, custom logic, and polished execution. That’s exactly why I (with the help of Claude Code) built the new Figma Exporter plugin and a native PageGrid Importer module for ProcessWire. It compresses hours of manual layout replication into a five-second automated import. By handling the structural translation instantly, it lets you skip the repetitive setup entirely and jump straight into the fun stuff: custom animations, fine-tuning, and high-level development. Instead of just telling you what it does, I want to be completely transparent about how it was built, why we intentionally avoided a "live AI" generation solution, and how it changed my perspective on building dev tools. Why We Rejected Live AI Generation When I started working on this, my first instinct was to leverage the power of AI agents directly during the import process. I tried using Claude via a live Model Context Protocol (MCP) setup to directly read my active Figma canvas and dynamically generate the PageGrid layout on the fly. Honestly, AI is surprisingly good at understanding how to build a layout in PageGrid now, and the initial results were already incredibly close to the original Figma designs. Using MCP is a really interesting alternative, but for daily production work, relying on a live AI connection just didn't make sense for a few major reasons: It was unpredictable: Every single time I ran the generation on the exact same layout, the resulting code structure came back slightly different. It was slow: Relying on live AI cloud prompts meant waiting for the model to think, stream, and process the data. API Bottlenecks: The live Figma API connections generated far too many requests, causing frequent rate-limiting issues. Resource-heavy: Each time we want to create a new layout we have to prompt an AI, which uses extra computing power and adds up in ongoing token costs. At our agency, Konkat, we built PageGrid to power actual production sites for our clients. We plan to use these tools daily to optimize our own studio workflow. In a professional production pipeline, an unpredictable guessing game that changes its behavior on every prompt simply isn't an option. We needed something that was completely deterministic, blazing fast, and independent of live external APIs. So, we changed our strategy entirely. Changing the Strategy: AI as the Engineer, Not the Runtime Since Claude had become deeply familiar with the Figma API, and thoroughly understood the structure of ProcessWire and PageGrid, I stopped trying to use the AI to generate layouts on the fly. Instead, I partnered with Claude to write a dedicated, local compiler. Claude acted as my co-developer. Together, we built a simple, two-part ecosystem: A local Figma Exporter Plugin that reads the canvas instantly and packages the architectural structure and assets into a lightweight .ZIP file. A native ProcessWire Importer Module that unzips that package and handles the rendering locally on your server. Because the final tool runs entirely on pure, local code logic, it requires zero active AI API calls, runs instantly, and produces the exact same, predictable structure every single time. Respecting Layout Intent Without Forcing "Auto Layout" Most Figma-to-code plugins fail unless you have meticulously built your file using strict, perfectly nested Auto Layout components. If you design loosely, those plugins break or output absolute-positioned spaghetti code that is impossible to maintain. As a designer, I know that forcing strict Auto Layout workflows during the rapid, creative prototyping phase can feel incredibly restrictive. That’s why we engineered our importer to give you complete freedom to design your way. Whether you prefer nesting elements using strict Auto Layout, arranging them freely using Figma's native Column Layout Guides, or using a mix of both, the compiler adapts to your workflow. When you run the importer, PageGrid respects your structural intent and translates it into standard web architecture: Native CSS Grid & Flexbox: Elements aligned to your column guides are automatically mapped to precise, responsive CSS Grid positions, while Auto Layout frames are translated cleanly into semantic Flexbox structures. Direct Layer Mapping & Smart Flattening: The importer replicates your Figma layer structure directly in PageGrid by mapping all layer nodes straight to native PageGrid Blocks like pg_group (groups), pg_image (images), and pg_editor (text). At the same time, the parser automatically filters the tree, flattening out any unnecessary deep nesting or arbitrary wrappers when needed so your backend tree stays incredibly clean. Maps Figma API to Modern CSS: It natively extracts typography styles, colors, borders, spacing rules, and effects, turning them directly into clean PageGrid metadata or copyable CSS. 💡 The "Grouping" Pro-Tip: Because Figma group nodes map directly to pg_group container blocks, grouping items that belong together directly shapes your PageGrid backend structure. While the importer can handle ungrouped layers, grouping your elements ensures the highest layout accuracy and keeps complex structures beautifully organized under the hood. Keeping You in the Driver's Seat When the import finishes, you are not left with a static image or a fragile webpage that breaks the moment you edit a line of text. You get a native, fully editable ProcessWire page built out of organized PageGrid blocks. Because PageGrid functions like a precise web canvas, the layout remains rock-solid. Your clients can easily log in to update text and images directly on the live page, but they will never accidentally break the structural layout you designed. The mechanical translation work is completed in five seconds. From there, you take over to do the work that humans do best: adding fine-tuned interactions, implementing custom animations, and binding dynamic backend data fields. How to Try It You don't need a paid plan to use it—the plugin works perfectly on the free version of Figma. Here is how to get started: Get the Figma Plugin: Open the Figma to PageGrid Exporter in Figma. Select your main design frame and download your .ZIP package. Install the Importer Module (Self-Hosted Only): Add the PageGridFigmaImport module to your ProcessWire backend. Upload & Run: Go to Setup > Figma to PageGrid, drop in your file, and watch your layout appear natively. Documentation: Figma Import Documentation. I consider this a beta launch, not every generated layout will be perfect out of the box, but results so far have been quite impressive. I plan to improve this over time. Give it a try and let me know what you think!

A big thanks to @@Mikel for flagging some of the items which form 1.19.1. Uninstall (fixed) The safety check that requires you to opt-in via `$config->MediaHubUninstall` in `site/config.php` was firing a beat too late. By the time the error showed, companion modules and their pages were already partially torn down. 1.19.1 hoists that check into a `hookBefore('Modules::uninstall')` so nothing is touched if the flag is missing. Also tightened companion module cleanup, admin page deletion, and crop-field removal so the whole flow is now atomic: succeeds completely or aborts cleanly. Import (fixed) Importing existing images on a non-MediaHub site (Setup → Media Hub → Import Existing) wasn't generating thumbnails. Bonus: retina `srcset` (1x/2x) and lazy loading on inputfield thumbnails. Icons (aligned) The library and the MediaHub inputfield each have view-mode toggles (grid, proportional or masonry, detail or list), but 1.19.0 used slightly different icon sets between the two surfaces. 1.19.1 aligns them on the same Lucide set. Labels bug (fixed) The new Labels section in 1.19.0 shared structural class names with Collections. This meant Labels were incorrectly displayed on some Collections filters nd menus. Labels and Collections are now strictly separate row types throughout the sidebar. Full changelog 1.19.1 blog post 1.19.1 download

This week on the core dev branch, the biggest addition was the upgrade from FontAwesome v4 to FontAwesome v6. This greatly increases the number of icons available in the admin. And while the new icons are in the same family as the old ones (still FontAwesome), they have a little bit different personality too. You can still use the v4 icons if you want by setting $config->adminIcons('version', '4'); though I recommend leaving it at the default, which will use v6 icons for AdminThemeUikit and v4 icons for older admin themes. There were several other updates this week to the core, which can be found on the dev branch commit log. The AgentTools module also received some significant updates this week: New scheduled tasks feature (this one is my favorite). Enables AgentTools to run tasks automatically at scheduled times or intervals. Improved Agents/models management screen (see screenshot). New tabs navigation makes it easier to get around in AgentTools. New debug and traces feature to track what agents are doing behind the scenes. New persistent memory feature, enabling agents to save a permanent memory across all sessions, when you ask them to. New guards on agent behavior, in case one goes rogue and decides to go places where it shouldn't. Note that SiteEngineer and PageEngineer each have their own persistent memory. SiteEngineer's persistent memory can be modified in the module configuration, while PageEngineer's persistent memory can be modified in your engineer field(s) settings. @wbmnfktr let me know about OpenCode Go last week, which I think is amazing. It provides you access to a whole bunch of AI models and a ton of usage for $10/month ($5 for first month). I have found most of the models to have very good ProcessWire knowledge. I think it's a perfect match with AgentTools because OpenCode provides you with as many API keys as you want. Whereas Anthropic and OpenAI don't include API keys with their monthly plans (Anthropic and OpenAI make you pay by the token with API keys). If you want an extra $5 credit for it use this link and it'll give both of us $5. I'm only posting that because it gives you extra credit, I don't need the extra credit so if we can get @wbmnfktr to post his link, use his instead since he's the one that told me about it. OpenCode also comes with a terminal app that is basically identical to the Claude Code and Codex terminal apps. They apparently have a desktop app too, but I've not yet tried it. If any of you do end up getting OpenCode I'd be curious what models you enjoy the most. So far I'm having a hard time deciding, as they've all impressed me in different ways. Yesterday I setup a scheduled task to "write blog posts" as just an AgentTools test, and do a round robin between the agents, writing blog posts and having different agent proofread them, every 15 minutes. I went to lunch. Then I started getting emails from the agents that they'd finished blog posts. Look at what they came up with (screenshot below). I started reading them, and they are actually fantastic posts. They are so good in fact that I'm tempted to post some of them on the site here, but I've never used AI generated content for this stuff before so am still debating that. What would you do? Thanks for reading and have a great weekend! Blog posts that agents came up with: AgentTools tasks: New AgentTools agents configuration screen: Background scheduled jobs in AgentTools: New icon selection in the core (InputfieldIcon, like used in the Field edit screen) replaces the "show all icons" grid of icons with a search box. FA6 comes with far too many icons to show a grid of them all at once, plus the search is a lot more useful and easy to use.

I've been meaning to raise this for a few years, and ironically, anytime I went to highlight it, I didn't know where to post it. Would it be worth adding a General Discussion area under Community Support for ProcessWire-related topics that aren't support questions? The gap I keep running into is topics that are clearly on-topic for PW but don't fit any of the support categories and aren't off-topic enough for the Pub or Dev Talk. Here are three sample posts to illustrate the issue: 1. "How do you pitch ProcessWire to clients who only know WordPress?" - not a support question, not off-topic, not a tutorial 2. "What's your experience of the PW community compared to other CMS communities?" - clearly PW-related but doesn't belong in any support board 3. "I'm seeing more agencies adopt PW in Germany - anyone else noticing regional growth?" - on-topic community discussion with nowhere to land I recently spoke with three PW users, and one told me they don't visit the forums at all because there's nowhere to simply chat about ProcessWire. Another wasn't aware of many of the recent Module developments because module-related content gets buried within Modules rather than somewhere more visible. I suspect both of those things would improve with a single well-placed General Discussion board. Just to recap, I think the boards are structured very well and cater for *most* topics. But has anyone else felt this gap or had posts they couldn't find a home for?

I certainly couldn't think of one, offhand, that wouldn't potentially cause similar confusion with blending of concerns. That was why I - not so clearly - suggested just doing away with the Dev Talk and Pub into a single home and calling it General. Although potentially boring, it's also somewhat convention. Curious to hear what others think. There might be a million dollar idea out there! 🙂

This may be my own interpretation of it, but both Pub and Dev are splits of a General Discussion, whereas Dev Talk is generic/general but leaning more towards business and professional areas of discussion, and Pub is the otherwise-named category where non-tech (more-often) conversations would go because, realistically, it needs to be named something else (other than General Discussion) to not be a catch-all for Dev Talk as well. I can see the reason for naming them differently and for separating them out, but I'd imagine they could both be enveloped into a single General Discussion instead. Inevitably people would post technically or professionally-minded conversations in both Dev Talk and Pub, and vice-versa. I'm not entirely sure there's a massive benefit to provide a distinction of categorization here, especially if there are people who explicitly don't converse in the community forums because of the categorization. To clarify: I'm not being critical of the naming, just analytical. As we all know: Naming things is hard!

That's f*****g insane! Excuse my french. There is a license or two I bought but never really ever digged into PageGrid. Maybe... this is a very good reason to do so. Great work you guys did here!

I couldn't agree with this "love letter" any more than the others already have! When we explored the possibilities of SiteSync, the interplay with RockMigrations and coding agents opened up an incredibly fascinating workflow that we wouldn't want to do without anymore. Our front-end and back-end developers have barely needed to talk to each other since. 😅 Fantastic module, thanks a lot, @bernhard!

I love this Love Letter! Not only because it's true, but because it showed me something I didn't know about RockMigrations - something I always wanted but couldn't really explain, something that was already there. Or as it is called Config Migrations. Buried deep, somewhere in the docs (at least for me). https://github.com/baumrock/RockMigrations/tree/main/docs/config-migrations I didn't know that. At all. I tried to handle and manage so many site/migrate.php files but it never felt right for me. At some point I lost track of changes, those hundreds of lines of code became unmaintainable for me. Wasn't fun. Stopped using it. One project after the other. Never really tried again. Did it the old way. But this, config migrations, this is a game changer for me. Sure, I quite often sleep under a stone, but this. Thank you @gebeer for making this your example. Thank you @bernhard for making RockMigrations - and this is exact feature. 🤯

I will fully admit that I think I try to do much, I'm still learning how to estimate time for things (this faucet repair will be easy, it should only take 5 minutes ... on my own, running up and down the stairs because there's no shutoff valve, a part broke, a new tool is needed to install the replacement that isn't made the same, etc., 4 hours later....). I constantly measure in expectations, not in reality, and I'd imagine that forces me down. I definitely make time for exercise. Being fit is, for me - thankfully - something that has been a priority. I don't need to be able to win races or competitions, but I need to be fit enough to at least stay relevant if I were to want to jump into a team-based sport on a whim. I've adjusted my diet a bit to significantly reduce processed grains and dairy, of which both (in tandem) seem to exacerbate gut issues. I've been drinking more coffee lately which has primarily been social, I think I'll cut that back. Otherwise protein smoothies with fruit and leafy greens, and a kombucha in the morning with an egg, and then dinner is whatever's on the menu. So, what works for me? I'm a solo-developer in a public library and it's the only professional job I've ever had (21+ years). No one truly understands what I do, and I don't have the opportunity to learn from others in the industry (directly), so I'm always stressing. I absolutely compare myself to others, so @Peter Knight's point is right on target. I definitely want to be/feel more productive and am not sure how to go about doing that, but perhaps that's not the right mindset. I've only recently realized I have a tinge of ADHD, it's more evident when I try to juggle far too many tasks at once - but I didn't really think it was a thing because my brother is an obvious case, so, again, comparing... 😅 I think I may need to try to set some actual goals, and boundaries to succeeding in those goals in order to maintain focus on them, such as, "I'm going to take a course on ______. I must spend ___ hours per week, with room for acceptable exceptions, to complete this goal." And make a list. Until it's written down, it's just a thought, and not a real goal (to me). To continue the conversation for anyone else that stumbles here: What has worked for you? What can you identify that isn't working for you?

Thanks for all the feedback, this is great. I just wanted to say ProcessWire has always been "back", never left. It's always been a long term project and never a fad project, so periods of rapid development and periods of slow development are normal, and I'm sure that cycle will always be the case. I've always been careful about making sure the project doesn't get bloated with short term things. So to make sure the quality is high over the long term, it's good to know when to go into rapid development, and when to let things simmer slowly. There's room for both. The other factor is that sometimes I have client work deadlines that I've got to give priority to because that's what keeps me in business, and able to keep investing in ProcessWire. I mention all this just because I don't want folks to be disappointed when there are weeks without any commits, etc., because that's unavoidable. For me this has always been a lifetime project, so ProcessWire isn't leaving or coming back, it's here to stay, as has always been the case.

So I tried the following but I'm not sure if it's good practice or not. Sharing in case anyone finds it useful. This setup requires that the PageImageSource module is installed with srcset image sizes setup in its config. It basically involves creating a page where cross-site images can be uploaded - like a simple image library. I created a short function to make it easier to grab the images where needed. Adding ->render() will output <picture> with srcsets. The media page should be set as hidden. Create a template, give it a name and add a multi-image field In the templates folder create _func.php and add the following: <?php namespace ProcessWire; /* Create a fn. that returns a Pageimage object from media library page you just created. Here i called my function medialib, and $medialibrary is the name of my template.*/ function medialib($filename) { static $medialibrary = null; if (is_null($medialibrary)) { // REPLACE the get directory with the Media Library page url created in admin. Mine was /media-library/ $medialibrary = wire('pages')->get('/media-library/'); } // Returns the image object if found, or null return $medialibrary->id ? $medialibrary->images->get("name=$filename") : null; } Add the include for _func.php in your _init.php in the templates folder: <?php namespace ProcessWire; // This makes the medialib() function available to all templates include_once("./_func.php"); // Render media library images on other pages using format: /*<?= medialib("imagefile.jpg")?->render() ?>*/ Function can now be called in template markup using: // Render media library images on other pages using format: <?= medialib("imagefile.jpg")?->render() ?> //Example <?=medialib("imageNameMustMatchFileName.jpg")->render()?> // Outputs <picture> tag. For CSS styling, target outer div class like so: .class img{.....} Combining this with another module might https://processwire.com/modules/process-media-lister/ might be useful.