Leaderboard

I'm thrilled to announce the official release of RockPageBuilder, the game-changing tool that's set to transform your web development journey (at least ChatGPT says so ??)! With its brand new drag-and-drop interface RockPageBuilder is your secret weapon for creating outstanding ProcessWire-based websites. Get a taste of the future of web development by visiting the demo page at https://pagebuilder.baumrock.com/ and exploring the RockPageBuilder documentation at https://www.baumrock.com/en/processwire/modules/rockpagebuilder/docs/ Don't miss out on this exciting opportunity to elevate your web development game. Get ready to rock with RockPageBuilder! ??️ Early Bird Sales until 30.11. https://www.baumrock.com/processwire/module/rockpagebuilder/ Here is a quick demo video: And here is how to install it from scratch in under 5 minutes: Some showcase projects are already in the pipeline ? So be sure to subscribe to https://processwire.rocks/ or to https://www.baumrock.com/rock-monthly/ Have a great weekend!

This week I've been working on various ProcessWire related projects, but haven't pushed much to the core. There was a core feature I've been working on which I decided to instead put in a module. It's one of those things that should be be really beneficial for some people, but not necessarily needed by everyone, so it makes more sense as a module. This particular module expands upon the page-lock option and permission in ProcessWire. The page-lock option (which you'll see as the "Lock" status in the Settings tab of the page editor) provides the ability to lock a page for edits. This can be really useful if you want to prevent a particular page from being modified for whatever reason. For instance, maybe you are doing a $pages->get('/some/page/'); on the API side and if the path /some/page/ got changed, it would break something in the site. So to prevent clients from breaking the site, you lock the page to prevent them from screwing it up and breaking something on the site. This is quite useful, and often a life saver. But I don't use it as much as I'd like because of one downside. That downside is that it locks the entire page so that nothing on it can be edited. So it's just too heavy of a lock. What if you just wanted to lock the page so that the name, title and parent couldn't be edited, but everything else could be? That's what this new module enables. To lock a field in the page editor, you click its header and hold until a dialog pops up asking if you want to lock it. To unlock, you do the same thing. Once a field is locked, it remains locked (non-editable) until unlocked. Only users with page-lock permission on the page can lock or unlock fields. Locks can also be managed with checkboxes in the page editor Settings tab as well, just in case that is more convenient in some contexts. While these are editor locks rather than API locks, the locks do affect contexts outside the page editor too, such as actions in the page list. For instance, if you locked "parent" then you wouldn't be able to bypass it dragging a page in the Page List. I finished developing the module today, but I've not yet written documentation for it or uploaded to GitHub, etc., so I'm going to give it another day of work and testing before releasing it next week, and will cover more details in next week's post. Thanks and have a great weekend!

The first version of FrontendLoginRegister was released a long time ago, and the module in its latest version (2.1.8) is now available in the Processwire modules directory. After a long development period, I have decided to add this module to the modules' directory. This will make it much easier to update the module in the future, and I hope that a larger community will test the module and report problems. The module has BETA status. I have tested it and have not found any problems, so it should work as expected (but I probably cannot test all possible scenarios). Therefore, I would be happy if many people would test the module and help me to reach the stable status after a while. Best regards

This is an oversight on my part- if the field is empty, it shouldn't translate. Problem solved. The following two issues are solved by a translate to all button on non-default languages, and the translation button type is still an option on the module config page ? The real point for a "translate to all" button is to make it easier for the end user and to prevent content deviation, where one language says one thing and another language says another. It's very easy for an end user to forget to translate content- so there is no translated content, or the translated content becomes out-of-date. I've seen both of these issues in sites I've built that had people doing SEO work, or just managing content in general. The "Translate to all languages" and the content change indicators are the best way that I can think of to help people enter content, click translate, and complete their work with the highest amount of accuracy. In my experience non-web people aren't as engrossed in the process of maintaining websites as much as developers are, so unless you make it as simple as possible it increases the likelihood that the website will be poorly maintained. Also just realized that the new "Translate to all languages" button doesn't work when translating the page's URLs. Will push a fix for that.

Congratulations! I think this will definitely fill a niche for certain site builders. I entirely agree with your reasoning for building it. I myself have rotated folks back to more of a Pagelines page creation philosophy. They made some pretty weird business choices that hopefully we all can avoid. When I was still building more WP sites folks did appreciate Pagelines block a LOT - way less frustrating that having to twist a bunch of knobs and dials on every page and pray things looked the same across the site.

Thx. I have not built a single site without it over the last 3 years ? Sure! It stores pages under a hidden page in the pagetree that you can show for superusers: I have not tried to be honest, but I don't see a reason why it should not? Could you give me some context to think about it? What would you want to do? Well - it depends. Technically you can place those files wherever you want. The module has an API to load those blocks, eg $pagebuilder->loadBlocks('/path/to/dir'); The easiest way to use it is to stick with the defaults, because then everything happens automatically and you don't need to understand the module's inner workings. The files itself are necessary for it to work, of course - BUT: That does not mean that those files have to be writable by the system on production. You could for example just create those blocks on your dev environment and then just push those files to git and deploy. That's what I'm doing all the time. You could even disable all migrations if you want. But then you'd have to push your db changes to production manually or create the templates and fields manually, which would be tedious of course. Technically all blocks are just custom page classes: Demoblock extends Block extends Page Does that answer your questions? Thx! That's fixed ?

HI @bernhard, this is an awesome addition to the ProcessWire eco system ! Great job ? I've noticed a little hiccup on this page : https://www.baumrock.com/en/processwire/modules/rockpagebuilder/ in the FAQ section. Clicking on the second question opens the response of the first one.

This is really impressive. A very nicely done piece of art work. Great job, @bernhard. Gideon

This is phenomenal bernhard. Took a quick peek at the demo which looks outstanding. If I wanted to use with the Bootstrap framework will the front-end editing still work, a little unclear on how that is implemented.

TL:DR I've updated a PW page we've built 9 years ago for the first time and it's still a solid experience. Backstory Back in May I was on a crowded train somewhere in the middle of Germany. Now working as a "Consultant" who builds slidedecks instead of websites, I happily noticed the men next to me talking about responsive webdesign with his friend. During the obligatory "This train is late" announcement we started to chat. My seatmate, a geography teacher, recently attended a web workshop at a large Hamburg agency. He told me he now understands the value of a CMS for updating their site and he wonders how to build a responsive layout. They don't get paid for this and work on their homepage in their spare time. And they have a Typo3 installation ? Back in 2013, together with my friend Marvin, we've rebuild our school website with ProcessWire optimized for mobile devices. Launched in 2014 this was quite an impressive feat including online time tables, a working event calendar (with import feature) and many small nice touches. After my encounter on the train, I checked the page and yes, It's still online and updated daily! The next day I wrote my old teacher a short email if we should have a closer look into the underlying tech and within minutes I got a super happy reply that he is so glad that somebody would help (again). So let's dive into what we've done. Situation First some details about this ProcessWire installation that is updated by a few teacher on a regular basis. Over the 9 years they've wrote nearly 900 news articles and kept more than 250 pages up to date. The asset folder is over 11GB. Build with Processwire 2.4 (?) and lots of janky code we've updated the page once to 3.0.15 somewhere in 2016 quick and dirty. They even used the old admin layout. ProCache, CroppableImages3 and a few other plugins were used. Every single one of them required an update It's used the classical append-template approach with a single big "function.php" included file. It's running on PHP 5.6 and for whatever reason no PHP update was enforced by the hoster (But the admin panel screamed at me) A privacy nightmare: Google fonts embedded directly, no cookie banner and a no longer working Google Analytics tag included The old ProcessDatabaseModule made a database backup every week as planned over all these years. Nice. No hacks, no attacks and all teachers are using their own account with assigned permissions Changelog I've updated the page with a focus on making it stable and reliable for the next 9 years. After making a development copy of the page, I've started working on the following changes: Updated ProcessWire and all modules to the latest stable version. After reloading a few times, no errors encountered Updated the whole templates to make it work with PHP 8.2 Removed all externally hosted scripts, disabled cookies for all regular visitors and introduced a 2-click-solution for external content Reworked a few frontend style issues around the responsive layout, made slight visual changes for 2023 (e.g. no double black and white 1px borders) Ported the image gallery feature to more templates (Big wish of the people updating the site, they've used a workaround) Cleaned up folder and structures, removed a few smaller plugins and admin helpers no longer needed All this was done back in May and - with a big break - completed now in October. It took a few days and most of the time was spent figuring out our old code. Learnings ProcessWire is robust as f*ck. I just clicked "Update" and it mostly worked instantly I nearly removed features for the PHP update. A custom written importer for the proprietary XML schedule was hard to debug and understand (5-dimensional-arrays...). Gladly I've tossed a coin and just gave ChatGPT the php function source and error message and within a single iteration it updated the code for PHP8. The "responsive" CSS framework aged badly. The used 960gs skeleton uses fixed widths for the responsive layout. I couldn't get it be wider than 320px on mobile screens. So the site is responsive but with a slim profile for now. Replacing it would be a complete layout rewrite Result and looking forward The Werkgymnasium site is now updated and live again. It still loads superfast and looks great after all these years. We have a few more features planned to help our editors input new content but overall it just works. Looking forward a few issues remain. ProCache would require the paid update but it still works fine. The layout needs improvement on mobile screens. There is still an error with the pagination. We'll cleanup the code more and then make the whole template public on Github so that maybe a few students after us can continue with the updates. Maybe even rebuild the frontend one day. I hope I can give you an update in a few years again. As a closing note: I'm still grateful for the amazing community here and all the features ProcessWire has to offer. My daily work no longer resolves around websites but PW has a permanent spot in my heart. Thanks Ryan and all the contributors.