bernhard

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/...

Hey @Techno "default" means the default language of your specific ProcessWire instance, not more, not less. It does not refer to your default spoken language, not your default browser language, not a global default PW language, nothing like that. It only means this is the default language of your own website. Which language that is is up to you, it can be anything. For me the default is often german, for you it could be PT, for others it could be FI, etc.. Have a look here:

Hi @Techno welcome to PW ? Have a look at the absolutely brilliant Tracy Debugger https://adrianbj.github.io/TracyDebugger/#/ and its debug methods https://adrianbj.github.io/TracyDebugger/#/debug-methods

You can use this hook to do what you want: $wire->addHookBefore("InputfieldFile::render", function (HookEvent $event) { $inputfield = $event->object; if ($inputfield->name !== 'your_fields_name') return; $inputfield->appendMarkup .= "<script> document.currentScript.parentElement.querySelectorAll('a.InputfieldFileName').forEach(function(link) { if (!link.href.endsWith('.pdf')) return; link.removeAttribute('download'); }); </script>"; });

If I reverse the order by disabling autoload and rendering the assets manually those Firefox warnings disappear, and I feel like the pages render a lot smoother in FF. Hey @Andi I've just pushed a "fix" for this on the latest dev. I did some research and from what I read it should not make a difference, but if at all it might be better to load styles first and then scripts, so that's what I'm doing now. The load order has always been scripts then styles. So nothing changed here in the past.

This is a quite common problem, but I haven't seen a good solution for it. Probably there is none, because the problem is not the technical solution, the problem is the problem itself. Does that make sense? We have different languages and we have different regions, so we have a multidemensional thing to show an a single-dimensional website. Even if we had a technical solution (like url segments or page tree) the problem is still a problem in my opinion, because content get's tedious to manage. But I'd be curious if anybody has found a good solution for it, as I've once talked to someone looking for something similar and he said PW would not be a good solution for this task. I don't think that this is true, but maybe my feeling is wrong and there are other platforms that already solve that challenge properly? Please let me know if you know any. --- I think if I'd had to build this I'd go with the page tree for regions and a global "data-pages" section for pages that can be shared as needed by the region pages. But it depends on the priorities of the specific project. Maybe reusing content is more important, maybe something else... What I could think of would look like this: -- home -- content -- foo -- bar -- baz -- about us -- europe -- about us -- asia -- foo -- bar -- about us -- america -- baz so all content would go into /content and all the regions would be reflected in the tree and only reference those content pages. Routing would be easy and all regions would support all language, eg /en/europe/about-us Think of it similar to a menu builder. Editing would get a little more complex, but I think that's a small price to pay and I can't think of an easier solution to this multi-dimensional problem ?

@maetmar not sure where you read about RockForms, but it's definitely neither a module by Ryan nor a replacement for FormBuilder, which is Ryans pro module. RockForms is a module built by me (baumrock.com) and is - like FormBuilder - a module that tries to help us developers to create secure and versatile forms for PW websites easily and quickly. In contrast to FormBuilder it does not come with a UI to build your forms. Instead if offers a simple* API to define your forms from within one PHP file and get forms with 100% custom markup (no iframes!) that have validation both on the frontend and backend with just on single source of code. As you define your forms in code rather than via GUI it is a lot easier to work with it on GIT based workflows. * it's based on nette forms and the API is unfortunately not as straightforward as we are used to from PW, but I did my best to make the experience as smooth as possible.