FireWire

I didn't know about DDEV until recently. It's been a gamechanger and I have yet to even harness it's full potential. I use it on everything now and can't speak highly enough of it. Many thanks to @bernhard

Just remembered this site. It was created many years ago with some really (really) humble beginnings to translate jQuery into JS as features became supported enough to be safely used. Ironically, it's aim is to suggest you don't need jQuery- but the content has grown so much now it could just as easily be used as a reference of sorts to show everything you can do with it. https://youmightnotneedjquery.com/ Even now with feature parity, jQuery really does shorten and simplify a ton of things.

I like his serious and thoughtful approach in this video. It's pretty crazy to see all of the deprecated methods in jQuery that have been implemented in vanilla JS that I've taken for granted. I haven't used jQuery in years but this video really takes me back to when it was more than a convenience- it was pretty much essential to get things done, done well, and done on time for projects. Pull up a chair kids and let grandpa tell you about the old days when we had to write JavaScript to mimic the placeholder attribute for form inputs because not every browser supported them. Not a joke. Random sidenote, I ran into this guy in a very tiny sushi restaurant in Japantown on a trip to San Francisco earlier this year. That mustache is on another level in person.

I just built an application using Livewire and it was a blast to work with, mentioning given NativePHP's support for Laravel. I recommend it if there's a project that has requirements to justify it while avoiding JS hell in full stack. I essentially wrote 130 lines of JS for an app with AJAX, dynamic forms + validation, file uploads, notifications dispatched from the server, SPA navigation, polling, etc. That aside, it would be pretty amazing to see a PW to desktop bridge. For all the power full stack frameworks offer- they're too open ended for a lot of projects and ProcessWire would be really rad alternative to see in this context. Hope to see something with your project @flydev! First app I would build would be an app to track all the work I'm not doing while I'm building a ProcessWire desktop app (billion $ idea, get in on the ground floor, investors welcome).

I'm dying ?

Glad that worked! Fix has been pushed to main. Thanks for finding, reporting, and testing @wbmnfktr Download latest on Github

@wbmnfktr I think I have an idea of what happened. Possibly typed some || where some && should have been. Pushed a potential fix to the dev branch. Can you give it a shot and let me know if it fixes the issue?

Hey all! This is a module to enhance forms built using the Pro FormBuilder module by providing the ability to submit them in place using AJAX and HTMX. FormBuilderHtmx works in harmony with FormBuilder by handling front-end rendering and AJAX and lets FormBuilder manage form configuration and processing. FormBuilderHtmx provides a drop-in replacement for the $forms->render() method and provides all native features and behavior (and adds a few extra superpowers to boot). Noteworthy features: Zero configuration, install and render AJAX powered FormBuilder forms immediately Render multiple forms on the same page. Supports both multiple instances of the same form or different forms. Each form is processed independently. Non-intrusive, can be used alongside FormBuilder's native rendering methods and does not modify core module behavior Perfect for forms embedded in popups and modals Does not conflict with styling and other JavaScript already in-place, only handles the form submission/response loop Automatically disables the `Submit` button on submission to prevent duplicate requests Provides the ability to add a custom 'spinner' shown when a form is being processed Gives you the ability to add additional HTML attributes to your FormBuilder <form> element. Add additional custom functionality using HTMX attributes, hook into form actions with your JavaScript, or even add AlpineJS directly to your forms. Compatible with FieldtypeFormSelect, let users choose which forms to embed, your code determines how they are rendered Uses HTMX, a stable, powerful, and tiny (14kb gzipped) library, installation documentation available here This module is BYOH (Bring Your Own HTMX) in that the HTMX library is not included or available within this module. This ensures long-term stability by not locking FormBuilderHtmx to external asset versioning. FormBuilderHtmx uses stable core HTMX features so use the library version that works for you and confidently add this module to both new, existing, and future ProcessWire applications. In some instances CSRF protection may need to be disabled to submit forms with this module. Just test your forms and you're good to go. Using this module is truly easy. <!-- Replace the native $forms->render() method with $htmxForms->render() --> <?php $htmxForm = $htmxForms->render('your_form_name') ?> <!-- Use native ProcessWire properties and methods as usual --> <?php echo $htmxForm->styles; echo $htmxForm->scripts; echo $htmxForm; ?> Presto. You can optionally include a helpful 'spinner' or activity animation that will be showed to users while their form request is being processed. Check out these ready-to-go examples you can use in your projects. <style> /* Add these styles to your CSS, the `.htmx-request` must be present as shown here. Be sure to include any CSS your 'spinner' may need, and style everything as desired */ .activity-indicator { display: none; } .htmx-request .activity-indicator, .htmx-request.activity-indicator { display: block; } </style> <!-- Optional second argument matches that of the $forms->render() method for pre-populated values The third argument is the CSS selector matching your 'spinner' element --> <?= $htmxForms->render('your_form_name', [], '#indicator-for-the-form') ?> <div id="indicator-for-the-form" class="activity-indicator"> <span class="spinner"></span> </div> Presto (again) Check out the documentation for detailed usage and other available features. Pull requests and issues filed on Github are welcome, or drop by here to get some help! Install as a ProcessWire module Install using Composer Download from the FormBuilderHtmx Github repository . Cheers!

I didn't think about that, but it could be. I don't want to make assumptions about ease of implementation. Breaking changes could be mitigated with fallbacks- use the env if it's available, and fall back to config object if not. I think what would be a true PW4 change would be full adoption of .env and deprecation of config.php. A case could be made that fallbacks now can introduce gradual adoption and make a breaking change in PW4 less impactful. I hadn't seen this discussed there in a formal repo thread before, but good to see interest elsewhere. IMHO, the initial framing of the request around 12 factor apps could have been simplified to just benefits and good practice. Conversely, the argument that not everyone is building 12 factor apps isn't a case against it. All said- I don't want to be critical of a conversation that happened that long ago, I mean- who would I be to talk? I wasn't using .env files in 2017 ?‍♂️ I do want to share a thought on this specifically in ProcessWire context. One of my favorite things about PW is the file structure philosophy where core lives in /wire and templates, styles, additional modules, assets, etc. live in /site. Site is a living breathing volatile folder and the domain of the developer to extend ProcessWire as a project demands. Replacing /wire is one of the most frictionless upgrade concepts ever and it's flat out elegant. It would be great to see the /site folder adopt that- a true "drag-and-drop" self-contained application directory that can be deployed anywhere ProcessWire exists. The /wire directory wouldn't be dependent on /site, and (aside from core version) /site wouldn't be coupled to /wire. Consider that the root directory is already environment specific. The .htaccess file, node_modules, vendor, .git, etc. are all in environment context. The use of .env fits here. This may come off as an esoteric or abstract argument, but think about how much time you spend naming things in programming and tell me that's not the world we live in ? To address a point in that Github thread as to considerations made inside /site for environment, such as an 'if' statement whether on dev or production, I think that's great for application logic that responds to the environment but does not alter it. It would be great to see this adopted into core, but as always with a project like ProcessWire it's up to the people doing the great work of maintaining and improving it to determine priority. Even if it's not implemented in core, I hope to have made a case for adoption in individual projects.

It's been talked about elsewhere here in the forums, but an alternate idea would be utilizing .env files. It would satisfy both the installation process and long-term management of values. Some benefits: Widely used across applications, frameworks, and languages running in a web server environment and strongly recommended as a standard practice Secure by default. Web servers do not serve .env files Provides the ability to manage local and production configurations separately Frameworks like Laravel provide a .env file as well as a .env.example file containing all variables used in the application. This is kept up to date, used to document application requirements, and is committed into the repository Values that are not security-critical can be safely stored in the example file Provides a convenient location for additional non-ProcessWire site/app specific values such as API keys, or those required for modules Solves the issue of excluding site/config.php from a repository given that it's a required file containing specific syntax and $config object property assignments If .env was available in ProcessWire I would have my Fluency module look for translation API keys there rather than store them in the database. A benefit there is that different environments like local/ staging/production can mean an environment that is yours and an environment that is a client's. Pulling the latest copy of a database from production wouldn't require manually re-configuring modules that require API keys, or module registration keys. It would be good to eliminate storing security-critical values in PHP files entirely. The .env file could be generated and populated during the ProcessWire install process pre-excluded in the .gitignore file. Example: ENVIRONMENT="development" # ProcessWire PW_DB_HOST=localhost PW_DB_NAME="your_database PW_DB_USER=your_database_user PW_DB_PASS="LowuHeju7[BoI3" PW_DB_PORT=3306 PW_DB_ENGINE=InnoDB PW_DEBUG=true PW_CHMOD_DIR=0755 PW_CHMOD_FILE=0644 PW_USE_PAGE_CLASSES=true PW_USE_FUNCTIONS_API=true PW_PREPEND_TEMPLATE_FILE="_init.php" PW_USER_AUTH_SALT=d5e3ac4beda1e382255bbd8744d7e815 PW_LOCALE="en_US.UTF-8" PW_TIMEZONE="America/Los_Angeles" PW_DEFAULT_ADMIN_THEME=AdminThemeUikit PW_INSTALLED=1580675413 PW_HTTP_HOSTS = "domain.com,www.domain.com" # Some API that is used EXTERNAL_SERVICE_API_URL="https://api.someservice.loc/v2" # Development EXTERNAL_SERVICE_API_KEY=0d41fe1b68244f4ea51ae5e4abd24fab # Mailgun MG_KEY=key-192cde47ab73095e747ebe7556577b2d MG_DOMAIN="mg.somedomain.com" # Forecast.io FORECAST_IO_KEY=c28096383d66bcb1e2cb9ec37153f85c To take the idea further, it could be integrated with the ProcessWire API in a way that would prevent conflicts, keep .env variable naming organized, and make any value added by the developer available. Something like: <?php // An accessor method, this is probably the cleanest and resembles other frameworks $config->env('SOME_ENV_VARIABLE'); // Nested under a property acting as a namespace $config->env->SOME_ENV_VARIABLE; // On ProcessWire projects I implement some extras to easily interact with .env values without needing to access them directly. $config->envIs('production'); // boolean I haven't built a ProcessWire site without implementing this for many years and there's a great widely-used great package that provides .env values to PHP. There are also hosting providers that make environment variables/secrets manageable through their admin UI that eliminates the need for an actual file in production entirely. If ProcessWire were to implement environment variables it could look to values that may already exist and fall back to using a file. Implementation aside, if someone is able to access phpinfo() in production it's a critical issue beyond exposing config values given the totality of information dumped by that function.

@bernhard So a quick fix for the FormBuilder isssue with the topbar is to exclude the page it renders inside the iframe by template name. <?php public function addTopBar(&$html) { if (!$this->isEnabled('topbar')) return; $page = $this->wire->page; if (!$page->editable()) return; if ($page->template == 'admin' || $page->template == 'form-builder') return; // Adding the extra check for FB here solves it if ($this->wire->input->get('rfpreview')) return; if ($this->wire->config->hideTopBar) return; // etc. It's the only instance of an iframe issue I can think of and that's because the contents are rendering from a page within ProcessWire where it isn't possible for it to be front-end editable.

@bernhard I'll look into this and reach out when I have more information. The form is being rendered using one of FormBuilder's built in methods to embed as an iframe. The iframe is being rendered in a UIkit modal, but that isn't causing any conflicts which is OK. This is only the 2nd time I've used FormBuilder so I'm no expert ha!

Hey @bernhard! Is there something I can add to an element to prevent the editor from rendering? If I can add an attribute or class to something that would disable editing on a per-element basis? I could skip elements where it isn't desired. This is a FormBuilder form embedded as an iframe: Would be a good idea to eliminate them in iframes altogether? Not sure if there would be instances where that would cause issues though.

@iank I'll double check on my end, I may have not tested thoroughly enough, or got inconsistent results. Not sure about yours, but in my case the most important component was the showIf since it is the primary method of indicating the action a user should take and important way to keep the UI tidy. If you continue configuring your fields to use requireIf then any update to RPB would mean those field settings will be respected. So hopefully it doesn't slow your development too much.

Also confirmed that the fix makes it possible to use requireIf in blocks!

This is pretty amazing stuff. I recently worked on a few tasks for a client that involved parsing ticket sales data in CSV and Excel formats. I was only working with ~67,400 rows of data. I used my go-to library Simple Excel which gets the job done and has a great interface for looping, filtering, reading, writing, etc. data. Maybe I'll try playing around with that implementation at some point... I guess then I'd have to figure out how to write something efficiently- because deadlines can wait (haha). Good share!

Hey all! Fluency 1.0.8 has been released. Now available for upgrade in ProcessWire admin and in the modules directory. For the Composer fans out there, Fluency has been added to Packagist and can now be installed by running `composer require firewire/fluency` This version contains a new feature where you can now disable translation on a per-field basis. Just check the "Disable translation for this field" checkbox under the 'Details' tab and Fluency will not be added to that field. This is helpful where fields may contain different content for different languages but may not be suitable or desired for translation- email addresses, phone numbers, full string URLs, etc. It can help clean up the UI when editing pages and prevent unnecessary translations. Also includes the following: Activity overlay text has been resized and reformatted, now looks better where the size of the field is smaller. Translation cache is now enabled by default as stated in the README file Performs some polite cleanup when uninstalling the module. Fix issue where CKEditor fields in collapsed Repeater and RepeaterMatrix fields may fail to initialize. Credit to @ryangorley for finding/reporting. Fix issue where fields with combinations of languages that are and are not configured in Fluency are properly handled. Languages that aren't configured in Fluency are now indicated where others have the translation button present. Credit to @ryangorley for finding/reporting. Fix for issue where the way that Fluency stored module configuration data may cause ModSecurity false positives depending on how rules were configured on that server. Credit to @update AG for finding/reporting. Various minor fixes and code cleanup. Please share any bugs here or, if possible, create an issue in the Fluency Github repo. Thanks!

Awesome and inspiring! This is some fantastic work @bernhard and showcases real talent. Wi-Five!

@Macrura I did take some inspiration from those conversations. Glad you find the module useful! I've developed it on the fly and am using in a site that I'm building right now so any feedback or bugs you can report from your use will be helpful.

I think you're making my point here- you're a graphic designer who has learned web. That means you're a web designer. Please don't take what I said as a negative towards graphic designers. What I'm explaining is that there are distinct roles. I can design and create a UI but I'm under no delusion that I have the talent of so many graphic designers I've met- and you are probably included in that group of professionals. I've worked with award winning designers at ad agencies for clients across the US, and they are phenomenal but still had much to learn when we worked together on web projects. This is by no means any insult or speaking badly of them, and they understood the work we needed to do together. I'm referencing graphic designers who aren't web designers. One is not more important than the other whatsoever! We can agree that a graphic designer doesn't have to test the poster they designed to make sure it works on mobile. I would never expect that printing a website I made out on a poster would be even remotely the same thing. In fact, please don't. It would look really bad. So when I say that I haven't met a graphic designer who knows web design, it's because if they did- they would be a web designer, in context of designing a website. Please don't take what I've said in a conversation about a web implementation on a web developer related forum as something that it isn't, and I apologize if I came off as aggressive or insulting. My comments were meant to address the original post and nothing more. So, I apologize if my comments came off as rude or dismissive.

I don't think anyone was knocking Cargo per se, just that according to OP, it didn't satisfy the requirements that the client had already stated to begin with. I will second @da² in that I also had pages on the Cargo site that appeared to be broken and wouldn't load for me. This is definitely an important distinction. It must be stated that the client is asking a professional web developer for a solution, not an artist. If they want to make an internet art piece, then they can. If they want a website that actually does something, like get new business opportunities, I hardly think that a graphic designer that thinks doing fancy font work could pull it off. I've never met a graphic designer that knew what the optimum width, in character count, text content should be for a user experience. They also couldn't explain when to use a .png or a .jpg. They don't think about things like variable background image size ratios, why text in an image is a bad idea, how people's experience looking at a print postcard differs from a website- simply stated, why something that looks really pretty can actually be a bad thing. Obviously the web doesn't have to be ugly- but the web demands more that aesthetics. If a client doesn't know about this- we educate them. If after hearing what we have to say they decide they don't care, that's the grave they're ready to dig for themselves. I have a close friend who works for a company that just got sued for lack of accessibility on their website last week. I also know that a manager there demanded that their preferences dictate how the site looked, now they get to deal with the repercussions. Probably going to cost them $10k in settlement money, then legal fees on top of that, and however much they'll be paying someone to fix their site. I'm on the side of the developer and I believe we have a profession that is constantly challenged by people who have been lulled into a false sense of "my opinion is as good as your facts". Having said all of that- if this is a company that simply does not care about anything other than creating high art on the internet- then they don't need a web designer/developer professional, they need to go find software like they did to create posters- or just put a .jpg up as their home page.

FieldtypeFormSelect lets you create fields to select from forms created using the pro FormBuilder module. Features: Create select fields that allow for choosing forms when editing pages Fully compatible with FormBuilder, render forms using native methods Choose which forms will be available to choose from, each field is configured individually Choose how form names will be presented in select elements Compatible with FormBuilderHtmx FieldtypeFormSelect lets you create fields like this, configured as desired. Choose which forms will be present. Including forms where names start/end or contain a value allows you to create a form select field once then use form names to help group them together, or add/remove them from form selects without editing the field. This is also a pretty simple way to allow end users to create forms that will be selectable without having to edit a field configuration. For example, this field will only allow you to choose forms having names ending with "request", so "customer-support-request" and "consultation-request" will be included, but where forms with names like "newsletter-signup" and "call-to-action" won't. Choose how you would like the form names to be presented in the select element. They can be shown as they are originally named, as spaced words, or as capitalized/spaced words. Rendering in your templates is straightforward <?php $page->select_a_form; // => A form ID, or null if no form has been selected // Render using the native FormBuilder method echo $forms->render($page->select_a_form); // Alternate method. Selected form will be rendered, if no form is selected output is null. echo $page->render('select_a_form'); Form select fields store the ID of the selected form and FieldtypeFormSelect makes use of ProcessWire's built-in field rendering to keep things simple. The fields you create will always be up-to-date with the forms as they currently exist. If a form is deleted that has been selected in one or more fields, those values will be set to null so you won't experience any issues with references to form IDs that no longer exist. Your templates and pages stay free from errors. My primary use is to have a form select field available for blocks created in the RockPageBuilder module by @bernhard. I want each section on the page to contain an option to choose any form that will open in a modal to put the power of choosing forms in the hands of the user. RockPageBuilder is not required, but makes for a powerful example. Contributions and issues are welcome on Github, or stop by here for some help! Install as a ProcessWire module Install via Composer Download from the Github repository Cheers!

I'll chip in some thoughts here, and this is from a perspective of caring about you @titanium in this situation. Well... they're graphic designers, not web designers. I've lead a web team and trained graphic designers to become web designers because they are not remotely the same. I always take the route of asking questions- a lot of them- because I wouldn't be able to make an accurate recommendation without understanding their needs. So I'd ask about more specifics about their design, view a mockup if they have one, understand what they're asking for because it does sound to me like they're asking for the moon. It's a moment where people reveal their level of expertise, or lack thereof, in the first sentence of their request. Sounds like they want * { position: absolute; } This is why I always operate with this thought in mind: what a client asks for does not have intrinsic correlation with what they need, or even want to begin with. Maybe they actually could achieve what they want using sane tools like @bernhard's builder. I'm sure there are more specifics to your situation and I'm not sure of the relationship you have with this client, but I would be concerned that they're going to end up trying to do something that isn't possible, or is so remotely possible that it's not worth their time, or yours. It might be worthwhile to ask yourself: Is this client expecting something that can't be done that may get you stuck in a position where you can't deliver? You're the expert in this field. Wix, Squarespace, GoDaddy Website Builder (lol), etc. They all fundamentally build in blocks with all of the standard limitations of the web. If they want to be big kid web designers then the onus of finding a tool that lets them do what we do is their job, in my most humblest of opinions.

@update AG Great to hear! I changed how Fluency stored config data. The issue you experienced helped find an edge case where the module may cause issues for some people. Your issue where you experienced two translator pages has also been fixed as well. Appreciate the feedback and helping make the module better. I'm going to add this to the next release but will try to see if I can prevent any need to uninstall/reinstall and preserve settings when upgrading.

Impressive and awesome module! Nice work!