FireWire

Yes. I've worked for agencies and with them. I've approached an agency who was full WordPress and in conversation explained the features and benefits of PW. The conversation went well but they declined to work with me. When I talked about stability and long term security, they simply said that the problems and bad parts of WordPress were part of their business model. They were quite satisfied selling a substandard product that they can count on breaking simply because they can charge their customers to fix it. There are a lot of reasons behind the decisions at agencies. I'm not discounting your thoughts on the website, many good points, and I know that you're not alone in those sentiments. I think that it's really good that devs who regularly use PW and care about it share those thoughts. It's something that makes this community unique 👍 I doubt there's not going to be a redesign. Maybe some Iterative feedback would be constructive if Ryan and the designers are open to it. It's easier to help incrementally improve support of the work that needs to be done. Not everyone will be satisfied 🤷‍♂️ An open and honest conversation in good faith is something to be encouraged. I personally always think content first. Maybe a conversation about what is said, how it's said, and how impactful it is as stated on the site can help. I can't find it for the life of me but I know that Ryan put a out a question of "what should be on the website?" in a post. There were a lot of great suggestions, and that's a lot of work. Maybe there can be some community contributions. Design follows content- so if there's something to say, it can help be the basis or blueprint for suggestions and improvements to the design. Want a section with stats? Perhaps share some research and stats you believe should be showcased and the text that supports it. Boxes with numbers in a wireframe don't justify the change, content does. All that said, my perspective is one that I think is worth considering: Operate on the assumption that a design change won't be a solution to client challenges. That's pretty much it. Whether it's true or not is irrelevant. I'll mention why in my last bit below. I would go so far as to say this applies to any equation, e.g. "I'm having client challenges with x because of y". Here are some specifics of my approach. Is it really because of the website? The website isn't that old. Is this a temporary dip in business? Has someone communicated, either directly or indirectly, that the website may have affected their decision? Unless you can confidently point to an example then it's just vibes and speculation. This is a question is less about an answer and more for considering all angles. Refresh the approach. Are there ways to reduce the impact of force "X" that may cause conflict? Is there something that can be discussed ahead of time, or after a conversation has already taken place? For the sake of example, let's use the website as the challenge. Here's how I would approach it in a follow up conversation where ProcessWire had already been discussed, there is some hesitancy, and my concern is that the website didn't help convince them in my favor. "So we had discussed using ProcessWire as the CMS for this project. I don't know if you've looked into it or visited the website, personally, I think it's a little more tailored for developers and programmers. There are a few other things I wanted to go over and cover any thoughts or questions you had since the last time we met" (or spoke, whatever) Strategy: I brought up the CMS, not always possible, but if I'm convinced that the CMS is holding things back then it's time to engage. Regardless of who brings it up, I take the forward position rather than defend. I stated outright a shortcoming that I think X has If I suspect X then I bring up X if/when possible. This does one of two things: confirms that it wasn't the culprit, or deflects an opinion they may/may not have based on something I perceived is a negative. Opened it up for them to share their thoughts after removing barriers I know this isn't applicable to everyone, or can be implemented exactly- but the concepts are not limited to this example. I also know that we are an international community where social norms, customs, and language may need an approach more appropriate for you. Reframing the conversation with an honest and confident approach is always a good way to connect. I like to own the perceived weaknesses in a conversation. Build an example website. Here's the one that I think may have the biggest effect. ProcessWire doesn't have an example site where you can log in and explore. We are web designers and developers! If you don't like a website, build another one 😎 If the ProcessWire website isn't having the impact you need, it's possible to help take control of that variable. Again, we're assuming that a design change to the ProcessWire website won't be a solution to client challenges. If you have a concept that you believe will speak to the features and strengths that matter to your clients the most, then there's no better way to speak to them than this. You know your clients and the potential clients you are working to gain better than anyone. Full stop. If I remember correctly, @bernhard had/has an example PW site that you could log into, make changes, save, delete, whatever, and every X amount of time or PW event all the changes are reverted. If that's true perhaps he can share that and some tips based on his extensive knowledge and experience; Challenge: Build as a community An example site with real world features, a great design, and a focus on usability is a great tool to showcase software. Many CMS sites have them. Regardless if you love the new PW site or not, there is no argument that an example site would be far more effective at illustrating the power and capabilities of PW as it relates to clients, either end users or agencies. This would be an opportunity for the community to build something that pushes things forward. I don't want to speak for Ryan, but perhaps this contribution would get a link on the site. If fit gets official support, perhaps a subdomain. I don't want to say "if you think it's that easy then try doing it yourself", but this would indeed bring in the challenges of group collaboration, planning, and delegation. That said, it's a blank slate without constraints. Take the collaborative effort that would be directed at improving the ProcessWire website, or the work that would be required to redesign it, and use it to make an experience that stands on its own. Ryan and the designers of the new site are working on the core and continuing to refine the new admin. I think expectations have to be realistic here. The priority is the functionality and quality of the ProcessWire experience. I wouldn't assume there's time to stop work on those and work on the PW site. There's nothing stopping the community from taking on this challenge and work together or working on our individual strategies. I think your original post @MrSnoozles is one that contains the topic of two threads. Website design feedback, and navigating client challenges possibly due to the website redesign. I focused on the latter because it's widely applicable and something that you, me, and everyone else can work on changing now. While that's happening, in the meantime contributing to a design conversation about the website if valuable but is at the very least a medium to long range timeline.

Free version of Microsoft FrontPage Express on Windows 98 made me think I didn't have to learn any more fancy HTML until I found out that was all a lie 🤣

I don't want to be too blunt and I can't speak for anyone else, but I've never referred a client to a software or service website as part of the education process. It doesn't do anything for them. You are the expert. The person making the pitch should be able to fully explain the technology stack to the extent that the conversation requires it in language they can understand because we are the interpreters. Clients trust me because I am the expert and the top 3 things they care about are these, in this order: How much is this going to cost me? Why don't we use xxx? (or, our current site is xxx I'm not sure we want to switch) When is it going to be done? Sending a client to any site for tools or software is like saying "here, do your own research". The ProcessWire site, like any other development tools/software sites, isn't there to woo clients. Most clients don't care enough to take time and truly understand it because that's not their job. If a curious client is in a position to go to websites like ProcessWire, several steps have been skipped in the client discovery/planning process IMHO. I'd even go so far as to say that if a site has "Docs" or "Documentation" in the primary nav, it's not for clients and they shouldn't be there. I hope this isn't a too hot a take... I would say that improvements could be made iteratively with more use of color for contrast, emphasis, and indicating priority. I think it's a flexible design that can evolve in whatever capacity that may be needed. This has the ability to highlight some impressive facts and figures. No notes on the content, some elements could be integrated into the current design. Even then, facts and figures are for devs. I used the word "scalability" with a manager once and they stopped the conversation to ask "wait, what does that mean?" and still didn't care when I explained. A a CMS or framework site is never going to lead to clients translating what's on the page to time or money. In all likelihood, the conversation you are having with a client at 10:00 just followed a call with their product distributor at 8:00am, their accountant at 9:00, and at 11:00 they're meeting with other members in management. Personally, I would no sooner send someone to processwire.com than I would laravel.com. You are the time and money. I agree with this. I will go out on a limb and say the number of end customers who went to the Drupal site and left thinking they need a Drupal site isn't zero, but it's probably close. If someone is hiring a Drupal developer then they're in a role where it's part of their job to understand the tech stack even if they aren't a dev. Visiting wordpress.com, it doesn't target the end user but name recognition still draws business which overcomes the website entirely. This is fair. It doesn't take a monitor that computer professionals use to get this experience. All you need is a consumer iMac. I think iteration can address concerns. I don't want to belabor the point, but to be fair, did you ever send a client to the QuarkXpress website... Just a little joke ☺️ Cheers from a fellow old school developer who built their first website in 1997 and tinkered with QuarkXpress 🍻

@Spinbox I'm not sure why that wouldn't be working if the fields are initialized with a translate button. I've never nested RPB fields. I'd like to support whatever features RPB has. I've reached out to @bernhard to see if there's anything that he may know of to help or confirm that nesting is supported. Will come back with more info when I can.

Perhaps give $user->isSuperuser() a shot instead. It's documented as faster and is my go-to since it's a dedicated method.

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.