FireWire

Perhaps the module can better communicate this in some way. I'll think about ways to possibly remind superadmins if translation is not fully ready. Google has more languages, DeepL has a few extra features. The extra features in DeepL have defaults that you only need to change if you really want to, so no additional configuration. I prefer the translations from DeepL, but Google is a good alternative to have because of their language selection. I've had some challenges with this myself. I usually create a dev key that is unrestricted for development since I know that it won't be used anywhere else and a separate API key for production where the IP address will be stable and the setup is more permanent. No problem at all.

@bernhard I just found this one myself this week 🤦‍♂️ I was so proud of my code being 8.4 ready too 🤣

Framework 16 daily driver here, excellent choice. Linux? Do it! Outstanding support on the hardware and once you settle in you'll wonder how you ever had to endure Windows.

@cst989 Okay, so I was unlcear if the entire page was showing a 302 or if just the file was showing a 302. This is going to lead you astray on this issue. The $this->modulesJsPath is a private variable limited to the Fluency class and isn't accessible anywhere else in ProcessWire. So if you attempt to dump that anywhere outside of a function in the Fluency module it will return null. If you are dumping this from within a function in the Fluency class then that is a different story. Let's try this. In a template file, run this code and share what you see: <?php $result = $fluency->translate('en', 'de', [ 'Testing the translation service', ], [], false); var_dump($result); die; ?> This will test to see that translation is set up correctly. If it isn't then it may be a configuration issue that Fluency is not detecting or handling.

Outstanding work! I also appreciate the botany refresher, this module is useful and educational.

@cst989 If you attempted to dump {$this->moduleJsPath} from any method in Fluency besides of init() and it's null then init() isn't being called. If init() isn't being called then ProcessWire isn't initializing the module. If you are seeing the bookmarks page then ProcessWire sent you there and the Fluency asset will return a 302. In this case it looks like ready() is being called but init() isn't but I am guessing on that. That's controlled by ProcessWire. I think I need to reassess where things are being initialized in Fluency as far as init() vs ready() because I think there is some core behavior that is causing some confusion in a way that makes Fluency look like the culprit. If you're seeing a 302 bookmarks page I don't see how it could have anything to do with Fluency. There's no circumstance where any asset that is being loaded would cause the entire page to 302 because ProcessWire will not 302 the entire page due to a JavaScript file not loading correctly. The 302 page is causing the incorrect Fluency JS URL, not the other way around. Are you a superuser when you see the 302 page? If there are permission issues with users that attempt to view a page they don't have permissions for it can cause a redirect to the bookmarks page. It could also indicate something having to do with the login session. Have you tried logging out and logging back in? Again, this is something that ProcessWire controls.

@Mikel I can't remember the exact message that I was shown but after editing a post too quickly or too many times consecutively I was blocked from making changes or posting anything IIRC. I don't know how related that may be to your case but if you posted/edited things quickly it might be flagging the post as a security method to prevent malicious behavior. Best guess. May or may not be relevant. 🤷‍♂️

@ryan Fantastic work. I was just doing some heavy development around FormBuilder earlier this year and this is all awesome stuff. Thanks!

@Mike-it I'm going to have to guess that this is a server issue that is unique to your environment. There's nothing that Fluency could do to change how the server delivers the JS file. The second error mentions the header which means that the way that your server is delivering the file to the browser is causing a problem because the browser is expecting a "text/html" document and the MIME type for a JavaScript file should be "text/javascript". Here's a stackoverflow thread discussing this same issue for JS. This is difficult for me to help diagnose since this is a one off issue that seems to be related to the server you're using rather than an issue with the module. If it's not happening in your development environment but it is happening in production then that also points to a server configuration issue.

This is dedication to the PW craft 😎

@poljpocket "It's not in the app so it shouldn't be in the app" isn't really a good argument against anything in software. Because it's a feature that would be beneficial to module developers and future utility. I think that's the point here- is the case being made for utility. I can see situations where this would be useful in the future and I don't have a reliable way to create dependencies that would make building on top of this functionality easy for me or users. Let's call my argument entirely separate from @bernhard as a developer who would love to see this supported without a complex module requirement process that doesn't exist and would require a lot more work to implement. If/when the time comes that something would benefit from adding hooks to the module, then it would be a good time to do it. There is no need to go and edit all of the JS for each module just to make it immediately available. It is perfectly fine to say that "many existing modules do not yet support JS hooks, but they may in the future". But the InputfieldDatetime.js example is probably a good example of where one may be easier to convert, at some point down the line (if it ever needed it), since it is a relatively simple JS file with few methods and not many lines of code at all. An alternative way of looking at this is that should the next version of a Datetime picker be chosen to replace this one in the core, for any number of reasons, then that would be a good time to write it for the first time. If a third party module for an alternate Datetime picker was to be written, it could make use of JS hooks if it's useful or valuable. All that aside, here's something that may resonate with the wider PW developer community. The server side API for ProcessWire is wildly powerful and flexible, however the client side is an area that has a lot of opportunities for growth. It doesn't have the dynamic nature of more modern front-ends. ProcessWire is built on jQuery and one of the things that @bernhard mentions were events. jQuery event listeners do respond to vanilla JS dispatched events and vanilla JS events can't be heard by jQuery. This can create interoperability issues for modules that primarily use vanilla JS and modules/core that strictly use jQuery. This bit me in the last couple of months. Hooks are an opportunity to bridge that gap, in the future. I need to stress this point- nobody expects the entire core to support this immediately or asking for it to. ProcessWire does not use event-driven architecture, it uses hooks to provide similar functionality. JS hooks are an opportunity to provide some sort of parity and additional powers on the front end that could translate somewhat into "if you know server-side ProcessWire hooks, you'll be comfortable using client-side hooks". One of the things that is really difficult for me to work around is not having a more dynamic UI in the admin. Having core and third party modules JS call hooks on specific events would make this much, much easier without having to write a lot of code or build an entirely new select input module. This is the first step towards an overarching client side admin API, which doesn't currently exist. Here's my hot take- jQuery is popular and easy to use but it will become a legacy library and in many ways it already is. I haven't used jQuery in projects in many, many years and the most recent lines I had to write were adding duplicate events fired in jQuery that I was already dispatching in vanilla JS in a module to make the rest of the UI see changes to fields. There are a lot of devs who really don't want to write jQuery. In 2025 it isn't necessary for jQuery to exist other than existing dependency or personal syntactical preference. There are going to be an increasing amount of people who want to use ProcessWire that have never written one line of jQuery. Does anyone expect the core to fully support hooks in all modules now? Tomorrow? Next week? Not at all. But having a framework in place that allows the core to continue using jQuery without overhauling it to bring a lot of extended functionality is really valuable. Nobody is asking that ProcessWire be rewritten in Alpine or htmx or something, hooks are a consideration for introducing more powerful features in the style of ProcessWire as part of a roadmap. Here are my questions @poljpocket: What is the best way to introduce new client side powers without completely overhauling the core JavaScript? Why is introducing powerful utilities that developers can use as part of ProcessWire being a framework, with parity in approach between server/client apis, that it may not prioritize using itself bad? If hooks can be introduced incrementally as needed, "as convenient", or by contributions and PRs- is that really completely overhauling the core JS? It seems like you are shooting down the simple examples, which are simple to show how easy using them can be, but haven't made the case for a true net negative other than saying "it will require work". This isn't how frameworks work, but it also doesn't preclude the value of having it available for use by the core in the future.

Quick shoutout and thanks to @bernhard for both RockCalendar and RockJavaScriptHooks. Modifying the module UI to fit client preferences was one line in some JS added to the admin. It really opens up a lot of opportunities for making module JS as flexible and powerful as ProcessWire. Nice work 🙌 I came to post this randomly and didn't know about the ongoing conversation. Might have been good timing. @ErikMH Here is an example on site I'm working on. By default, RockCalendar times are 24hr, this hooks into the JavaScript method that creates the timepicker and changes it to 12hr time. JS hooks are supported in RockCalendar. // Set calendar time input to 12 hour ProcessWire.addHookAfter('RockCalendarPicker::settings', e => e.return.timePicker24Hour = false); Without this ability my alternative is to modify the module where it would break later or request a feature. "Can you add a config option for 12hr time" is a feature request I didn't have to write and @bernhard didn't have to read/implement and his module has even more utility right off the shelf. In cases where you're working on an open source/free module that can be a really big deal as well. Just to contribute a little more to the greater conversation- there is a lot of value in this. I would go as far to say "it will become clear how useful it is when you really need it." Hypotheticals for hooks are difficult. Most of the hooks in PW core are just "neat" until the time comes when they solve an issue or let you do something really cool. This would be more true if there were true dependency support in the core the way that it exists in Composer. Until then the requirement of dependencies is difficult to put on the user unless they come from the same author or are somehow packaged together in a way that handles that more easily. This is especially true since there is segmentation by module type (Inputfield, Fieldtype, Process, Markup, etc) and manually installing these one b one becomes exponentially tedious. If dependency installation existed then there could be fewer feature requests for Ryan or core contributors and that development can remain focused on the "framework" part of ProcessWire rather than individual unrelated feature requests. Perhaps this would be a good feature request for the core. In this case, JS hooks are a natural application of a fundamental feature on the client side implemented in a syntactically consistent way which encourages adoption and potential utility in the same. That would be my argument for core over module. Core support for the ability to hook into JS scripts can be established beforehand so that modules can take advantage of it and the core can implement gradually. It is an enhancement, not a breaking change, and doesn't modify the core API. A rollout where updates are prioritized by the greatest utility when feasible is an acceptable path forward IMHO. If hooks were part of the core I would write them into modules I build. The value of doing that is future creativity and problem solving by developers who use them.

@DV-JF It's already merged with main but will be noted in the next release with credit for your contribution. Thanks again!

@DV-JF I swear I thought I fixed that in a previous version... Thanks for the PR. I'm tidying up some updates and will include in the next forthcoming release.

@Tiberium I have another way to attack this so I'll put together another commit on that branch and let you know. Unfortunately adding an ability to manually assign languages like the TranslatePage module would be a heavier lift than you might think since there are more features that Fluency uses. It would require rewriting the module config page for DeepL. The true solution is to make sure that the module performs correctly for everyone and preserve the UI that people are familiar with. It wouldn't be a good move to require some people who are having difficulty with API calls to forego features that are available to others who aren't. So I want to get this right for everyone 👍 Hold tight, I'll come back with another test. Please expect that via private message so we can more easily converse without adding too many more posts to this thread. When the issue is solved I'll come back and post a new release.

@Tiberium This seems like a new issue that has happened to you and one other person over the past couple of weeks. There haven't been any changes to how Fluency interacts with the API for years. The API use to rate limit translations but now it looks like it rate limits all endpoints(?) What is odd is that only you and one other person have experienced this, or at least reported it here on the thread. I had to repeatedly hit the API endpoint 3-5 times to replicate the issue. I've updated the code to account for this but it is difficult for me to check since I have to create artificial conditions to replicate the problem. Can you test the code from this branch? Many thanks!

New dev version of Fluency with fixes to address RockPageBuilder compatibility issues. Translating content within blocks should now save correctly. @bernhard @snck @Tiberium If you are able to test it would be a big help so I can merge this into a new release. I've tested this on text, textarea, TinyMCE (normal/inline), CKEditor (normal/inline), as well as image description fields. This should cover all multi-language fields. Download the .zip from dev and replace the entire folder (not copy/merge) in your modules directory. https://github.com/SkyLundy/Fluency/tree/development

Here is what I'm currently doing: <?php class MyBlock extends Block { // ...rest of block /** * Determines if this block should render on the page * @return bool */ public function shouldRender(): bool { // For a field that displays featured activities. This is actually much more complex in real life // and keeping this in a shouldRender() method makes the template much cleaner return $this->featured_activities->where('date>=now&is_sold_out=false')->count(); // Sometimes blocks are saved in an incomplete state // Because ProcessWire doesn't have live field dependencies, an event has to be selected, page saved, // then activies in that event can be selected. This block shouldn't render until all of the information is complete. return !!$this->title && !!$this->event?->id && $this->featured_activities->count(); } // ...rest of block } View file: <?php namespace ProcessWire; /** @var Page $page */ /** @var MyBlock $block */ // This could be eliminated by making shouldRender() a method in Block.php if (!$block->shouldRender()) { return; } ?> <section class="rpb-myblock <?=$block->classes()?>" <?=alfred($block)?>> <!-- Block markup --> </section> If shouldRender() is defined in Block.php then it would be available everywhere. Otherwise to maintain consistency I have to do this in every block: <?php class AnotherBlock extends Block { // ...rest of block /** * This could be eliminated by making shouldRender() a method in Block.php */ public function shouldRender(): bool { return true; } // ...rest of block }

@bernhard Forgot to mention that the first block of code is added to Block.php and is a method provided just for child blocks to override if they need. This way RPB will not render a block if that method returns false independently of the Inputfield UI for hide/unpublished state, which I think is what your for loop checks for. If I'm misunderstanding your for loop example then that could be my problem. A block can be published and unhidden, but the block can determine if it will render with its own logic.

@bernhard My approach was very basic. <?php /** * Whether this block should be rendered. May be optionally implemented by blocks to control front-end visibility * @return bool */ public function shouldRender() { return true; } /** * Render this block * @return string */ public function renderBlock() { if (!$this->shouldRender()) { return ''; } // rest of method... } It works in practice as a function that does not modify RPB's existing behavior and the Inputfield UI takes precedence. Since this visibility is controlled by the blocks and not the user, the developer can work with this state. These may serve some edge cases, but it illustrates the philosophy of separating what is declared in the UI vs. in the block. <?php namespace ProcessWire; /** @var Page $page */ /** @var FeaturedActivities $block */ ?> <section class="rpb-foo <?=$block->classes()?>" <?=alfred($block)?>> <!-- You can create "grouped" behavior --> <?php if ($block->nextBlock()->type === 'Bar' && $block->nextBlock()->shouldRender()): ?> <p>Here's a little something extra</p> <?php endif ?> <!-- ...rest of block code --> <!-- Conditional design still possible --> <?php if ($block->isLastBlock() || !$block->nextBlock()->shouldRender()): ?> <span class="rounded-bottom-corners"></span> <?php endif ?> </section> The un-rendered will exist with an ID because the UI and RPB's core behavior dictates that the block exists and is available, but blocks maintain control of rendering separately.

One of the things that I have to work around in a current site is lots of dynamic content. Content in blocks may change depending on values from other pages, dates/times, or updates from external sources such as APIs. Many of these are automated via hooks. My example is events and activities. Events can become active, tickets go on sale, be cancelled, end, etc. This is a block for "Featured Activities" Activities are selected by a person editing a page. They can choose as many activities as desired but only 3 are shown on the page If the date of an activity passes, or tickets are sold out, it is removed from the featured activities (automatically via hook) When one is removed another is rotated in (automatically via hook) If there are no more featured activities (all of the dates have past, or tickets are sold out) the block should no longer be output to the page. These are featured on many pages across the site with a lot of automation and updating them manually would be a very terrible thing 🤣 I have a handful of blocks that do stuff like this. The idea is a shouldRender() method for Block classes. By default it returns true but may be overridden to control whether a block will show up on the page. <?php /** * Whether this block should be rendered. Called before a block is output to the page. * @return bool */ public function shouldRender() { return true; } I have something like this cobbled together already in my code but I have to add an if statement to all of the block views that need this. I also use it for things like image galleries that shouldn't render if the image field is empty. It would be really nice native feature 😎

@bernhard Awesome as always 😎 I don't know if you have a use case for trying the filesystem cache, but I recommend it. As it's a drop-in replacement it's a default for my projects. Sometimes just knowing it's the caching method is nice (I sleep better at night?) haha If you see any issues that pop up during testing it would be great if you could share them ahead of the release. Maybe there's a fix, maybe I need to reconsider it in project.

@bernhard I made the following change to the code and it appears to work correctly. <?php public function __construct() { parent::__construct(); $this->path = $this->wire->config->paths($this); $this->wire->classLoader->addNamespace("RockMigrations", __DIR__ . "/classes"); $this->lastRunLogfile = wire()->config->paths->logs . 'rockmigrations-lastrun.txt'; // load all constant-traits in /site/modules/*/ $file = wire()->config->paths->site . "RockMigrationsConstants.php"; if (is_file($file)) require_once $file; $dir = wire()->config->paths->siteModules; foreach (glob($dir . '*/RockMigrationsConstants.php') as $file) { require_once $file; } $this->watchlist = $this->wire(new WireArray()); // $this->lastrun = (int)$this->wire->cache->get(self::cachename); <- Move this from here } public function init() { $this->lastrun = (int)$this->wire->cache->get(self::cachename); // <- To here $this->wire->classLoader->addNamespace("RockMigrations", __DIR__ . "/classes"); $this->wire->classLoader->addNamespace("ProcessWire", wire()->config->paths->assets . 'RockMigrations'); $config = $this->wire->config; $this->wire('rockmigrations', $this); if (!wire()->modules->isInstalled('MagicPages')) $this->installModule('MagicPages'); if ($config->debug) $this->setOutputLevel(self::outputLevelVerbose); // ...etc I'm not sure if there is a need to have the last run timestamp checked in __construct() that you know of and I am not familiar with but this change seems to work for migrations and resolves the issue.

New thread from this original comment in the main RM thread. So I have WireCache Filesystem installed and it's a critical part of the back end of the ProcessWire application. This is a drop-in replacement by Ryan for the core database cache system. @bernhard from your original response: So the benefits of a filesystem cache are that it's lightning fast. It's really preferable in a lot of situations to database caches which require DB queries. It would be difficult to quantify in hard numbers but the simple fact is that filesystem reads are much faster that MySQL queries. This is negligible on local environments but in production is has a significant impact. The compatibility issue is that RM is getting the lastrun value in the __construct() before the filesystem cache has a chance to boot. Is it possible to move that to init or ready?

That would be a great feature, however I will make a case for an implementation for your module. Since the module adds the lqip property and lqip() method to the image field object it would be important to selectively disable some features of the module and not others. It's important that they're always available so that there aren't any errors or unexpected behaviors. A full module disable might cause some of those. I'll send over the PR 👍