Leaderboard

Most important to me is that I understand everything that goes into the core, and that means that AI is used for ideas and suggestions, but the code is still written by hand. And even then, the suggestions and ideas only end up in the core if they produce a measurable improvement. After testing and benchmarking, sometimes the ideas/suggestions result in an improvement, and just as often they do not. I do the same with pull requests. Coding and re-coding something is how I feel comfortable that I understand it. Perhaps too old-school but I don't think that will ever change. So long as I'm in charge of the core, I need that level of understanding with it. On another project I'm working on with a client (an add-on to their website), we're letting Claude handle the code entirely, with lots of instructions from us, but zero code from us. It's kind of a test and a learning experience, and the client initiated it. We don't know the details of the code, but we do know that the code works quite well. Though I had a peek at its code and found it to be quite solid. What's funny is that in this case, Claude is having me build web services it can pull data from. So I'm giving it instructions, but it's also giving me instructions. 🙂

[Update] v1.0.25 – Multi-Email Account Merge A small but handy addition for real-world scenarios: customers sometimes purchase with different email addresses and end up with split accounts. The new Merge User Accounts tool in the module config lets you consolidate them in seconds. You enter the source email (the old/unwanted account) and the target email (the one the customer wants to keep). The module transfers all purchases from the source to the target and permanently deletes the source account. Before committing, you can run it in test mode to see exactly what would be transferred – no changes are written. Once you're confident, check "Merge now", save, and the merge report confirms what happened. One thing worth noting: the source account is permanently deleted after the merge – so double-check in test mode first. 🙂 Feedback welcome!

The toughest challenge so far? Being our own client. Actually, the website we launched back then was just a placeholder, and the plan was to quickly replace it with a proper portfolio website. But as is often the case, it ended up taking a little longer than expected. A year later, we’ve finally done it: Our new website is live! https://konkat.studio/ The goal of the new website is to showcase our work and better communicate our services. The site is bilingual and was built using ProcessWire and PageGrid. More on that later. In addition to the website, we’ve also evolved our visual identity and logo. KONKAT (from concatenation) stands for linking individual elements into a functional whole. Our new branding makes this connection visible. In our case, we combine strategy, design, and technology into a unified process. The logo mark communicates this as well; as most of you probably know, the += operator in JavaScript joins elements and assigns the result. It took us some iterations to get the design right, but once the design was done, development was pretty straightforward. Most of the time was spent preparing the content for the projects, and that is also where PageGrid was super useful since it allowed us to design the layout and content of each project individually. Backend view: Managing project content and layouts with PageGrid. PageGrid also significantly sped up development, as we built all other pages using only its core blocks. For the projects overview, for instance, we used the datalist block to automatically generate the listing from our project pages, working perfectly out of the box without any custom logic. We also added some custom code where it made sense, e.g. the scroll animation on the homepage was just a bit easier to achieve with custom code (it uses native CSS sticky). Backend view: Using Pagegrid's inline editing to update some text on the english version auf our services page. Another great thing is that PageGrid takes care of lazy loading images and videos (using the famous lazysizes js plugin) and is caching its content automatically. As a result, we got a 100 on the Google Lighthouse test on desktop and 99 on mobile without any extra optimizations (we are not using Markup Cache or ProCache for this site). Backend view: Editing a thumbnail on the homepage If you have any further questions regarding our workflow or process, feel free to ask. I will do my best to answer them. Also, please let us know if you find any bugs, since the website is brand new, there are probably some we haven't caught yet! We also welcome any feedback you may have. Best, Jan & Diogo (KONKAT)

Hi everyone – very infrequent poster here, and also a long-time PW user in my web development career, for which I am deeply appreciative. Like @Ex-user, I have a lot of intense skepticism about AI, not only because of the environmental consequences being referred to, but also the invisibilized human costs in training these algorithms, as well as the risk of impacting critical thinking skills. I bristle at the way it's being coercively marketed as the inevitable answer to every human problem. That being said, I, like everyone else, recognize I have a career because of the many visible and hidden costs of digital technologies. That neither means I am "pure" or exempt from the hidden costs, nor does it mean I accept everything without pause. I think we all are attempting to make the best decisions for ourselves and consideration for others, and this may be expressed in differing ways when it comes to AI usage. For me, the primary issue with using AI is the matter of trust and accountability – what person is bearing responsibility for the work it produces or choices it makes? If PW's codebase adopts any changes suggested by AI, my hope would be that it undergoes the same level of testing and scrutiny as any other code revision, and it seems like Ryan is doing just that. If I have any say as a PW user in how AI is adopted into the main codebase, my hope would be that it's a transparent, auditable process, and (somewhat idealistically, from my own personal, ethical position) continues to be opt-in.

Thanks for the feedback! Done in v1.1.7! 🎉 You can now manually select your CSS framework in module settings: Setup → Modules → Context → Configure → CSS Framework Options: Auto-detect (default) Tailwind CSS Bootstrap UIkit Vanilla CSS / Custom ← your use case None This will generate more accurate code examples and snippets for AI, specifically tailored to your vanilla CSS setup instead of assuming Tailwind.

Hey folks, fun fact: this module was already featured in this week’s ProcessWire Weekly – even before we managed to post it here in the forum. So, here we are, finally giving it a proper introduction! 😅 TL;DR: This module connects Stripe Payment Links with ProcessWire and provides a simple checkout integration for sites that don’t need a full shop. 🎯 ✅ Drop a Stripe buy button anywhere ✅ Redirect back to PW thank-you or delivery pages ✅ Buyers get accounts, purchases are logged, access is granted ✅ Access mails are sent automatically ✴️ New in v 1.0.7: Sync existing purchases and buyers from Stripe to PW with test/write option ✴️ New in v 1.0.8: Full Stripe subscription support with real-time webhook updates (cancel, pause, resume, renew) and smarter access control logic ✴️ New in v 1.0.10: Notify existing buyers and update purchases when products gain gated content. ✴️ New in v 1.0.14: Create and send "Magic Links" (access links) to customers for products they've already purchased. ✴️ New in v 1.0.23: Give Free Product Access to customers. ✴️ New in v 1.0.25: Merge Accounts of customers who purchased with different mail addresses. First things first: What are Stripe Payment Links? Stripe Payment Links are basically hosted checkout pages that you can create directly in the Stripe Dashboard – no coding required. You define a product (or multiple line items) in Stripe. Stripe gives you a unique URL (the “Payment Link”). You can drop this URL behind any button, on any landing page, newsletter, or social media bio. When a customer clicks the link, they’re taken to a secure Stripe Checkout page (PCI compliant, supports all major payment methods, Apple Pay, etc.). After payment, Stripe redirects them back to your success URL. Super simple. But… on its own, Stripe has no idea about your ProcessWire site, your users, or your gated content. That’s where this module jumps in. 🚀 Why another payment module? We at frameless Media often work on small client projects where setting up a full e-commerce shop would be complete overkill. Think: Coaches selling a few courses or workshops Businesses offering a handful of digital products or subscriptions Creators who just need a buy button on a landing page Stripe Payment Links are perfect for this. But: ProcessWire on its own doesn’t handle redirects, user handling, or gated delivery pages. So we built StripePaymentLinks – a lightweight drop-in module to connect Stripe with PW. What it does Handles the redirect back from Stripe Checkout that contains the session id Creates or updates the buyer’s user account Records purchases in a repeater field Manages access to “delivery pages” (only available after purchase) Auto-sends access mails (configurable: never / new users only / always) Provides Bootstrap-based modals for login, password reset, set-password Usage examples Example 1: Sales page + delivery page Sales page has a “Buy now” button (Stripe Payment Link). After checkout, the user is redirected to the delivery page, which is access-protected. → Module logs them in, grants access, and if they’re new: a set-password modal pops up. → An access mail with product links is sent. Example 2: Product without a delivery page Some products don’t need protected pages (e.g. a consulting slot or voucher). → The success redirect goes to a generic thank-you page. → The module shows an access summary block with purchased products and sends the mail. Example 3: Mixed purchase (thank-you + delivery page) A checkout with multiple items: e.g. a “simple product” plus an addon that has its own delivery page. → Thank-you page shows the addon link(s). → The access mail lists all purchased products. Source & License The module is open-source under the MIT License. 👉 GitHub: https://github.com/frameless-at/StripePaymentLinks 👉 ProcessWire modules directory: https://processwire.com/modules/stripe-payment-links/ So yes: if you or your clients just need a few low-barrier buy buttons, not a full-blown webshop, this might be the module you’ve been looking for. If needed we can provide some screenshots and visual examples next week 😉 Happy to hear your thoughts, ideas, and testing feedback! Cheers, Mike

Thank you both for the feedback! Added a dedicated sitemap-edit permission in v1.0.1. It is created automatically on module install — just assign it to the roles you need in Access > Roles. https://github.com/mxmsmnv/Sitemap

On a side note, because of the ProcessWire 'way' of handling images, it helps to think about the purpose of the images your page will have. As teppo flagged. So I usually have 1 x carousel images or a hero image field 1 x general images field i might display in the content 1 x something else The reason for doing this is that you can keep all your images and image field settings appropriate for the image purpose etc. Especially if you have clients adding or removing images. I find having just one image field can be an issue if they accidentally remove something or add an image which should not be part of the hero banner etc. Later on you might want to also look at tagging images and calling them onto your front-end pages https://processwire.com/modules/textformatter-image-tags/ But I'd recommend getting used to the basics first. An example of how I use image tagging might be. I have a product field with a lot of general images one of them in particular is used as a preview thumb on a product overview page so i'll tag that image 'preview' or whatever you want really. Lets us know how it goes

I left out that I meant this option to be an individual field level setting, not a global one. There are always pros and cons, but this solution also ensures that the default UX/UI of the admin is not changed too much, and if users use both interfaces (standard PW and MediaHub), then less deviation from what they are used to will generate less confusion.

Hi @Stefanowitsch, thanks for the heads-up! Pushed a fix to Github to handle wrong values for model or API key a bit more gracefully 😅

It looks really nice and congrats on the (re-)launch! A small bug I noticed though on the homepage with the scroll animation (using Firefox on MacOS): konkat.mp4