bernhard

Hey @FireWire great thank you! My project is taking shape and we will start adding content soon, so it's a bit annoying if the translation service breaks our site snippets 🙂 Great to know that you can reproduce and a fix is coming 🙂 All the best for your event!

This might be helpful:

Hey @FireWire thx again for sharing your block thumbnails! I have just made it a lot easier to explore/find/use them and added this field to the module config screen where you can just click on the icon and it will copy the name to the clipboard that you can then just paste into your "thumb" property of the block's info method 😎

Today a client asked if they can have a page where they can upload internal documents that are only visible to logged in users... I thought the easiest solution is to make the page unpublished and make sure nobody can publish it. This is done with a checkbox that is only visible to superusers and when checked, the page always adds the unpublished state on saveready: <?php // in init() of the Site.module.php wire()->addHookAfter('Pages::saveReady', $this, 'lockPage'); // the hook protected function lockPage(HookEvent $event): void { $p = $event->arguments(0); $locked = $p->getFormatted(RockMigrationsConstants::field_lock); if (!$locked) return; $p->addStatus(Page::statusUnpublished); } And another hook to remove the publish button (which is why I found this thread and thought it might make sense to share this solution): <?php // init() of Site.module.php wire()->addHookAfter('ProcessPageEdit::buildForm', $this, 'hidePublishButton'); // the hook protected function hidePublishButton(HookEvent $event): void { $p = $event->process->getPage(); $locked = $p->getFormatted(RockMigrationsConstants::field_lock); if (!$locked) return; $form = $event->return; $button = $form->getChildByName('submit_publish'); $form->remove($button); } This will also remove the copy of the publish button 🙂

Needed this today. This is what I used: <?php // on init of a module wire()->addHookAfter('ProcessPageEdit::buildForm', $this, 'moveStatusFieldAndHideSettings'); // the hook method protected function moveStatusFieldAndHideSettings(HookEvent $event): void { // do not change the UI for superusers if (wire()->user->isSuperuser()) return; /** @var ProcessPageEdit $process */ $process = $event->process; $p = $process->getPage(); // check for page template if (!$p->matches('template=basic-page')) return; // get status field /** @var InputfieldWrapper $form */ $form = $event->return; $statusField = $form->get('status'); // add field to content tab $tab = $form ->find("id=ProcessPageEditContent") ->first(); if (!$tab) return; $tab->add($statusField); // remove settings tab both from form and from UI $tab = $form ->find("id=ProcessPageEditSettings") ->first(); if (!$tab) return; $form->remove($tab); $process->removeTab('ProcessPageEditSettings'); }

Hey @FireWire any news on this? Can you reproduce the bug? Let me know if I can help with anything!

A very quick and easy solution would be to add css like this to your admin.less file: li.Inputfield_tmp2 input { margin-top: 30px; } Before: After: You need to adjust the field names in your css though.

Thx for sharing! In case you don't know or anybody is interested in alternatives: RockDevTools is free and provides asset merge/minify plus live reload:

There we are: https://ddev.readthedocs.io/en/latest/users/quickstart/#processwire-zip-file 💖

I'm not sure, but I don't think it supports redirects for subtrees. But you could easily solve that by adding an url hook to /{year}/{page} That hook will not fire for /2025/... as this page exists, and for all other years you can make it look for the page at /oldyears/$year/$page and redirect to that page if it exists.

Ah, thx! That's what I was missing 🙂 It returns only view links which I don't want either. Thx for the clarification 🙂

Thx @adrian that already helps! I missed that comment! This one is interesting. This is not the case for me! I'm also hooking Page::editable and Page::addable and the live search returns non-editable pages as well...

Hey @adrian I had a look into your modules code to see how you restrict search results in the PW backend. I need this for a multisite module I'm building. I took your hook: wire()->addHookAfter('ProcessPageSearch::executeFor', $this, 'hookSearchResults'); ...but wondered why it did not trigger my callback. First I thought the bd() call in the callback might not be working, but turned out the callback was never triggered. So I added a hook recorder and got a log like this: ProcessWire\FieldtypeModule::formatValue ProcessWire\FieldtypeModule::formatValue ProcessWire\ProcessController::execute ProcessWire\FieldsArray::changed ProcessWire\FieldsArray::changed ProcessWire\FieldsArray::changed --- ProcessWire\ProcessPageSearchLive::execute ProcessWire\ProcessPageSearchLive::getDefaultPageSearchFields --- ProcessWire\FieldtypeModule::formatValue ProcessWire\Pages::find ProcessWire\PageFinder::find ProcessWire\PageFinder::getQuery Which made me aware of "ProcessPageSearchLive". I then changed my hook to hook into ProcessPageSearchLive and boom, everything worked as expected. Now I'm wondering why your module only hooks into ProcessPageSearch. Does that even work? Or am I missing something? Thx!

Oh, I was always using + instead of = and it worked as well. Not sure where I picked that up. Yes, manually entering it saves it. But the issue is that when you translate a string and the returned translation is the same (eg Telefon (DE) --> Telefon (CZ)) then fluency will fill the input with "Telefon" which will then be lost on save and the field will be marked as "blank". I think it would be good if it turned "Telefon" into "=" on save. But I think that the core should take care of this! What do you think? PS: No hurry.

Ever felt like your ProcessWire emails look like they're stuck in 1999? You know the drill - sending emails is super easy with WireMail: $m = new WireMail(); $m->from('foo@bar.com'); $m->to('xxx@yyy.com'); $m->subject('Hello there!'); $m->bodyHTML('<h1>This is great!</h1><p>I am an ugly mail...</p>'); $m->send(); But let's be honest - they look about as pretty as a website built with Microsoft FrontPage! 😅 🪄 Enter the Mail Pimp Hook! Drop this magical hook into your /site/ready.php (or even better Site.module.php), and watch your emails transform from ugly ducklings into beautiful swans: <?php $wire->addHookBefore('WireMail::send', function(HookEvent $event) { // double check that we got a wiremail instance // this also tells the IDE what $mail is (to get IntelliSense) $mail = $event->object; if (!$mail instanceof WireMail) return; // get current mail body $html = $mail->get('bodyHTML'); if (!$html) return; // get email layout markup $layoutFile = wire()->config->paths->templates . 'mails/default.html'; if (!is_file($layoutFile)) return; // replace ##content## with actual mail content $html = str_replace( '##content##', $html, wire()->files->render($layoutFile) ); // write new body to mail $mail->bodyHTML($html); }); The HTML Just create a beautiful MJML template at /site/templates/mails/default.mjml, put ##content## where your email content should go, convert it to HTML and BOOM! 💥 Every email gets automatically wrapped in your gorgeous template. No more CSS wrestling matches, no more "Why does this look different in Outlook?" headaches. Just pure email beauty, automagically! ✨ Now your clients will think you spent days crafting those emails, when in reality, you're sipping coffee while your hook does all the heavy lifting. Work smarter, not harder! 🚀 #ProcessWire #EmailMagic #NoMoreUglyEmails PS: This is the MJML template that I used: <mjml> <mj-head> <mj-attributes> <mj-all font-family="Tahoma" /> <mj-text line-height="140%" /> </mj-attributes> </mj-head> <mj-body background-color="#efefef"> <mj-section background-color="#ffffff" background-repeat="repeat" padding-bottom="30px" padding-top="30px" text-align="center" > <mj-column> <mj-image align="center" padding="25px" src="xxx" target="_blank" width="200px" alt="Logo" ></mj-image> <mj-text>##content##</mj-text> </mj-column> </mj-section> <mj-section> <mj-column> <mj-text font-size="10px" color="#a0a0a0" align="center" > powered by <a href="https://www.baumrock.com/" style="color: #158f66" >baumrock.com</a > </mj-text> </mj-column> </mj-section> </mj-body> </mjml> VSCode has an extension to get a live preview and export MJML to HTML: And here are some other free templates: https://mjml.io/templates I use https://www.base64-image.de/ to add the logo to my mail template as src="data:image/jpeg;base64,/9j/4QAWRXhpZgAATU0AKgAAAA..." to avoid headaches with image paths, remote assets blocking etc.

I don't know for sure but I don't think that this is possible. All posts that I found do not mention any solutions either: https://processwire.com/talk/topic/17834-how-to-rtl-admintheme-core-files/ https://processwire.com/talk/topic/7262-ckeditor-rtl/ https://processwire.com/talk/topic/13540-ck-editor-rlt-for-arabic/ (@flydev seems to have tested it) But UIkit supports RTL, so it might be possible?

RockForms v3.0.0 removes RockFrontend dependency for asset loading and uses RockDevTools instead. It also comes with a new config migration that creates a field to select a form (eg from your rockpagebuilder blocks):

@Stefanowitsch I'm proud to announce that this is now also successfully ported to rockdevtools 😎 Note that the syntax changed to grow() and shrink() as it is not any more a RockFrontend feature and AI told me it's safe to use these wordings as they are not used in css/less/sass https://www.baumrock.com/en/processwire/modules/rockdevtools/docs/rockcss/

Yes that should be all you need to do.

At the moment I'd recommend simply not to upgrade and use the new RockFrontend + RockDevTools just for new projects.

@FireWire thank you very much! Another little detail I just found: I wanted to translate "Telefon" to EN + CZ. For EN it's "Telephone", fine. For CZ it seems to be "Telefon", the same as in German: Now the problem is that if it is the same and it is saved like this, the field's value is lost: Not sure if that is an issue with your module or rather an issue for Ryan? What do you think? I think it's more a thing that should be handled by the core. When the field is filled out and the same as the default's language value, I think it should automatically save as "+" which tells PW to use the same value as the default.

PS: Thought it might be translation cache, but just flushed the cache and I get the same (wrong) translation 😞

Hey @FireWire any idea why this is not working: Never used this feature before, so I might be doing something wrong? Thx for your help!

Hello and welcome to ProcessWire 🙂 Seems you are lucky - this is my setup that I just shared 4 days ago:

That's wrong. It should either be $rockfrontend or rockfrontend()