Leaderboard

That's an interesting topic and the reason why I built RockForms. I initially released it open source in 2018 (see forum post), but I've built a new version that is not public yet. The module tries to solve exactly the pain points that you mentioned @Jonathan Lahijani. It is a wrapper around Nette Forms which is a brilliant library for creating secure and powerful forms. It takes care of all the hard parts when dealing with user input (security, remembering filled fields etc) and it is the only library that I know that let's you write code ONCE and get both client-side and server-side validation rules. By including a small JS file you even get live validation / live feedback with custom error messages. In my opinion that is the best UX you can get. The drawback of such modules / approaches is always that it get's harder to control the markup of your forms. That's why I have put a lot of effort into making the forms as easily customisable as possible. This is an example that defines custom markup that places two fields into one single row using tailwindcss: $form->addSelect("salut", "Anrede", [ 'f' => 'Frau', 'm' => 'Herr', ]); $form->addText("degree", "Titel"); $form->addMarkup("<div class='md:grid grid-cols-2 md:space-x-6'>{salut}{degree}</div>"); Note that {salut} and {degree} get replaced by full field markup that holds all the necessary form magic (field error, live validation...). Also it works great with alpinejs and/or uikit because you can easily set custom attributes: $form->setHtmlAttribute("x-data", "{affiliate:false, azubi:false}"); ... $form->addCheckbox("affiliate", "Ich bin Anschlussmitglied") ->setHtmlAttribute("x-model", "affiliate"); You don't need JQuery on your frontend - you can use the tools you want. And you get forms that fit 100% to the rest of your site. ?

Personally I'm a big fan of Form Builder and there are very few cases where I wouldn't use it. The builder and built-in actions are super flexible, it's often a requirement (or at least preferable) for site admins (content editors) to be able to customize the form, and by adding some hooks one can achieve pretty much anything with it. As it happens, I've also built a few e-commerce checkout forms with it, and would definitely do it again ?‍♂️ Cases where I usually go with a custom form are one-off cases with heavy focus on accessibility, super specific layout requirements, mostly custom inputs (which are of course possible to handle with Form Builder, but not exactly straightforward), or loads of custom JavaScript logic. I'll admit that this is quite opinionated, but I've never found the API way of generating forms particularly useful: for me at least markup is both easier and faster to generate without it (particularly if there are specific requirements), validation is in most cases a relatively minor issue — unless it's a very complex setup, in which case there are brilliant third party tools available — and core features such as $session->CSRF->renderInput() and $session->CSRF->hasValidToken() work just fine without it. Long story short: it's either Form Builder or custom form implementation for me ?

I build a lot of custom registration forms on ProcessWire sites and prefer to write the HTML directly, with some ProcessWire goodies added on. This seems quickest for authoring forms that match the site and doesn't require jQuery/jQueryUI. I prefer to make forms work even when JS is disabled, if possible. For CSRF, I manually generate a single-use token and put in the hidden form fields. I have a custom class that lets me set up a set of fields, their types, and validation rules. Parts of that leverage PW's $sanitizer and sanitized values end up in $input->whitelist() for easy processing and for populating form field values.

Personally, I prefer the old-school way rather than the ProcessWire way simply because it becomes too cumbersome to use ProcessWire to create Admissions forms, Tax forms, Milspec forms, Aircraft maintenance forms, etc. which I do almost monthly. I did begin with the ProcessWire way and spent way too much time trying to get the layout correct on both the front end and back end, so I stopped using its forms. As you know PHP has some built-in validation such as email, url, dns, etc. The remaining form types are simple enough to validate manually (ie, not using ProcessWire). Don't get me wrong, ProcessWire is great for the majority of solutions I require and I use it as the base for all current projects. But Ryan built it to satisfy his requirements, which don't necessarily meet with our requirements 100% of the time. When I create complex forms I use css grid and flexbox with custom styles to achieve the necessary front-end layout -- I don't allow user access to any back-end forms. Custom javascript is sometimes required to validate some form elements client side, including ajax calls, but it is nothing major. Also, I don't have to bloat my forms by including one or more third-party javascript libraries. If I receive a request for a simple form such as a contact form, then yes, I use the ProcessWire way. Otherwise, I find it much simpler to do it the old-school manual way.

This is something I've been thinking about over the years and I want to hear other people's thoughts on whether custom forms should be built using ProcessWire's form API. For a simple contact form, I'll usually use Form Builder. For something like a complicated signup application (like a university admissions application for example), I've used the ProcessWire admin itself (heavily locked down depending on the user's role) as the "form". However let's take an example of an ecommerce checkout form. Pros It's the "ProcessWire" way to do it. Built-in server-side form validation, CSRF and session related persistence. Cons Requires jQuery (for example when showing/hiding) and jQuery UI if using advanced fields (date picker, ASM Select, etc). Must load the appropriate JS correctly. You can also argue it loosely depends on Font Awesome 4 for icons. Due to some limitations, it doesn't work well with something like Alpine.js; for example this issue. Work-arounds are required to get the correct markup in place. It just feels more difficult even though it's the ProcessWire way to do it. Thoughts?

"Allowed memory size exhausted" is often a sign of a loop somewhere, but in this case it's more likely just an issue with your hosting environment or PHP configuration: 16777216 bytes = 16 megabytes, which is quite a small amount of memory. It's not surprising that it keeps running out. Is this an actual limit of your hosting package, or have you configured PHP to only use 16M? Either way I would recommend raising the limit to at least 64M, or preferably 128M.

Just a little badge in the top right corner of the cards? "Year To Date". I see you're using tailwind for the dash so just grabbing a tailwindui badge screenshot as reference and a uikit card with a badge to better present the idea. Then I suppose eventually you could add a switcher to show Year Averages, Month Averages and the badge label just updates. Anyway... Just a thought ??

Building your very own custom Fieldtypes in ProcessWire seems to be hard, but it actually is not, once you get the concept. In this post I'll share a simple and as minimalistic module as it can get that everybody can use as a boilerplate for his own Fieldtypes. A Fieldtype that does not store any information in the database A Fieldtype that stores information in the database (to be done) Make your Fieldtype configurable 1. A Fieldtype that does not store any information in the database Some of you might know the excellent RuntimeMarkup module by @kongondo. I've used it a lot in the past, but I get more and more into developing custom fieldtypes rather than hacking the runtime module to my needs. That has several advantages, but it has also one major drawback: It is always a pain to setup a new Fieldtype, because there are lots of methods (see the base class /wire/core/Fieldtype.php) and you have to know which methods you need, which ones you have to remove and adopt etc.; Not any more! Ryan has developed a showcase module (the Events Fieldtype) to learn from, but when I first peaked into it, it felt quite complex and I thought it would be a lot of effort to learn Fieldtype development). There are also some easy and small Fieldtypes to learn from, like the FieldtypeCheckbox. But all of them require a good understanding of what is going on, you need to modify existing config inputfields that might have been added to that fieldtype and afterall it's not as easy as it could be. With my new approach I plan to use a boilerplate fieldtype to start from (in OOP terms to "extend" from) and only change the parts i need... More on that later. Here is the boilerplate module with some debugging info to illustrate the internal flow on the tracy console: See the module in action in the tracy console ( @adrian has done such an amazing job with that module!!!): The code should be self-explaining. What is interesting, though, is that after the ### getUnformatted ### dump there is only one call to "___formatValue". All the other calls (loadPageField, wakeupValue and sanitizeValue) are not executed because the value is already stored in memory. Only the formatting part was not done at that point. With that concept it is very easy to create your very own custom Fieldtypes: <?php namespace ProcessWire; /** * Demo Fieldtype Extending the Boilerplate Runtime Fieldtype * * @author Bernhard Baumrock, 03.10.2018 * @license Licensed under MIT * @link https://www.baumrock.com */ class FieldtypeDemo extends FieldtypeMarkup { public static function getModuleInfo() { return [ 'title' => 'Demo', 'version' => '0.0.1', 'summary' => 'Demo Fieldtype', 'icon' => 'code', ]; } /** * convert the wakeupValue to the given format * eg: convert a page object to a string */ public function ___formatValue(Page $page, Field $field, $value) { $value = parent::___formatValue($page, $field, $value) . " - but even better!"; d($value, '___formatValue --> convert to whatever format you need'); return $value; } } Notice the change "but even better" in the last two dumps. I think it can't get any easier, can it?! ? I'll continue testing and improving this module, so any comments are welcome! 2. A Fieldtype that stores information in the database See this module for an easy example of how to extend FieldtypeText: