bernhard

@FireWire not sure what you want to say or ask?

@adrian unfortunately I'm lost with this and need some more help 😞 Where would I put this mapping and what would I place as patterns? It feels complicated to me and I'm a bit afraid of doing this for each and every project 😮 I have a wrong return value in Editor.php on line 49 which throws a bluescreen like this: As you can see the path to that file shows /example.com/site/modules/.../Editor.php The tooltip shows the correct path in the DDEV web container: /public/site/modules... When I click the link it tries to open that folder in Cursor, but without the needed /public and therefore it does not find the file: I'm totally lost and I hope you have an idea?

Hey @FireWire thx for the idea/suggestion! Sounds good to me! The only thing to consider would be to also account for hidden blocks. Blocks already have an _mxhidden flag/attribute which is used both for rendering/not rendering the block but it is also used in the helper methods like getBlockNum() or getBlockIndex(). The latter is the base implementation where it accounts for that flag. So maybe all we need to do is to move this: foreach ($items as $item) { if ($item->_mxhidden) continue; if ($item->_temp) continue; if ($item->id === $this->id) return $i; $i++; } Into a dedicated method as you suggest?

Hey @FireWire thx sounds good! I can't remember any reason for having it in __construct I have just added this to the dev branch so we have a month of testing before it's merged to main 🙂

I think the latte docs here should answer your question: https://latte.nette.org/en/template-inheritance

@Sanyaissues and I have been working intensively on a new version of RockMigrations Deployments, which will be moved to RockShell and will support Github Environments. So we thought about having an .env file per environment instead of prefixing every variable: // STAGING.env dbHost=localhost dbName=db_staging dbUser=whatever dbPass=1234 vs STAGING_dbHost=localhost STAGING_dbName=db_staging STAGING_dbUser=whatever STAGING_dbPass=1234 PRODUCTION_dbHost=localhost PRODUCTION_dbName=db_production PRODUCTION_dbUser=whatever PRODUCTION_dbPass=1234 But at the moment I decided to go with PHP files, so there is no need to change anything in your library 🙂 Thx for the explanation!

v7.0.0 removes the hideFromGuests() feature and moves it to the dedicated RockGatekeeper module:

RockGatekeeper A lightweight ProcessWire module that provides simple password protection for your website using a configurable gatekeeper password. Overview RockGatekeeper adds a basic authentication layer to your ProcessWire site. When enabled, it blocks access to all pages for guest users unless they provide the correct password via URL parameter. Features Minimal footprint: Only runs when gatekeeper is configured Session-based: Once authenticated, users stay logged in for the session IP tracking: Remembers the IP address of authenticated users Clean URLs: Automatically removes the password parameter from URLs after authentication CLI safe: Won't interfere with command-line operations Installation Copy the RockGatekeeper folder to your site/modules/ directory Install the module in ProcessWire admin Configure the gatekeeper password in your site config Configuration Add the gatekeeper password to your site configuration: // In site/config.php $config->gatekeeper = 'your-secret-password'; Usage Basic Authentication To access the protected site, users need to append the password as a URL parameter: https://yoursite.com/?gatekeeper=your-secret-password After successful authentication, users will be redirected to the same page without the password parameter, and they'll have access to the entire site for the duration of their session. Download & Docs: baumrock.com/RockGatekeeper

Hey @FireWire this is a really cool class! @Sanyaissues recommended it, so I had a closer look. I added it to RockShell (experimental) here: https://github.com/baumrock/RockShell/tree/env And I have added this little improvement: https://github.com/baumrock/RockShell/blob/7605dcaad6f0b009e01039405936aad825dc47c5/Env/Env.php#L37-L39 Then I added this test command: https://github.com/baumrock/RockShell/blob/env/App/Commands/EnvTest.php What I do not understand: It creates the file RockShell/Env/cache/env.php to cache the results. Does that mean that your class only supports reading from one single .env file system wide? What if I loaded another .env file from another folder? Would that be cached somewhere else or would that overwrite my existing .env file? Or is it maybe the point to always ever only have one .env file for the project? Never used .env before, sorry 🙂

// get current mail body $html = $mail->get('bodyHTML'); if (!$html) $html = nl2br($mail->get('body')); // <--------- add this line if (!$html) return;

I'd just add the button as regular html that you then place in ##content## in your mjml file. That way you don't have to recreate the .html from the .mjml - but it depends. If you need complex content like a responsive grid then mjml might be the better choice.

@snck yeah that's likely the change detection in RPB not recognising the change. Sounds like it would need a fix in RPB not in fluency. Do you have the latest version of RPB? There have been some changes in change detection, one of them coming from @FireWire himself 🙂

Glad it was helpful 🙂 Believe it or not - I can't reproduce it at the moment 😅 I'll keep an eye on it!

Hey @adrian thx for your thoughts on this. With htmx you can add hx-boost to and dom element and htmx will convert all links in that element to ajax powered links that fetch the new page's data and then replace the content of the dom element instead of reloading the page. You could, for example, do this: <body hx-boost> and it would replace the whole body for you after clicking on a link. This would cause the tracy debug bar to disappear. That's why I did this: <body> <div hx-boost> ... </div> </body> Tracy injects the debug bar in the body, which means it can survive different swaps of the hx-boost content and shows new requests properly as ajax requests. This cannot be the issue. I have no tabs and I have a single d($page) call. If I find time I'll ask the folks at nette about it. Thx four your assessment!

And https://processwire.com/store/form-builder/ has a stripe integration as far as I know

Another issue that I just found is that it breaks the console 😞 The first request goes through and I get the result of d($page) in the dumps area, but I also get this in the devtools console: VM20245:1 Uncaught QuotaExceededError: Failed to execute 'setItem' on 'Storage': Setting the value of 'tracyConsoleTabs' exceeded the quota. at xmlhttp.onreadystatechange (<anonymous>:1:287591) I really don't want to bother you with this edge case scenario but maybe there is not much to it to fix it?!

Hey @adrian I'm using HTMX on my current project, specifically hx-boost which turns every regular link on the page into an ajax-powered link. It makes the request and then swaps out the content without a new page load. This is mostly great but sometimes introduces issues, for example the tracy debug bar needs to be out of the swapped area to stay on the page. I managed to do that and thought it was working well. The debug bar stays on the page and for each link that I click I get another AJAX entry in the debug bar, which is great 🙂 Today I realised that when I click the browser's back button I get this error and the debug bar disappears: tool/?_tracy_bar=js&v=2.10.10&XDEBUG_SESSION_STOP=1:34 Uncaught TypeError: Cannot read properties of null (reading 'Tracy') at new Panel (tool/?_tracy_bar=js&v=2.10.10&XDEBUG_SESSION_STOP=1:34:31) at tool/?_tracy_bar=js&v=2.10.10&XDEBUG_SESSION_STOP=1:453:30 at NodeList.forEach (<anonymous>) at Debug.loadAjax (tool/?_tracy_bar=js&v=2.10.10&XDEBUG_SESSION_STOP=1:451:48) at tool/?_tracy_bar=content-ajax.db1c54dcde_4&XDEBUG_SESSION_STOP=1&v=0.5514348022883848:1:13 Do you think this is something that can be accounted in Tracy Debugger? It's not critical, but a bit annoying. So if there is a simple solution for it I'd be thankful 🙂

You can apply any SQL you want by hooking into the PageFinder: $wire->addHookAfter("PageFinder::getQuery", function (HookEvent $event) { // get the DatabaseQuerySelect object $query = $event->return; // dump the object to tracy // https://i.imgur.com/BdDEQU3.png bdb($query); // modify the query to only find pages with name length < 5 $query->where("LENGTH(pages.name)<5"); // remove the hook after first execution $event->removeHook(null); }); bd($pages->find("id>0")); The idea is to add the hook directly above your $pages->find() call and inside the hook you remove it so that it does not apply to any other $pages->find() operations that might occur later. This is a DatabaseQuerySelect object: And with that object you can add any custom ->where() or ->join() or whatever you need.

You can add the class InputfieldIgnoreChanges to your field then the warning will not appear. Check out inputfields.js:

Hey @adrian that works! I added a pull request for that and also added another one to improve dumps when using latte. The problem here is that when using latte files and adding a {bd('whatever')} in those files tracy actually picks up the compiled cache file and not the source file: source: /site/templates/latte/includes/foo.latte cache: /site/assets/cache/Latte/latte-includes-foo.php The implementation is kinda hacky and uses rockfrontend's dom tools to parse the html content of the dumps panel and then rewrite it to my needs. I didn't find a better option to modify what tracy puts in its bd() editorlinks output. If you know one let me know!

I'm not sure I understand. buildForm is called when the form is rendered, which would be a GET request. So this is how you could set defaults based on get params: $form->addText('demo', 'Demo') ->setDefaultValue(wire()->input->get('demo')); Again you need to import wire() correctly or use $form->wire->input

The only breaking change in v6 was the changes introduced in RockFrontend regarding ->styles() and ->scripts(), see https://www.baumrock.com/en/processwire/modules/rockfrontend/docs/asset-tools/#upgrade-guide If you need help just let me know!

If all RockPageBuilder files are in /site/modules/RockFields please just rename that folder to /site/modules/RockPageBuilder and you should be fine 🙂

Hey @gebeer RockFields is part of RockPageBuilder and should not be in /site/modules/RockFields but in /site/modules/RockPageBuilder I think you have a custom folder structure that is not intended. This is how it should be:

You need to have the proper use statement at the top or use the full name with the namespace: RockForms have "namespace RockForms", so if you use "rockforms()" in this file it will look for "\RockForms\rockforms()" which does not exist. So you either use "\ProcessWire\rockforms()" or you add the use statement. If that's not done correctly my ide shows me the problem: PS: You can also use $form->rockforms()