FireWire

Thanks to @Sanyaissues for the great work and PR that makes FormBuilderHtmx work when rendering in loops of repeater field content ?. Latest version on Github has the fix merged. Available for download on the main branch.

@Sanyaissues Github PR?

@Sanyaissues Updated the module to support markup regions. Download and let me know if this resolves the issue. https://github.com/SkyLundy/FormBuilderHtmx

If the forms only work when markup regions is not used then that's more of something to do with FormBuilder itself. FormBuilderHtmx just hooks into the FormBuilder module so if FormBuilder doesn't work, this module won't either. It may be better to look into markup regions in the FormBuilder support threads. Not sure why that would be beneficial? Htmx sends headers to indicate that the request is from htmx (via ajax), and the module adds identifying markup to tell htmx where to insert the form results. So while ajax is used, detecting it separately wouldn't be useful. The module does more than just return the form, if it just returned the form then ajax submissions would stop working for it altogether. There is a lot more that goes on behind the scenes to make this work in harmony with FormBuilder.

@Sanyaissues I've never used markup regions before. Knew they existed but haven't been part of my workflow. From the looks of it, that error indicates that when the form is submitted, the return markup doesn't contain the form or doesn't contain the identifying markup FormBuilderHtmx adds to a form that identifies it. With markup regions adding a step where it handles replacement of markup in the document, I'm not sure how that affects form rendering. This error is intentional as it helps identify where forms aren't rendering in a way that FormBuilderHtmx expects. Need to see your code and how you're embedding your forms. If you embed a form using markup regions without FormBuilderHtmx using $forms->render(), what happens?

New version pushed. This resolves several issues and also adds expected features. The $htmxForms->render() method is now a true drop-in replacement. All methods/properties available on $forms->render() are available. The $htmxForms render method returns the original object expected from $forms->render(), so FormBuilder scripts and styles can be used The same form can be used multiple times on the same page when all are rendered using FormBuilderHtmx, each separately tracks state/errors/submissions Has more thorough checking for form submissions to detect HTMX form submissions vs. traditional form submissions Resolves issue where the full page markup was appearing in place of the form in some instances when submitting A note on multiple instances of the same form on one page- if one is rendered using FormBuilder and a submission has errors, all instances of that form will show those errors regardless if rendered using FormBuilder or FormBuilderHtmx. This is a core behavior of FormBuilder AFAIK and is not something introduced by FormBuilderHtmx. A benefit to rendering multiple instances of the same form using FormBuilderHtmx is that each form is individually processed. Have done a lot of testing with great results, but as always, community testing and feedback is appreciated! Available for download via the Github repo. @gornycreative & @Sanyaissues let me know if this fixes the issues you're seeing.

@Sanyaissues Indeed. It had been working in my use case, but this issue came up with another person using the module and I'm working on a fix. So, fix and improvements are on the way.

It is. Next revision will truly be passthrough in that it adds HTMX and then returns the FormBuilder instance so you can continue to use all of the built in methods, including rendering FormBuilder scripts and styles- so a true drop-in replacement. Appreciate your feedback and help with making this module better!

Can you double check that CSRF is disabled for the form? I was able to replicate the issue, working on it. This is a good point... I haven't been using either of those since I include my own styles. So I guess only the render method is "drop in". I'll look into this.

Well, one is a spider and the other is a club that I'd use to kill spiders with. I vote for Padu #2.

@bernhard I did try to use it at one point. I remember that it wasn't compatible with how DeepL required it's URL parameters to be structured. I think it was the way that it had multiple GET variables with the same name and that didn't serialize properly when using WireHttp. That may be a moot point now because the DeepL API now accepts JSON encoded POST requests so that URL issue isn't a problem. Prior to that I ran into an issue with WireHttp not handling 404 responses in a way that I need to rely on, so it isn't generally top of mind. Long story short, if a 404 is returned, WireHttp will ignore that valid response and try again. As an aside- I'm working with an API right now where 404 is a valid response for a record that doesn't exist, so trying 2x doubles the API credit usage with that service. May or may not be an issue in this instance, but it is something to keep in mind when HTTP requests have a hard cost associated with them.

@theoreticHey there- we figured out the issue on Github but wanted to mention here for others as well. Fluency uses CURL to make API requests to the translation service so that is required to be present on the server. I'll note this in the documentation on the next release as a requirement for the module since it's possible to use ProcessWire and never need or use CURL. Good catch and thanks for the report!

Clickbait title? Yes. Content? Real gold.

Oh yeah? PATH is so *checks date of tweet* last year. The new stack is PHAT. "Whats the difference between PATH and PHAT" "Nothing, but one is going to appeal to kids from the 90s" My takeaway, and why it's relevant to devs here in the forum, is that ProcessWire is the right choice for a lot of situations. Side by side comparisons implementing the same thing in each platform makes an objective case for both and, from a technical point of view, my application could have been built in ProcessWire. Heck yeah. If/when possible, posting a case study here in the forum would be a great read!

Excellent. Looking forward to the results of your investigation, detective!

I tested in a repeater and didn't see the same issue so not sure. Let me know if you find something, interested in seeing what's up.

Interesting. I'll take a look at that and see what I find. Just to confirm, it's working in other places, just not repeater?

I like this thread, so I'm back to bump. Everyone has stacks! MEAN, MERN, TALL, LAMP, MEVN, RSTY, VILT, FLIP, PILF, DUMB, HALP... stacks are neat! It's cool when you can make a word out of tools! It makes it easier to argue over! I made some of those up! I'm planning out my current project and it needs a stack, or I'm not a Real Web Developer™ What is that stack you (didn't) ask? PATH. I'm putting the finishing touches on a full stack application I built over the last month using the TALL stack (Tailwind, Alpine, Laravel, Livewire). I've been jumping back and forth between that and ProcessWire and may write a post about the experience (when I can finally get enough time to do it). I've seen talk in the forums about ProcessWire alongside other tools like Laravel and want to share some firsthand information as far as differences, similarities, comparing how each handles the same task, when to consider one over the other, and takeaways that are going to influence how I use ProcessWire on upcoming projects. Also worth mentioning is how much I, and I cannot stress this enough, hate Tailwind and why I'm still going to use it. Before you ask, it's not because I can't spell "PATH" without the "T". I start out every project with research before writing code and in this case it's been a deeper dive into htmx. Along the way I have been reading Hypermedia Systems, a book written by the authors of htmx. It's free to read online, and I recommend it to everyone here. The contents of the book take the web back to basics, understanding it's core technology, and the importance of extending it's functionality, rather than fight it the way that client-heavy tools like React have chosen to do. PHP and PHP developers have a lot to gain from this approach and embracing that mentality, even if you choose not to use htmx. While my "stack" comment was a little flippant, the fact is that you can build ProcessWire applications and sites with dynamic content that provides an SPA-like experience without the SPA which is better for users, much more efficient, and provides a far better developer experience. Towards the topic of this post, I can't help but notice the continual renewed interest in alternatives to JavaScript as a full stack solution and to an extent (as noted in the videos above) an uptick in consideration for PHP as something to consider. As also discussed above, how much JavaScript fatigue is turning into JavaScript burnout. Anyway, here's a hot take by Theo that looks cold in comparison to the heat people are bringing in the comments calling him out (worth the click-through to read). One of the things that Laravel and ProcessWire have in common are modularity and the number of powerful tools built into their APIs, something I think about when hearing conversations about other PHP frameworks. So, bump in relevance to this video. You can already tell this guy is going to miss the mark because he doesn't have a Lamborghini in his preview pic SMH.

@Jonathan Lahijani I wrote a little utility that works with .env files. It uses phpdotenv but adds additional features that are ProcessWire focused and also adds caching for performance. Sharing since you mentioned dotenv in your list. I've been thinking about how I've been using phpdotenv myself on every project and am interested in thoughts from other devs who use in with PW as well.

I've written a utility for working with .env files in ProcessWire and it makes use of the directory structure in the great post shared by @netcarver. I think this addresses the items brought up here about vendor directory placement and also provides a clean and simple method of implementation while providing some handy tools to boot. You can view and download the code for this .env implementation strategy from this repository. This reads and caches .env file variables and makes them easy to work with in the ProcessWire config.php file. The readme in that repository provides a full rundown of directory structure and setup. Here's an overview of how it's used once you've configured it in your project. <?php namespace ProcessWire; /** * Example usage in config.php **/ use App\Env\Env; if(!defined("PROCESSWIRE")) die(); $env = Env::load(); // You can now access any variable in the .env file located in your root directory with an accessor method $env->get('YOUR_ENV_VARIABLE'); // => returns whatever that value is in .env // You can optionally make env values accessible globally in ProcessWire by assigning $env to a property // Then you can use $config->env->get('NAME_OF_VARIABLE'); $config->env = $env; // Use to set up your config values $config->debug = $env->get('DEBUG'); // ... But hey, why stop there? You can also do this: <?php namespace ProcessWire; /** * Example config.php file */ use App\Env\Env; if(!defined("PROCESSWIRE")) die(); $env = Env::load(); $config = $env->pushToConfig($config, [ 'useFunctionsAPI' => 'USE_FUNCTIONS_API', 'usePageClasses' => 'USE_PAGE_CLASSES', 'useMarkupRegions' => 'USE_MARKUP_REGIONS', 'prependTemplateFile' => 'PREPEND_TEMPLATE_FILE', 'appendTemplateFile' => 'APPEND_TEMPLATE_FILE', 'templateCompile' => 'TEMPLATE_COMPILE', 'dbHost' => 'DB_HOST', 'dbName' => 'DB_NAME', 'dbUser' => 'DB_USER', 'dbPass' => 'DB_PASS', 'dbPort' => 'DB_PORT', 'dbEngine' => 'DB_ENGINE', 'userAuthSalt' => 'USER_AUTH_SALT', 'tableSalt' => 'TABLE_SALT', 'chmodDir' => 'CHMOD_DIR', 'chmodFile' => 'CHMOD_FILE', 'timezone' => 'TIMEZONE', 'defaultAdminTheme' => 'DEFAULT_ADMIN_THEME', 'installed' => 'INSTALLED', 'debug' => 'DEBUG', ]); // Arrays aren't for .env files... $config->httpHosts = ['yourdomain.com']; // You can also get all of the values at once with this method $env->toArray(); What this does behind the scenes: Parses the .env file Casts booleans and ints appropriately where detected Caches the .env values in a file located outside of the public directory (read why below) Provides utility methods to access the .env data Optionally loads values to the server $_ENV array Values provided by the Env object are immutable Because ProcessWire has pretty much all of it's out-of-the-box configurations located in config.php, by default this only loads the values and makes them accessible via the get() method available on the object returned by Env::load(), not via $_ENV. You can optionally make your values available in $_ENV by passing 'true' to the load() method. About caching... This uses phpdotenv to read the .env file and load it's contents. There is some overhead for this process and requires significantly more work than just turning the .env into a key/value array. This application uses phpdotenv to parse the file then stores that in a cache file called env.php as a native array which is then subsequently loaded using require_once, an operation that is trivial for PHP to handle. Additionally, the object returned by Env::load() memoizes all values so the cached file is only read once during application execution and all subsequent key/value access is pulled from memory. Cache can be cleared using a provided method. I like how this came out and hope others find it useful. Interested in everyone's thoughts. It would really be great if installation and directory configuration were automated in a bash script, but I don't have the time. Pull requests are wide open for that ?

Yeah, the subresource key is a hash of the file contents so that will break at some point on @latest. Alternatively, I don't want to introduce external resource versioning since it would mean the module has to be updated to keep up with HTMX. Biggest deal for me is that, as an online privacy advocate, I can't recommend something that I wouldn't use myself. Agreed! Great way to add SPA features without fundamentally changing ProcessWire rendering. I'd argue that it's the way that interactive UI should be built to begin with.

If they leave Gutenberg off their resume.

? This is outstanding and I love the implementation. Being able to choose where blocks are available/rendered using a function is really powerful, even better than I hoped for. As usual, RPB continues to deliver so many great features that I wouldn't be surprised at all if this module even made coffee. My wife is really not going to like this.

Paging Dr. @bernhard! I'm kicking off a website project (likely the largest I've ever taken on before) soon and, of course, RockPageBuilder will be used ? It's for a large public event that will have hundreds of pages for event activities, information about entertainment and things to do around town, lodging, sponsors, promote tickets sales, etc. as well as a branded "magazine" style blog. It's going to require a lot of diversity in content and design. My question: is it possible to have multiple RPB fields with the ability to implement blocks as such: Have blocks that are available to all RPB fields (as it does now) Assign blocks to multiple RPB fields, but not all Assign blocks to just one RPB field exclusively In my case this is very useful as the "magazine", events, and main pages each have unique design elements and I would like to let users use blocks without using them where they shouldn't be and "breaking" the design of the website, so to speak. If this is possible I may have to file for divorce and marry RockPageBuilder.

@Jonathan Lahijani I'm not surprised, but still shocked. I have heard of people not adopting Gutenberg but couldn't tell if it was just a preference to not adopt. This is some critical stuff. The amount of CSS that WP stores in the database has always been problematic. I was asked to make some adjustments on a site, so logically I went to the theme CSS, nope. Then went to the page builder plugin because you can bump around a lot of values for CSS properties in different units- struck out again. Then went to the in-admin theme editor where I found a bunch of styles in a text box, most of them had '!important' to overcome the styles in the other two places. The fact that this got even worse, is feature incomplete, breaking, and seemingly underengineered is just wow. Everyone get in the time machine... <!--include /text/header.html--> <!--getenv HTTP_USER_AGENT--> <!--ifsubstr $exec_result Mozilla--> Hey, you are using Netscape!<p> <!--endif--> <!--sql database select * from table where user='$username'--> <!--ifless $numentries 1--> Sorry, that record does not exist<p> <!--endif exit--> Welcome <!--$user-->!<p> You have <!--$index:0--> credits left in your account.<p> <!--include /text/footer.html--> That's PHP 1.0 WordPress has adopted the syntax of PHP 1.0 I, for one, am truly inspired.