Mikel

Because this question came up: No, the user does not have to enter any data before checkout. All user data is pulled via Stripes PHP SDK (included with the module). Therefore the only thing needed for the module to work is that the redirect link configured in Stripe contains the session_id param. You configure this directly in the Stripe backend by simply adding ?session_id={CHECKOUT_SESSION_ID} to your desired redirect-URL: Thats all. With this session id the module has access to all data of this specific purchase. Cheers, Mike

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! 😅 (Links to the official ProcessWire modules directory will follow once it’s approved there.) 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 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: pending 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

Allways great learning something new, isn't it? 😉 Can you explain what kind of data you are displaying that can not be handled by the module?

First of all, hats off to everyone involved in the redesign! I can only imagine the countless hours that must have gone into this project – really impressive work. Of course, a redesign will always divide opinions. Some will love it, some won’t – that’s the nature of design (a bit like beer: there’s no accounting for taste). But let me share a perspective from my three decades of experience working with clients: 99% of paying clients couldn’t care less about what CMS powers their site. What matters to them is that the website looks good and feels professional. The ones we really need to convince are the second tier of decision-makers: the people who will actually use the system day-to-day. These users are rarely designers. They don’t care much about animations or typographic finesse – what matters to them is clarity, ease of use, and a sense that the CMS won’t get in their way. That’s why, in practice, we almost never show clients a backend during the decision-making phase. Instead, we show them beautiful, carefully crafted frontends, and sometimes highlight the inline editing capabilities. That sells. Clients are impressed when they see polished websites that “might be running on ProcessWire” (since, let’s be honest, you can’t tell a CMS from the frontend anyway). How this focus on real-world client priorities could be reflected more strongly in the redesigned ProcessWire website is something I’d love to explore further. Cheers, Mike

Hi everyone, we’d like to share a small but handy module we developed at frameless Media: TextformatterSmartQuotes. 🧠 The Problem While working on a client project, we needed to replace straight quotes ("...") with typographic quotes (like „...“) — but only in the visible text content, not inside HTML tags or attributes. Using the TextformatterFindReplace module, a case like this: <strong style="font-size: 18px;">Improved "well-being"</strong> would turn into: <strong style=„font-size: 18px;“>Improved „well-being“</strong> which breaks the HTML. We tried solving it with regular expressions, but none proved reliable enough. Every approach either failed to match all valid cases or accidentally modified tag attributes. That’s when we decided to build a dedicated solution. ✅ Our Solution TextformatterSmartQuotes is a Textformatter that replaces quotes only in visible text, leaving HTML markup untouched. It supports the following quote styles: German: „…“ English: “…” French: « … » The quote style can be selected in the module’s settings. 📦 Installation Place the module in /site/modules/TextformatterSmartQuotes/. Install it via the Modules admin interface. Assign it to any text/textarea/CKEditor field under “Text formatters”. Configure your preferred quote style if needed. This module helped us avoid fragile regex workarounds and keeps content formatting clean and reliable. Feel free to use, improve, or contribute to it. You can download it on GitHub or via the Modules Directory We’re happy to hear your feedback! Cheers, Mike

While making Screenshots for a support reply I noticed a little bug: The logged in user in the screenshots has a specific role that allows him to view existing DataTables of our module ProcessDataTables in the backend but nothing more. The user has logged in at the admin URL, what normally will not be the preferred way. But anyway, with Reno it looks as expected: With AdminUIKit it shows some minor visual bugs:

Hi, @PWaddict, here is how to make use of the permission: Create the permission data-table-view and add a distinct description to it. Create a role (lets say its called „data-viewer“) and add the permission data-table-view: Make sure the template datatable has granted view access to that role: Make sure the template admin has granted view access to that role: Then all of your existing DataTable pages should show view access for that role:

Thanks for the findings, @PWaddict. We fixed these issues in version 2.4.5. Please upgrade 😉

😄 Yes, that would be not so nice. But we created the app (and the toggles) for a small user group with no color blind members and the mission was to visualize the states of many projects and subtasks at one glance. The green/red scheme achieved the best results in our test settings, so we went with that. 😉👍 But have a look for yourself: https://frameless.at/en/case-studies/real-estate-marketing/

From the start, I asked myself why I was somehow not completely satisfied with the display of the checkboxes as switches: We actually use switches quite heavily in some of our webapps, so I looked at the examples and therefore suggest making the “inactive” status brighter. This makes it easier to recognize the status of the checkbox. Below is an example of iOS switches. I also find it problematic when the theme color is red: To me, this makes the checkbox appear “false” even though it is “true”. Making the “unchecked” state lighter in color, also would help in this case. Below is an example of one of our web apps. There we chose to give both states a color: That makes it easy to understand the state of the toggle (checkbox).

Hello again! We have made some small bugfixes in the last few days, 2 of which are worth mentioning: All labels and texts of the module can now be translated. From version 0.6.5 column templates are saved in /site/asstes/. This has the advantage that you no longer have to remember to export your column templates before upgrading the module. ATTENTION: Before upgrading to this version, be sure to create an export of your column templates! 😉

We just discovered something funny: The design of the column width slider handle is from a galaxy far, far away, isn´t it? 😉

Wenn using the admin theme on touch devices (iOS) the visual aid of the highlighted background is missing. This is kind of irritating, especially when pages are hidden, because the page title does not get highlighted either.

Hello everyone, I would like to give you an overview of the recent changes and improvements that have been incorporated into the ProcessDataTables module since version 0.6.0. Maybe there is something interesting for you! As we are testing the brand new UIKit style the screenshots are made using that theme. From 0.6.0, the UI for import/export is now clearly structured, visually improved and much more user-friendly. The new pagination (from 0.6.2) ensures better performance and overview for large data records. The value for the rows per page for DataTables is defined in the config area. Before this version there was no native pagination, i.e. all data records were loaded at once - problematic with large amounts of data. Now the navigation is performant and user-friendly, large tables are divided into pages.

As our interface test module evolves, more minor bugs pop up. Here we have the toggles: I think there is supposed to be a separator between the two options? Interestingly when 3 options are defined there is a separator between the first two options:

One of our test users of the new admin style informed us that there is a minor visual bug on the "close" button of the slide-in pagetree. As I was able to reproduce it, here you can see the issue: Also present when hovering the "close" button

I have to add that my example from above already uses a custom CSS for the buttons. Out of the box the example would look like this: The Code: <div style="display: flex; gap: 10px; margin-top: 15px;"> <button class="uk-button uk-button-primary uk-border-rounded">Primary</button> <button class="uk-button uk-button-secondary uk-border-rounded">Secondary</button> <button class="uk-button uk-button-danger uk-border-rounded">Danger</button> </div>

Thank you for your response, @jploch. I really appreciate when a conversation is held at this level. Regarding data on user preferences: We have such data because we regularly collect it during design processes for user interfaces through test series. These tests have shown us a clear pattern so far: decision-makers—i.e., those who pay for the project—are generally drawn to sleek, modern, and shiny interfaces; those who actually work with them (daily) prefer a bit more color in the interfaces because it allows them to orient themselves more quickly. Of course, I agree that one can fine-tune the use of colors in the “Classic” style of the admin theme, but our clients – or rather, those who actually worked with it 😉 – have always been happy with the look and feel. By the way: in our view, a CMS is not meant to reflect corporate design any more than MS Word, InDesign, or any other software solution is. Since you want concrete feedback and suggestions, we are currently developing a small test tool with the most common UI elements that we use in the backends we manage to identify any potential issues. We usually provide our clients with 2–3 different admin themes that they can choose freely. (That is also where our data comes from.) Here is a first example (more to come) showing why we would like the option for a second color – on the left, the AdminTheme UIKit “classic” style; on the right, the new “default” style: By the way, we really like the decision to have the open/close arrow point in the correct directions! In closing, we would like to thank you again for the openness of the discussion and your willingness to engage! As a design agency, we unreservedly support your stance on “design by committee.” At the same time, we also understand developers like @bernhard, who have invested a lot of time in creating their modules and make their living from it, and who would have welcomed a discussion beforehand. At frameless, we have been convinced by ProcessWire for many years and use it for every web related project we develop ourselves. We currently see an opportunity with this redesign to position the platform as effectively as possible in the changing market for the coming years. So, thank you for your thoughts and implementations!

Recently, we did a lot of testing, including installations on different systems, and in that context, a small import/export functionality proved very useful: New in version 2.4.3: Import/Export Configuration Functions: Introduced logic for importing/exporting user data table configurations using JSON files. Added code to automatically create an import directory (UserDataTableImport/) if it does not exist. The module scans for the latest JSON file in the import directory and, if found, decodes the configuration and applies it to the module settings, removing the file after a successful import. This allows easy migration or backup/restore of configuration settings between environments. The process is very simple and self-explanatory: you’ll find the relevant fields at the bottom of the config page. A JSON file is exported or imported, containing all the settings of the page. We hope all of you find it just as useful as we do!

I fully agree on your example of the supermarket, which is something I often mention myself when talking to clients. But nobody would claim that the “classic” ProcessWire theme is too colorful, would they? It is well coordinated and offers enough possibilities to make COLORFUL distinctions if you need them. Deciding between "green, red and yellow button" will always be more self explaining and less prone to errors as deciding between "left, middle and right button" Because you mentioned UIs from OSs, just a small example from the Apple Developer Docs: Having three equally colored buttons at the top left corner would not be that practical, would it? 😉 As someone who has developed many interfaces, I can only say that our user tests have ALWAYS shown that more than one color is needed in addition to black, grey, white, which, as we know, are basically not colors 😉 For us, the new default style of the UIKit Admin theme is currently not a viable option. We’ve decided to hold off until the final release, ideally with the ability to define a secondary color.

Thanks @jploch for your time, the thoughtful perspectives and the in-depth explanations behind the new theme direction. I’d like to add that – regardless of trends like monochrome color palettes – there are universal usability best practices, especially when it comes to complex interfaces. Renowned usability experts like Jakob Nielsen have shown that color differentiation and clear visual hierarchies are crucial for orientation, error prevention, and efficiency. Relying on just one color (even with accent tones) can make it harder for the user to distinguish between navigation, controls, content areas, and information messages, particularly in a CMS as flexible and powerful as ProcessWire. On the marketing and positioning front, it’s also important to recognize how much the market has changed. Many users today are looking for ready-made, hosted CMS solutions with out-of-the-box themes, rather than building or customizing everything themselves. When ProcessWire started, there were far fewer quality options available; now, even agencies often prefer SaaS CMSs for their convenience. So it raises the question: who is ProcessWire really for in 2025? Is it still mainly aimed at developers and agencies who need maximum flexibility, or is there a desire to broaden the target group? I believe clarity in both design and communication about the intended audience will help keep PW competitive and attract the right users, whether they value flexibility and control, or are seeking quick, plug-and-play solutions. Thanks again for all your efforts and the open dialogue – these conversations are what keep the community strong!

Thanks for the details @jploch about the goals and considerations that preceded the design process. Some things become clearer because of that, while others still interest me, as I can’t fully comprehend them yet. Let’s perhaps first establish that although both a website and a CMS are interfaces, the latter must follow a different set of visual rules. The approach of trying to unify both visually is understandable in the context you described, but it results in a dysfunctional design language for a CMS. A not ideal interface is either too loud or too quiet – like the new theme. What’s missing is clear differentiation between various element groups (navigation, controls, content, info, to name a few). I‘ve been working in the design field for nearly 30 years and am aware of many trends, fashions, and viewpoints. I’m by no means looking to argue about matters of taste – instead, I’m interested in the underlying design philosophy that guided the development of the new admin style. That said, once again, many thanks for all the work that went into this project!

Thanks a lot, @ryan, for posting such detailed examples! I agree with many of the concerns regarding having multiple “style” layers stacked on top of each other, as well as what @bernhard wrote about “reinventing the wheel.” It reminds me of the horrible experiences we had when a client decided to purchase a “professional” Bootstrap theme… I counted four different style systems overwriting each other countless times. It was a mess to work with and almost impossible to make any changes without writing a lot of extra code. We’re still experimenting with the new admin style, showing it to some clients and collecting feedback. The main response we’ve received so far is that everyone felt somewhat uncomfortable with the non-white background (“dull”, “depressive”) and missed the colors on the input elements. What everyone did like were the productivity improvements like the fixed navigation and the hover-toolbar in the page tree. Maybe I’m wrong—time will tell—but from a strict UI designer’s standpoint (which is my profession), the hype around “dark modes” introduced by operating systems is… well, just hype when it comes to software like a CMS. Most “regular” users are happy once they’ve learned an interface well enough to complete their tasks. If that interface suddenly changes just because it gets dark outside, it’s… let’s say, at the very least, irritating. Lastly, I think there’s a typo in the custom CSS example linked in the admin style config: /* -------------------------------------------------------------------- */ /* ---- THEME WITH COLOR MASTHEAD VARIABLES -------------------------- */ /* ---- (these depend on the default theme variables) --------------- */ /* ----------------------------------------------------------------- */ :root { ... --masthead-menu-item-backgroud-hover: rgba(255,255,255,.2); } I believe there’s an “n” missing—shouldn’t the variable be like this? --masthead-menu-item-background-hover Cheers to all of you—have a pleasant and productive week!

For anyone who saw the forum post about our ProcessDataTables module: you can absolutely reproduce the same output and functionality (even more complex one if you need to) using that module. UserDataTables, however, gives you everything entirely within the backend—no need to touch or customize any PHP templates. If you need DataTables in your backend beyond just user-related data, choose ProcessDataTables—it’s designed for exactly that. We’re aiming to release a stable version by next week.

The latest additions/improvements of the module [v0.5.0]: Template file structure Stubs are now namespaced into subfolders per DataTable (column_templates/<table>/<slug>.column.php) instead of a flat directory. TemplateGenerator::getTemplateFilePath() and createTemplateFile() updated to build and create these subdirectories automatically. Legacy-stub upgrade loadColumnTemplates() now checks each stub for a return function(...) signature. If missing, it archives the old stub (prefixing its filename with _) before regenerating a new closure-based stub. Page-property handling Unified list of core properties driven by getStandardPropertyLabels() (including status). All Page-property stubs now use return …; inside closures and map bitmask flags (status) to human-readable labels. Lets look a little closer at the switch to closures for the column templates and an export/import feature. We planned this from the beginning and now switched over to a slightly different approach for the tiny template files used to display the data in your columns. The mechanism of those templates remains the same, but the performance gain is huge. Especially when dealing with lots of columns and rows: OLD: echo htmlspecialchars((string)$value); NEW: return function($value, $config = []) { return htmlspecialchars($value); }; Anyone who tried to create a DataTable gets column templates automatically created. They support the most common field types in ProcessWire and format the output initially in a simple but (hopefully) useful way. If you then tailor the output exactly to your needs, sometimes it would be handy to just save those micro templates for further use. Well, we are just developing export/import features for that purpose: Just export your global and dataTable settings as JSON and your column templates as ZIP and reuse it, manipulate them, share them 😉 and then use for migrating or easy duplication of tables. Here are some screenshots showing its (yet rather ugly) interface in action. We assume you want to port existing dataTables to another processWire site using the same data structure. Well start with a fresh install of the module We upload our exported JSON file, that contains data like this: { "moduleConfig": { "checkboxYesLabel": "Yes", "checkboxNoLabel": "No", ... }, "dataTables": [ { "name": "orders", "title": "Orders", "data_template": "rockcommerce_order", "data_selector": "", "columns": [ "rockcommerce_paymentid", "status=rockcommerce_paymentstatus", "rockcommerce_paymentdate", "order=meta", "rockcommerce_net", "total=rockcommerce_net" ... After importing we immiatly see the result of the import displayed as DataTable with, at the moment, default fieldtype templates as column templates: But at the bottom of each DataTable there is more: SO in the next step we import our prior fine-tuned column templates and immediately get a much better result: Under the hood the "old" default column templates that were created after importing the JSON config are not deleted, the get prefixed with an underscore in case you already made some adjustments before importing other column templates. Of course one can also manually copy column template files from one install to another but we found it more practical to let the module handle this. Especially when building new sites or testing, be aware that an uninstall of the module always wipes out the entire column_templates directory. So you better export before uninstalling! We are still working on the interface because it hurts my designer sensibilities to look at the UI of the import/export section. 😉 What do you think? What could be further improvements? Cheers to all of you and have a productive week!