bernhard

Hey @ryan first of all let me thank you for ProcessWire in general and for all the work you put into it! Also thank you for mentioning me and my modules. Unfortunately I can second what @jploch said, that it's very hard to offer commercial modules in PW, but that's a topic for another post as this one has gotten very long already ? NOTE: Sorry, this post got very long, but I think it covers some important concepts and I think some of the concepts can really push PW forward on the web-application front. I think it's important to understand the details, so I ask you kindly to read carefully and try to understand the bigger picture ? In this post I'd ask for clarification about what you said about custom page classes attaching their own hooks: I think the phrase "everything necessary" might be worth considering here. A class ideally just has one responsibility. Page instances are there to provide an interface to one page's content and be swapped in and out of memory on demand. When there are things like hooks going into a Page, that changes the role completely. If you start doing this a lot on a large site then it may affect scalability. Maybe it's fine for one individual installation or another, however. I didn't want to believe that, because everything that I've built over the last few years relies heavily on the concept of "MagicPages" which is a feature of RockMigrations and which basically turns every custom page class into an autoload module where you can add hooks that are related to that pageclass. This concept makes maintainability of the whole project a lot easier imho. Before I invented that concept I had quite complex applications and they had hundreds of lines of code in /site/ready.php or /site/init.php; ---------- first some background, later the tests ------------------ ---------- the tests ------------------ ---------------- Very, very long story short: @ryan I'd appreciate if you could explain in more detail why you think it is bad to put - what I'd call - pageclass-related code into pageclasses? Also I'd like to invite you to re-think if it is really bad to have things like "getPageListLabel" in the pageclass. I think this is a great to have these methods and I really enjoy having "editForm($form)" as a shortcut for ProcessPageEdit::buildForm if($page->template == ...) and so on. At the very minimum I'd love to have an init() and a ready() method where we can add hooks as we need them. Thank you very much for reading. I'm sorry for the length, but I hope there was maybe something interesting in it. Please let me know if I did anything wrong with my tests or what I could do better. Thx. Long live ProcessWire ?

Thx, I hope you enjoy it! Looks good. I'm always using an autoload module for every project called /site/modules/Site/Site.module.php and put all the global things there. So there I'd have a migrate() method with something like this: <?php public function migrate() { $rm = rockmigrations(); $rm->createTemplate('doo'); } And then all the migrations that are related to the "doo" template go into the DooPage.php pageclass. Creating the fields can either go in Site.modul.php or in DooPage.php - it depends. If I want to reuse these fields I put them in Site.module.php - if they are solely for DooPage I put them in DooPage.php In the module settings you have a checkbox to copy snippets over to /your/project/.vscode and that should make VSCode recognise the snippets and show suggestions once you type "rmf-" etc

Anybody using RockMigrations for automated deployments please check out v5.0.1 which changes the names of the release folders from "release-[deploy-id]-[commit-sha]" to "release-YYYYmmddHHiiss-[commit-sha]" The reason for this change is that yesterday suddenly my deployments broke and it turned out that the deploy-id made a jump from 999... to 100... which broke the logic that was used for renaming all release folders after each deployment. This should not happen any more now that we are using timestamps which are maybe more helpful anyhow. I don't think so but in case it does not work with the new version remove all old release folders and then deploy again.

Please check out the new version on the dev branch which will be merged begin of next month: // site/ready.php wire()->addHookAfter("RockFrontend::addLiveReload", function ($event) { // if the current user is a guest user we override the // original return value and set it to false // which will tell RF to not add livereload markup if(wire()->user->isGuest()) $event->return = false; });

What do you mean? For a guest user on development? On a live site you should never ever enable Livereload.

Ok glad it was helpful. I never know the level of the users so it's sometimes hard do find the right amount of information ? Looks like you are just missing the |noescape filter. Use it with caution, see https://latte.nette.org/en/tags#toc-escaping-output The reason why you don't need it always is that many times RockFrontend/RockPageBuilder will return HTML objects so that Latte knows not to escape the output. If you return some html code as regular string then latte doesn't know anything and will encode entities for preventing some vulnerabilities.

I just had a look at your example and answered the question about the latte syntax. I didn't think about what you are actually doing. The error message means that you provided an invalid selector, which is obvious in your case as you are - as I said - in PHP land inside the brackets. That means inside the brackets the $block->rpb_left will likely be a RockPageBuilder\FieldData object (similar to a PageArray). You can't to a $pages->get( FieldData ) and that's what it complains about I guess. What you are doing with " ... " is to typecast it to a string value and that makes it return the page ID if you have a single block in that field. If you had multiple blocks added to that field it would do something like $pages->get("1010|1011|1012") which would also cause an error! It's really nothing related to RockPageBuilder or Latte, it's just basic PW API usage. Didn't understand you where having problems with this, sorry. But glad you got it sorted.

Once you are in a tag you don't need any brackets any more. Basically inside the bracket its regular php: {$pages->get($block->rpb_left)->text()}

Hi @sebibu thx for the great feedback ? Technically you can achieve that by creating a new block called "layout". Then you create two new RPB fields, eg column_left and column_right. Then you can add blocks to those fields, for example add "headline", "text" and "image" blocks to the column_left field. Then you can go to column_right and click add new block and click reuse existing block for all of your blocks. For the frontend you have to create the markup of your layout in the "layout" block's template file (eg layout.latte or layout.view.php). The problem with such setups is that it get's more complicated and you are moving the sweet spot between easy of use and features more towards features at the cost of more complicated content editing. On the backend RPB will show a button for nested RPB fields to edit those fields in a modal (or panel I think). So editors have to save the base page first, then can edit nested content. On the frontend this should be less of an issue. You can try and report back what you find. Also @Stefanowitsch might have useful tips as he built a quite complex page using RockPageBuilder recently and I think he is going to share something soon?! ?

Yes, quite easy ? $wire->addHookAfter( 'ProcessPageEdit::buildForm', function (HookEvent $event) { $form = $event->return; $page = $event->process->getPage(); // if page is young enough don't lock the page name field $lockPagenameAfterSeconds = 60; if ($page->created > time() - $lockPagenameAfterSeconds) return; // get field and set status to collapsed + locked $field = $form->get('_pw_page_name'); $field->collapsed = Inputfield::collapsedLocked; $field->notes = 'Can not be changed any more'; } ); Alternatively you could use $page->meta() to set a flag at some point instead of waiting 60s.

I'll continue the monologue... Installation and setup has recently become a lot easier as I made UIkit and Tailwind a integral part rather than an optional addon. I guess anybody not wanting one of those components will never ever use the profile anyhow. The benefit is that for a full working setup all you have to do is follow the instructions of the welcome screen: No mercy for all those who have not tried this setup! ?

You can have a look at https://github.com/baumrock/site-rockfrontend

It should be there, of course. I just checked and I can reproduce this on my end, so I'll try to fix this asap. Can you please confirm that your user does also not see the clone icon?

Hi @iank thx for the report - that has been fixed 2 days ago, just forgot to push it to main ? It is now available to download on my website! https://www.baumrock.com/en/releases/rockpagebuilder/

Thx for sharing. Does it have a feature to auto-close the modal after page save (without errors) and then reload the page?

Before I find time to add my very own wishlist let's not forget the PW requests repository

Anything wrong with this? wire()->classLoader->addNamespace("MyModuleNamespace", __DIR__ . "/classes"); This will add an autoloader for all files in folder __DIR__ . '/classes' where all these files need to have the namespace "MyModuleNamespace". See https://github.com/baumrock/RockAdminTweaks/blob/a8b82fff339ecf403966d806db398d20286219cd/RockAdminTweaks.module.php#L28 for an example. As far as I know require_once is problematic in multi instance usage, because you have different paths for the same class and that causes "fatal error: cannot redeclare class XYZ ..."

Hey @FireWire sorry for the trouble. Could you please provide step by step instructions to reproduce this?

Hey @adrian this is a small issue but it gets annoying here while working on a new frontend as I see it on every page reload ? This is my layout: The blue border shows where the <body> is. I'm using a dark gray background for <html> and white background for <body> to make sure that the footer (the part where is says "Impressum / Datenschutz TBD" looks like it goes down until the page ends, but actually it ends where the blue line of the body is. This seems to work well, the only problem I see so far is that the tracy debug bar flickers on page load. It seems to be at the bottom of <body> because I tried making the body 100% height and the flash was gone. I also don't see it if I "disable tracy", but I still see it if I only "hide tracy" (the very right icon). Would it be possible to hide tracy until the DOM is loaded or until the final position of the bar has been calculated? Thx in advance! Update: I sometimes see the white stripe even if the bar is disabled! PS: I also tried to change my concept and make the body 100% and then make the body have gray background and make <main> have white bg, but that caused other problems with my layout so I'd prefer a solution that works with html+body ?

Sorry, but I still can't reproduce it even with "hidden" setting... No logo field there... If you want to find the reason I think you have to debug that further and maybe check everything on a fresh install and see when/if you see the same bug. If you want a quick&dirty solution we could try to add a hookable method that runs after each migration of the settingspage where you should be able to override any settings.

Hey @FireWire I can't reproduce. I tried the following: Do a modules refresh to make sure everything is set to default Check the logo field - it was opened by default. Edit template "rocksettings" Edit field "rocksettings_logo" in context of this template, set visibility to "closed + ajax loaded" Do a modules refresh again to run all migrations. The field was still ajax-loaded after the migrations. Can you please provide more details or step by step instructions?

Hey @FireWire fields created by the module are migrated on every modules::refresh, so if fields define a default collapsed state then this will be applied to the field on every migration. This is intended. If you want to override this you can set different settings in template context, then your modifications should keep intact. Or am I misunderstanding?

As I know you are using RockMigrations / RockPageBuilder have you seen https://www.baumrock.com/en/processwire/modules/rockmigrations/docs/magicpages/ ? It will let you define hooks in an init() or ready() method in your custom page class. There you can add hooks and RM will make sure it will only trigger init/ready once for each pageclass, which is one culprit when using loaded() as it will get triggered multiple times and potentially add hooks more often than once. Also it has shortcuts for often needed hooks, so for example you can hook the backend page edit form like this: public function editFormContent($form) { $form->add([ 'type' => 'markup', 'label' => 'foo', 'value' => 'bar', ]); }

You are just missing the final semicolon after addDefaultFolder()

Anybody using this config setting $config->livereloadBuild = true; please update to the latest version v3.18.2 otherwise the "npm run build" will execute every second if you have multiple tabs open which will produce useless cpu cycles and make your computer feel like it's training for a marathon ??