FireWire

@bernhard I ran into the broken recurring event that noodles was having. After performing this fix in RockCalendar.module.php everything works as expected. I'm on 1.6.1. Not sure if there's something "special" about my PW setup that is causing the issue but it works for me now.

I knew that at some point but didn't connect it in my brain when I made the map feature. The other ones were made before I knew that. The rest of them are original. I just upgraded RPB and saw the notes on the module config page which was a good reminder 👍

Hi all (yet again)! I'm still at it with some new buttons added, now up to 28 in total. New buttons include Form, LightboxGallery, Map, and CalloutImage, as well as a reverse color CalloutImage. Happy building! 😎

An escape key binding could be implemented with a snippet of code that looks for a modal element with a class or attribute defining it as active. So a binding that looks for that and executes a click action on the nearest close button or programmatic closing may be doable. That's a hypothetical based on instances where I've implemented it in my projects though, so just a cursory thought. I find myself reaching for the escape key often to exit windows, so it would be a welcome feature if implemented!

As someone who has implemented accessibility measures before, AA is the standard for public non-governmental sites serving different abilities and satisfies all legal definitions of accessibility. Adhering to AAA standards means a full compromise of the design to achieve that rating and is a rarity. These ratings are also targeted at public facing websites where legal compliance is required. A public facing site, i.e. the site that ProcessWire manages, should adhere to the standards that apply to the audience it serves and is the responsibility of the developer. The admin has a different audience. With the new theme having flexibility in customization, as with @ryan mentioning the availability of CSS variables in the new design in a more recent update post, higher levels of compliance could be achieved by theming. Even if CSS variables were not available, the admin them can be (and has been) modified. If there are special use cases where developers using ProcessWire must provide an experience for users or clients that need additional levels of accessibility then it would be a good place to have some community help developing themes that meet more strict standards. Consider this- ProcessWire itself is an application used for the production of content, not consumption of content. To that end, accessibility measures designed for content consumption should not be implemented at the cost of usability or preference for it's purpose and widest user audience. If someone needs the ProcessWire admin to look like this, then I and many other users, would kindly ask that they implement a theme to accommodate that and release it to the community as a module. This is a good target. Adjusting shades to help with contrast would help a wide audience with minimal impact on development costs. Tabbing and escape key binding are good. Considerations at this level are general good practice. The differences between applications (ProcessWire) and websites (a product ProcessWire can be used to produce) is a good thing to keep in mind. It would be difficult to expect the end user of ProcessWire to have the ability to use all functionality and manage a site on the back end using a screenreader and keyboard alone which is one of the goals of accessibility even at the AA level. I say this as a person currently developing a website for a nonprofit organization that serves the Parkinson's disease community. Their site needs to be accessible (we are targeting AA) but they would never consider having the admin they work with be accessible by the people they serve.

Hey translators and polyglots! v2.1.1 has been released to address a bug introduces in 2.1.0 that affected some, but not all, users. If you are experiencing issues please reference this Github issue that may provide more information. If you haven't experienced any bugs, upgrading is still recommended to prevent any oddities in the future. Unlikely, but safer than sorry. 2.1.1 is available via the modules directory and can be upgraded from the module config page in your ProcessWire admin. Thank you to @jacmaes, @ryangorley, and others contributing in the Github issue for reporting and assisting with debugging!

@bernhard Many thanks as always 🙌

Heyo, Just ran into a conflict between RPB and other fields on the page. I'm using a custom inputfield that uses Quill as the editor. There's an event listener that is catching changes in an instance of a Quill input while the field is located outside of RPB blocks. InputfieldRockPageBuilder.js L327 // monitor inline ckeditor fields $(document).on("blur keyup paste input", "[contenteditable]", function (e) { RockPageBuilder.changed(e); }); Quill uses a contenteditable attribute for the editor so an instance of that field anywhere on the page is triggering a RPB field update event. // monitor inline ckeditor fields $(document).on("blur keyup paste input", ".rpb-item [contenteditable]", function (e) { RockPageBuilder.changed(e); }); I scoped the event listener selector by adding .rpb-item and that kept it from firing when editing a Quill field, but I don't have any CKEditor fields to test whether that affects other fields. "That fixed it for me, don't know if it breaks something for someone else." 😆

@ryan Makes sense. Really looking forward to seeing what y'all been cooking up! I paused the other day and appreciated all the quality of life improvements that have come over the years and value them as much as the big features. Almost can't wait. It's like Christmas for adults, who are also developers.

Hey everyone! Fluency v2.1.0 has been released with new features and bugfixes. Translation cache now caches translations permanently until cleared on the module config page when translation caching is enabled. Some Fluency methods are now hookable. Refer to README for documentation and use case. Credit to @Hari KT for inspiring this feature. Globally excluded strings can now be entered either one per line or all on one line separated by a || (double pipe). Credit to @bernhard for the feature suggestion Translating static strings using the ProcessWire translator now offers the ability to specify the language code to be used for the source language Fix issue where strings configured to be excluded from translations on the module config page were being translated. Credit to @bernhard for finding and reporting Correct issue where custom language code field that may optionally be added to ProcessWire language pages was inconsistent and incorrectly documented. Fix missing localization strings for some errors Various small improvements, some bugs that had not yet affected regular usage Various housekeeping and code cleanup that only matters if you like reading the source 🤷‍♂️ Thanks all, and please report any issues!

I think this approach is an excellent idea and hopefully something that will be considered. In addition to the benefits @teppo described, using CSS really open things up for JS as well where getting/setting values via scripts could make admin development very dynamic. Laying some future friendly groundwork in CSS would be a major advancement.

Boy howdy, I'm pretty excited to see this.

Perfect!!! This will make everyone's dreams come true 🙌 I have been looking forward to spending more time with RockCalendar. I've just had to prioritize things according to client needs so I've had to put that feature on the back burner but can't wait to work with it. It's such a relief to know that there's a quality modern module to handle this feature. Well done and many thanks! Note: It double posted for some reason, but this is the better comment 😆

Perfect!!! This will make everyone's dreams come true

@bernhard This is something that is coming up in my current project for a client that has support group meetings. For example, a support group meets every Monday at 3pm but the second meeting next month has to be moved from 3pm to 4pm due to an unforeseen situation, or maybe an in-person meeting will be held online instead. This would also apply if an occurrence needed to change days, so a recurring event could take place every Monday at 3pm but meeting "X" will take place on Tuesday due to that Monday being a holiday. This happens regularly enough with the client's operations that I have to take it into account. In this situation they would need to: Adjust the start/end time or possibly day for that specific instance Update fields (such as a description or body field) for this instance to inform visitors of any changes when they visit the site Click a checkbox to mark this instance has having had a schedule adjustment which renders a "badge" on that event when rendered in a list of support groups and make it easy to query with a selector. Will be used to differentiate occurrences that have had a schedule change vs just some edits to content somewhere on the page. A couple of months ago I was tinkering with showing/hiding fields to achieve this but I haven't worked on that component of the site since then and don't remember where I was at with it.

@zilli This is a complete coincidence and the only reason I can speak to anything on this topic is that was just tinkering with PagesVersionsPro a week or two ago on a site that I'm building. Some interesting timing! @sodesign Here are a few comparisons. I'm not familiar with Craft, but hopefully the info will help your comparison with that. Differences from WP Versions are manually performed, there currently isn't an autosave feature, however this may change in the future if/when PVP replaces or supplants ProDrafts (that's a Q for Ryan) WP's style is more of a timeline "snapshot" method whereas PVP works with true page versions that are completely separate instances related only to the live page or version you created it from. You can manage and switch between versions based on a name and content first approach. You can create versions and then pick any one of them to edit or restore at any time without the "restore and edit" process that WP requires, so no "version stacking" by replicating when you may not need/want it. Because versions are manual, all versions are always named which is helpful for picking out specific states of a page or intent of edits rather than by timestamp like in WP. Where WP shows you HTML/markup comparisons between versions, PWP's compare feature shows you changes for each field as fully rendered field values, including image fields, so that you can see the changes side by side which is a much better end user experience. PVP allows you to fully load a version of a page in the browser and see it as visitors would see it for a visual comparison. It's worth noting that while you can create versions from any version whether live or not, comparisons are always made between a given version and the live page. I personally think this is a better approach because end users pretty much only care about what a version looks like compared to the live version. Please feel free to correct me if I got anything wrong with WP's implementation, I've seldom found it useful (if not outright frustrating) and may not be up to speed with more recent features. Also, I believe PVP is still in beta. I don't have enough experience to know what that means for real world use. If you have access to PagesVersionsPro I recommend installing it and taking it for a spin. You'll get the gist quickly and be able to decide how it works out for your needs. I'm looking forward to spending more time with PVP. For my current project I had to stick with ProDrafts as it's a carryover feature from their last PW site and it's not compatible with PVP. There was a post somewhere by @ryan about the status of PVP and a potential new release at some point in the first half of 2025 but he would be able to better speak on the status and plans for the module. Hope that was helpful!

@elabx Those are really just a matter of being thorough with security. Another answer to your question about where to put the env folder is anywhere you want really. As long as you update your composer.json file so the namespace resolves to the location that folder you can keep it anywhere.

@elabx Same here, once I stumbled across that Github issue with performance I wanted to implement caching. There were a couple of places I needed to access env variables elswhere in my code, so this all grew out of some real world experience. I have my env folder in the root directory. The folders in the repo come with .htaccess files already placed which block access to any assets via http request, no need to make any changes to the ProcessWire .htaccess file. This can be used without any changes to ProcessWire itself.

Hello! I use .env files on every ProcessWire project to manage environment-specific configurations and settings. I've built a ProcessWire specific utility that makes using .env files a breeze. This post isn't intended to debate .env vs. config.php, use what you're comfortable with and prefer. That said, here are a few benefits to using .env files that may make it worth considering: Native support on web servers, including Apache, they are not served via http request by default True environment based secrets and settings management A standard file widely used and accepted as the method for managing secrets and sensitive values Able to store any value whether sensitive or not and access them globally Building a dedicated solution came from a discussion here on the forums where I threw together a rough implementation that needed little polish for real world use. It makes use of phpdotenv. This utility delivers the following: Easy use of and access to .env variables Caching the parsed .env for performance. This is a significant part of this utility and addresses a known need Automatic .env change recognition and re-caching Utilities to make working with environment variables feel ProcessWire native and a few extra nifty things What it isn't: A module. It's not possible to make a module for this need because the information kept in a .env file needs to be available before ProcessWire boots. Adding this to a new or existing project is very easy. It's designed to implement quickly and use immediately in your projects. Full documentation is provided in the Github repository. Here are a few examples of using this tool: <?php namespace ProcessWire; use Env\Env; if(!defined("PROCESSWIRE")) die(); $env = Env::load(__DIR__ . '/../'); // Make env available throughout the application $config->env = $env; $config->dbName = $env->get('DB_NAME'); $config->dbUser = $env->get('DB_USER'); $config->dbPass = $env->get('DB_PASS'); // Env::get() takes a second argument that is the fallback value if for any reason DEBUG doesn't exist $config->debug = $env->get('DEBUG', false); // Conditional values. By default, if the condition is falsey, Env::if() returns null $config->adminEmail = $env->if('APP_ENV', 'production', 'you@youremail.com'); // A fourth argument will be returned if condition is false, truthy/falsey output can be env var names or specific values $config->adminEmail = $env->if('APP_ENV', 'production', 'ADMIN_EMAIL', 'you@youremail.com'); // Conversely, you can also check if a condition is not met. $config->adminEmail = $env->ifNot('APP_ENV', 'development', 'ADMIN_EMAIL'); // Use one env value to set multiple config properties $config->advanced = $env->if('APP_ENV', 'production', false, 'ENABLE_ADVANCED'); // Never in production, change locally in env as needed $config->adminEmail = $env->ifNot('APP_ENV', 'development', 'ADMIN_EMAIL'); // Never send an email in dev, always on staging/production These helper methods make is very straightforward to implement a dynamic config file. This can be useful for using secure .env values while retaining the ability to commit and upload some types of changes to your config.php file without needing to touch .env values on the server. You can also use Env::pushToConfig(). As long as you use the "screaming snake case" naming convention for your environment variable names, type and value recognition are handled automatically. <?php $env->pushToConfig($config, [ 'usePageClasses' => true, 'templateCompile' => 'TEMPLATE_COMPILE', 'debug' => ['DEBUG', false], // Fallback to false 'advanced' => $env->if('APP_ENV', 'production', false, 'ENABLE_ADVANCED'), 'adminEmail' => $env->ifNot('APP_ENV', 'development', 'ADMIN_EMAIL'), 'httpHosts' => [ 'something.com', 'staging.something.com', 'something.ddev.site' ], ]); Using Env in your application files and templates can be very useful. In the above example we assigned the Env object to $config->env. This lets you access your .env variables globally and use some helpful methods. <?php if ($config->env->eq('APP_ENV', 'development')): ?> <script src="/some/development/stuff.js"></script> <?php endif ?> <?php if (!$config->env->exists('GOOGLE_API_KEY')) { $wire->error('A Google API key could not be loaded from the environment file.'); } try { // Do something that could fail } catch (Exception $e) { $message = $config->env->if('APP_ENV', 'production', 'Oh no. Friendly message here', $e->getMessage()); } This utility also automatically casts 'true' and 'false' values in .env files to booleans, and casts numbers to integers. It also includes several configuration options. I have been using this tool in production and have been happy with it. Maybe you might find it helpful in your projects as well. If you like it, throw a star on the repo. If you run into any bugs, file an issue on Github. I may publish it as a composer package at some point. Env utility for ProcessWIre on Github.

@bernhard Outstanding! Yet another great PW feature I wasn't aware of. Thanks for sharing!

@monollonom Thanks for the insight. I haven't had a chance to work on that yet but I'll report back. I didn't think to check that output formatting would be the culprit since it's changing the output class itself whereas output formatting on other fields changes the value output to the page, like a text field for example. I'll report back when I have a chance to tinker.

@bernhard It's never too late to star a repo 😎 Thank you!

@bernhard Your wish is my command 🧞. Dev branch has one string per line entry for globally excluded strings on the module config page.

Sorry about that, I didn't think of that and nobody ever mentioned it before 🤔 I can add that.

@bernhard Apologies for the delay! I've pushed updates to the dev branch. I had a few changes that were already going into the next version that I had to do some extra testing for and a lot of housekeeping. Let me know if this works as well for you as it did me and I'll push another version to main https://github.com/SkyLundy/Fluency/tree/development New feature that some may be interested in- adding DeepL languages for translation that are technically supported by their API but not delivered by the languages endpoint yet. You can read more about when that happens and why on this DeepL documentation page. To manually define languages in Fluency that are supported for translation, you can use a hook. This will make the language available both within the global translation tool as well as available for configuration with a ProcessWire language on the module config page. <?php namespace ProcessWire; // ready.php use Fluency\DataTransferObjects\{EngineLanguageData, EngineTranslatableLanguagesData}; // Hook after Fluency gets the available languages from the DeepL API wire()->addHookAfter('Fluency::getTranslatableLanguages', function (HookEvent $e) { // $e->return is an instance of EngineTranslatableLanguageData // The `languages` property returns an array of EngineLanguageData objects $languages = $e->return->languages; // Create a new data object, define the values according to the API docs, add it to the original languages array $languages[] = EngineLanguageData::fromArray([ 'sourceName' => __('Arabic'), 'sourceCode' => 'AR', 'targetName' => __('Arabic'), 'targetCode' => 'AR', 'meta' => [ 'supports_formality' => false, // This is determined by DeepL, check to see if it's available in their API docs ], ]); // Instantiate a new EngineTranslatableLanguageData object with the language array then assign it to the return value $e->return = EngineTranslatableLanguagesData::fromArray([ 'languages' => $languages ]); }); @Hari KT This is a new method supported by Fluency to add Arabic to Fluency before DeepL lists it for translation. Thank you for inspiring a solution with your Github issue on languages not being available in Fluency. This is available on the dev branch of the Fluency repo if you would like to help test it out @ryangorley This will address the issue you had with Traditional Chinese, albeit a lot later than may be useful for you, but the hook above can be modified to resolve that problem. I'm surprised how long the language had been listed as "available soon" on their API documentation 🤷‍♂️ I would have gone this route sooner had I known there was some documentation about this, I don't think it existed at the time.