FireWire

@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 😎