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.