FireWire

Thank you for sharing your invaluable work and contributions @bernhard! You had a lot of options with how to move forward and I believe that open sourcing your modules ensures that your work carries on into the future and continues to benefit both ProcessWire developers and users alike. I do want to share some thoughts and contribute to what @bernhard said about "feature complete". Most of the modules you have built are indeed robust and offer a large number of features that are implemented well and will continue to bring value long into the future. Modules like RockPageBuilder offer a solid set of features and are built in a very extensible and customizable way that puts a lot of power in the hands of developers. If any are reading this and are just finding out about it or have not yet had a reason to use it yet, I highly recommend taking a look! Other modules like RockMigrations have become staples in my workflow and will continue to be. Whether new features are added or not, the utility and quality of these contributions stand on their own. I also want to share some thoughts with the greater community. ProcessWire is a powerful tool that is developer-focused and easy to use for beginners while being powerful enough for advanced applications and more senior developers. It's one of the reasons we all love working with this platform. It also means that this community is comprised of people of many levels of skill and creative abilities. These are the factors that make open source software work. Whether you're working with the core or a module from any developer that is open source, your contributions matter and they are a way to "pay it forward" and give back to the community that makes your work possible. The vast majority of modules are free to download and use, and that "free" to you comes at a cost to module and core developers in both programming and support time. These are hours spent beyond our professional life. Nights and weekends, and breaks from our jobs to respond when something is urgent. Keep the developers in mind and remember that burnout is a real thing in the open source community. Greater involvement and contribution helps that greatly and also helps the developers you rely on for quality code you use stay engaged and make offering their work to the community enjoyable. Many hands make for light work. If you're using a module and run across an item that can be improved, a bug that hasn't been reported yet, or have an idea for a new feature then please consider forking, contributing, and pushing upstream via PRs on Github. If you are able to see something, take a moment to try and find a solution- I guarantee it will always be greatly appreciated and your efforts will not go unnoticed. You'll find some of mine coming to @bernhard modules in coming weeks. If you haven't contributed to open source before or find the process intimidating, please consider a module contribution for your first time out. The thoughtfulness and helpful attitudes here in the forums continue on module Github repositories. Those repository owners and module maintainers are the same people who are members of one of the greatest developer communities around. Never forked a repository or opened a PR before? Anyone with experience here is ready to help. You'll level up your skills, increase your confidence, and the satisfaction you'll feel cannot be overstated. These can be as simple as small changes to make a code base compatible with a new version of PHP, or a little tweak to some JS! I wanted to take a moment to mention this here because the release of these modules, much like those that were open-sourced by @kongondo and others, have a future through contribution. I don't mean to hijack your thread @bernhard but I think what you have shared offers a great opportunity to communicate these ideas in appreciation and encouragement to others. Thank you again @bernhard for the wealth of knowledge you openly share here and the guidance that you have offered to others. It is inspiring and, on a personal note, has immeasurably advanced my knowledge and confidence as a ProcessWire developer. @Jim Bailie The concept of a paid platform for modules has been discussed by many both in public and private. I don't know that there's a single answer to that question. Hopefully that may come about one day, it would mean a lot to the sustainability of ProcessWire. When it comes to taking a shop from concept to reality from a community standpoint it always comes down to "if not me, then who?". Should Ryan take time from the core to build it? Maybe it would be better for a team to collaborate and offer help to create an official channel. I think what I mentioned above underscores the importance of not relying on one person to solve the problem. I'm sure Craft had a team of people working together to make their shop come to life and also requires work to keep it going. If one person did all of it for Craft I would be truly shocked. Hey- RockCommerce is open source... maybe it's a starting point 😎

@bernhard thanks for the fix!

@lpa Apologies for the late reply, I got sick and was off my feet (and keyboard) for a little while there. Are you still having this issue? If so, are you seeing any errors in the browser developer tools console? Did you make any change to your languages? Can you clear the translation cache and see if that changes anything? I can't reproduce this, I'm using Fluency 2.3.0 in production and having no issues. That query parameter error is impossible with 2.2.0+ <?php // Line 217 in DeepLEngine.php $requestUrl = "{$this->apiUrl}{$endpoint}"; // <- This used to have a query parameter for the API key anything earlier than 2.2.0 will have it // Line 227 "Authorization: DeepL-Auth-Key {$this->apiKey}", // This is the header authentication now required and added in 2.2.0 It's not possible to get an API key parameter error because Fluency will never send a request with an API key parameter. It's possible there's a DeepL issue? No idea. Fluency 2.1.1 should fail. 2.1.1 on local may be working if you have translation cache enabled and it's not actually making API calls to DeepL. Just a guess This is hard to diagnose because the errors don't make sense...

@lpa I didn't deliver a formal release announcement but Fluency 2.3.0 was released. There were some fixes to CKEditor that may possibly be related. I've had 2 reports of issues with CKEditor fields in the last couple of weeks that hadn't been seen before. Not sure what caused it. 2.3.0 is in the modules directory, you can upgrade from within ProcessWire or download the latest version from Github. Let me know if that fixes the issue. I'm going to be away from my computer over the weekend so I won't be able to come back and check until Monday afternoon at the earliest.

@maximus I included that .htaccess file as an extra measure but Apache won't serve .env files. Just don't tinker with some deeply hidden config somewhere to serve dotfiles 😆

@netcarver That is really odd. I couldn't think of how that would have happened and then I remember that I pasted "Thank you" in 11 languages (6+ years ago). Looks like the spam filter doesn't like polite conversation 😆 Thanks for jumping in and fixing!

@ryan Saw nothing on my side except that it was fixed (thanks to Netcarver). I received notification saying "Your post was approved". I'll have to go with your thought on the forum upgrade. Only tidied up some info on that original module post which I don't do very often. I think it happened once a while ago for the same reason, but it was approved quickly so I didn't think anything of it.

Not sure who would be the best person to reach out for help on this but there's a critical update for my module, Fluency, and getting the word out is not possible because the thread is locked and hidden from everyone but me. I edited my original post last week (IIRC), which I've done before, and I didn't know that this hid it, which hasn't happened before. This is a bit odd given how old my forum account is and reputation 🤔 I'm attempting to let all Fluency module users know that there is a critical update that must be installed for all users that are using DeepL as their translation service or all translation services will fail with an error. This is due to a short-notice breaking change by DeepL stating that they're deprecating their previously documented authentication method on January 15th, 2026. If you're reading this and use Fluency, please update your module installs to version 2.2.0 which now available via a ProcessWire admin module upgrade, the modules directory, Github, and Composer. I pushed the update as soon as I could to give ProcessWire devs as much time as possible to update their installs and those of their clients. Thanks to whomever sees and can/does unlock the thread!

Hello all! There's a new version of Fluency and a critical update announcement for all DeepL users. Fluency 2.2.0 has just been released and is a critical update for all users of Fluency that employ DeepL as their translation service. As mentioned above, DeepL is deprecating their previous method of API authentication on January 15, 2025. This means that all Fluency versions less than 2.2.0 that are using DeepL will no longer translate content. Upgrading from Fluency 1.8.0 or earlier requires a complete uninstall/reinstall. The module will have to be configured again, so note your API key if you don't have access to it otherwise. This will not result in any content loss. Fluency 2.2.0 also brings additional features and bugfixes. These include compatibility with AdminThemUikit v3 and its theming customization abilities. Fluency also now uses CSS custom properties so it is possible to customize it separately. This release also includes a fix for an issue that may affect saving content in RockPageBuilder fields mentioned earlier in this thread. For full notes on changes and improvements see the Github release page. If you have any trouble with the module please report them here, filing an issue on Github is helpful as well. Thank you all for your feedback and ongoing support. Additional thanks to the developers who have donated via PayPal, always appreciated!

@imandreas The pages under the 'Admin' branch of the page tree are often created by ProcessWire itself for Process modules. Moving them may make modules in general that use them break. It's not recommended that they be moved because they won't be where ProcessWire or the module itself expect them to be. This is part of how modules are built for ProcessWire and isn't customizable.

Quick announcement. DeepL is enforcing a new authentication method when making API calls that deprecates how previous methods were used. You may have received an email from DeepL notifying you of this change, if your clients have a DeepL account of their own to power the translation on their site they may have received this notification. This is the authentication method that Fluency uses (and was the only option available for a long time). The deprecated authentication method will no longer work on January 15th 2026 onward, which means that the current and and all past versions of Fluency will stop working and an API error will be shown when attempting to translate content. Fluency will be ready. I am working on updating the module to adhere to the new requirements and it will be ready ahead of the January 15th cutoff. This means that the Fluency modules you have installed for yourself and clients will need to be updated. I just received the email notifying me a couple of days ago and this is much shorter notice than usual for a deprecation of a critical API component. Unfortunately we have to work with what we have as far as time. It isn't ideal, but again, Fluency will be ready with weeks to spare and an update will be available as soon as possible. Stay tuned for more information and an update on the module release. Thanks and if you have any questions feel free to respond and tag me!

@Frank Schneider Are you rendering this calendar on the front end or in the admin? First thing I noticed was that the closing </script> tag is missing. You can use the native PHP alternate control structure syntax if this is in a mixed markup/PHP file. It's up to your personal preference but it can help readability. <?php if ($page->path == "/avisierungen/kalender/" || $page->path == "/vermietungen/kalender/"): ?> <script> $(function(){ 'use strict' $('#calendar').fullCalendar({ header: { left: 'prev,next today', center: 'title', right: 'month,agendaWeek,agendaDay,listMonth' }, height: 'auto', contentHeight: 'auto', aspectRatio: 2.0, weekNumbers: true, navLinks: true, eventTextColor: 'black', defaultDate: '<?=date("Y-m-d")?>', editable: false, eventLimit: true, // allow "more" link when too many events events: <?=json_encode($calendar_data)?> }); }); </script> <?php endif ?>

It does but using MarkupCache means that the file doesn't exist on the filesystem so, to my original point, loading /sitemap.xml starts PHP, makes DB calls, and then returns the cached markup via a virtual URL. Yes, it's cached and faster than generating a new sitemap on demand, but not as fast or efficient as writing a file that has a direct URL on the filesystem. Your topic may be better suited for a separate thread about multisite implementations. This thread is for support and discussion of SeoMaestro.

@Jonathan Lahijani Congrats 👏 I heard about Omarchy, curious to hear your thoughts so come back and share more when you've driven it for a few miles. I really like Gnome's super key then type to search feature. It keeps my hands off the mouse and is much faster once you get used to it rather than a task bar or dock. I don't even have icons on my desktop, really is a nice workflow. It's great getting everything set up with shortcuts. I use my mouse so much less since I switched and it really speeds things up not having to touch the mouse.

@hellomoto Sorry if I mislead you, I'm a user of the module, not the author. My response came from breaking down why one is preferable to the other. This isn't entirely accurate. They may not serve as useful of a purpose but size shouldn't be an immediate disqualifier. Sites grow in size and should have a sitemap ready. They also make poorly linked pages discoverable. Sitemaps are best practice. This module is unmaintained. Fork it on Github, experiment with it, and if it works out come back and share the results. Your first hook above is the way I would hypothetically approach the problem. This is definitely an example of a module that needs to be built with multisite capabilities whether it's modifying this one or building one from the ground up. You can fork this and release an updated version to the modules directory as an author if you give the creator of this module credit.

@hellomoto Efficiency. If a file exists on the server then the server immediately returns the file from disk and PHP doesn't load to process the request. File access from disk is much faster, has little to no server overhead, and in the case MarkupSitemapXML, doesn't require a DB call to get the same static markup that could exist in a file.

I second @elabx for using RockMigrations. It contains a lot of powerful utilities that you can use as you see fit. Many can be used separately, they all work well together. Tools like field and template migrations mean that you can often get away without having to perform large DB sync operations. Cheers to @bernhard for a module I use on every project 🍻

@adrian Just want to come back 8 years later and mention that this saved me a lot of time today 🫡

@bernhard I completely forgot about this post and ended up with a solution. I do have a default block and did implement this as you described. Interestingly I did this on my own having missed your reply. So we were thinking in the same direction.. This is ultimately what I came up with and this made it much easier to implement a solution and with less effort. This is a simple example of a block with an image marquee. I only want the block to render if there are images that will show up on the page. <?php // rest of block... /** * Renders this block if conditions are met */ public function renderBlock(): string|Html { if ($this->images->count()) { return ''; } parent::renderBlock(); } // rest of block... I added a renderBlock() method that overrides the parent Block::renderBlock(). It contains all of the logic that determines if a block will render. For a complex block that has multiple fields that need to be checked this can be very helpful. It is also very clean and simple since that method is automatically called when RPB renders blocks anyway. I think this is better than an entirely new method like shouldRender() In my case there are blocks which have an ASM page select. The pages that can be selected may become unpublished or hidden which will remove them from the selected pages. If there are no pages left to render then renderBlock() will return an empty string and prevent it from rendering without any need to go through the site and hide blocks that don't have any pages. This allows for dynamic changes in content and the block always behaves as needed. Thank you for working on a solution and apologies that I missed it!

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.