bernhard

Would be nice to share the whole hook ?

Haha, so true. How often have I heard "super easy, super simple..." ? I agree with most of what @wbmnfktr said, but IMHO if you don't use the PW backend you probably lose one of the main advantages of PW over laravel et al. You have to build all the forms, all the logic and all the underlying concepts on your own. Have a look at https://www.youtube.com/watch?v=MYyJ4PuL4pY for example. When you watch this video you'll see so many things that are so much quicker when using PW + backend. Do I say you should use the PW backend? No, but it's probably too early to ditch it. If the design is important it's probably easier to build something on your own, but it sounds like a quite technical project with tech-savvy users I guess, so using the PW backend should work quite well?! You could also just replace the things you want to have different and build your own admin theme. For example you could totally replace the main menu bar / header and leave everything else as it is. 80-100h sounds sporty to me ?

I don't think so. When I asked Ryan recently about modifications for our admin style he said he usually does those small modifications with JS. Not very pretty, but on the other hand this might be more robust than str_replace (which is not pretty either).

Ah, didn't know that existed! thx ?

I thought exactly the same, but I think he wants to show the published date and not the modified date? So if anyone edited an already published blogpost the date would NOT change. At least that's what the hook does as far as I understand. Maybe this shows that the naming of "$blog->date_modified = $page->date_modified;" might not be ideal ?

This might also be helpful, I don't know, I tried ? https://youtu.be/ncS36UqaBvc?si=SYhVc_qcaN5lneDP&t=355 All the best for your journey!

Hi @FireWire thx for your kind words and congrats for the project! I think what you are trying to do is already possible, it has just not been documented yet ? So I've added it to the docs for you: https://www.baumrock.com/en/processwire/modules/rockpagebuilder/docs/blocks/#conditional-blocks Does that do what you need? As mentioned in the notes you could also hook into "getAllowedBlocks". Or you can also create different fields and share blocks across those fields. The easiest solution is the "show" property in the info method if you can trust your users to some extent. Your project sounds great, would be awesome if you shared the result with us once it is online ? All the best!

Great! Are you porting a feature from AOS to RM Tweaks? ?

I'm using git revert + rockshell db:restore for that ? But on large dbs a snapshot might be faster, so I keep that in mind, thx!

Why don't you look into the code of those modules or ask the module authors how they did it?

The endpoints don't have a $page, because they are not a page ? It's just an url hook behind the scenes. You can add the page url in a hidden field of the form.

For options you can define the id, a value and a title (aka label): 123=value|title So you could create these options: 1=left|Left aligned image 2=right|Right aligned image In your code you can then access either one of those three. See https://processwire.com/docs/fields/select-options-fieldtype/ Would that match your needs?

How do you use it? I've never used it myself ? Glad it is helpful @FireWire ?

From the Rock Monthly newsletter: RockPageBuilder v5.4.2 We have now an API to save settings: $block->saveSetting('image-size', 'S'); Docs about Frontend Editing have been improved. Fixed "$root not defined" bug

From the Rock Monthly newsletter: RockForms v1.4.0 RockForms does now support file uploads!! ? https://tinyurl.com/ymhofek9 Improved several security features thx to @netcarver Improved the API

Haha, thx @netcarver it was great input ?

From the Rock Monthly newsletter: RockShell v3.0.0 Folders are now protected from direct access via .htaccess thx to a PR from @netcarver (but I don't think it was a security risk before) @netcarver also suggested to change the folder structure. This might break some commands, so I bumped the version to 3.0 (it might work without any changes though!) Made wget quiet in pw:install command as requested by @netcarver

From latest Rock Monthly newsletter: RockMigrations v4.3.0 New method hidePageFromTree() New config setting to disable magic methods (request by @netcarver) https://tinyurl.com/ykv9otsc Improved the "copy code" feature in the PW backend GUI Improved method renderTable()

From latest Rock Monthly newsletter: RockFrontend v3.14.0 LiveReload does now work on Tracy's bluescreen! That means if you introduce an error that throws an exception (like a typo that causes a call to undefined function...) you don't have to leave the IDE and reload the browser. Simply fix the bug and your browser will refresh! The great AJAX Endpoints feature has been improved thx to @netcarver We now have LiveReload on AJAX Endpoint debug screens! We now support relative urls in the svgDom() method + improved docs. Sitemap tools have been improved and multilang support has been added, see docs: https://tinyurl.com/ywflthta SEO tools improved: canonical tag now by default!

@netcarver yep, that's also implemented: https://github.com/baumrock/RockMigrations/blob/be4138ed26d8aa0116ebdd21a79148d21574d546/MagicPages.module.php#L191-L202 <?php // in site/classes/OrderPage.php public function onChanged($field, $old, $new) { if($field == 'order_status') { if($new == 'foo') $this->sendFooMail(); elseif($new == 'bar') $this->sendBarMail(); } }

Hey @TomPich I think what you did can also be done like this: https://processwire.com/blog/posts/new-ajax-driven-inputs-conditional-hooks-template-family-settings-and-more/#new-conditional-hooks $wire->addHookAfter('Page(template=order)::changed(order_status)', function($event) { // execute some code when "order_status" changes on "order" pages. });

Or when using Custom Page Classes + MagicPages you have your code where it belongs (if it's for the "home" template then it's in the HomePage.php file) and avoid hook hell in site/ready.php // site/classes/HomePage.php class HomePage extends DefaultPage { use MagicPage; public function editForm($form): void { $f = new InputfieldMarkup(); $f->label = 'Help'; $f->value = 'Foo bar baz!'; $form->prepend($f); } }

What exactly do you mean? A page tree with references to global data pages like I mentioned or a simpler approach where editors just copy over content?

Glad it helped. Congrats on not giving up ? ?

If you want to serve the english content from / instead of /en then you need to go to the home page (id=1), edit it and go to settings: In this example it's default = german and I'm serving "de" from foo.com/... English has url "en", so it's served from foo.com/en/...