FireWire

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.

Hello all- FieldtypeFormSelect does what the post title says it does. Lets you create a field to select a form created by the FormBuilder pro module. This type of field (or some variation of it) has probably been done elsewhere but I put this together with a few extra considerations for flexibility and utility. When creating a form select field you can choose what forms will be present and how their names will be shown. Let's go to the pictures: A form select field: Creating fields to choose from specific forms? You have options. You can also create a field that will only include forms that begin, include, or end with a specific string. This allows you to create a field once, then use form names to help group them together and add/remove them from form select elements 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 ever edit a field configuration. For example, this field will only allow you to choose forms having names enting with "request", so "customer-support-request" and "consultation-request" will be included, but "newsletter-signup" and "call-to-action" won't. You can also choose how the form names will be presented in the select element. They can be shown as they are originally named, as spaced words, or as capitalized/spaced words. So, how does this field work? Form select fields store the ID of the form you select, but it also has a nice trick for working with forms in your markup too. FieldtypeFormSelect makes use of ProcessWire's built-in field rendering to keep things simple. Let's go to the code. <?php $page->select_a_form; // => Outputs the form ID, or null if no form has been selected // You could do this to output your form markup echo $forms->render($page->select_a_form); // Or you can do it this way. If a form has been selected the markup will be output to the page, if no form is selected, the output will be null. echo $page->render('select_a_form'); The fields you create will always be up-to-date with the forms that have been created in FormBuilder. This module also keeps things tidy- if a form is deleted that has been selected in one or more fields, on one or more pages, the values for those fields will be set to null so you won't experience any reference errors to form IDs that no longer exist. My primary use is to have a form select field available for blocks created in the RockPageBuilder module by @bernhard. I wanted each section on the page to contain an option to include a call to action button that can be a link to a page, a link to another URL, or that can open a modal with a call to action form to capture leads and visitor contact information. It's a great way to easily add flexibility and give some extra power to the end user when considering what they want visitors to do when browsing their website. RockPageBuilder is not required, but makes for a useful example! Protip for website designers- in my experience and empirical study of conversion analytics for sites that I've built, buttons located within sections of content on the page captured more leads and outperformed a call-to-action button in the page header, the call-to-action form at the bottom of the page, and forms located on a "Contact Us" page- by far. The true purpose of this field is to get the right forms in the right places quickly and easily without any need to work around markup output strategies or short codes. Contributions on Github are welcome if there's some extra functionality anyone wants to add that makes sense. Please let me know if you run into any bugs as well, when there's some extra usage and testing I'll submit it to the modules directory. Hope you find it useful! https://github.com/SkyLundy/FieldtypeFormSelect

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.