bernhard

Magic Pages are great ? Note that it's not just a regular update as we are used to! So for existing projects it might be better to stay with RM1. But for new projects you should definitely have a look at RM2 - it's so much better in so many ways, but it will be a quick win if you are used to RM1 as the basic syntax/API did not change a lot ?

If you are using custom page classes + RockMigrations MagicPages feature, then you can simply add this to your init() method: $this->createOnTop(); Here's the full code for a custom page class using that feature: <?php namespace ProcessWire; use RockMigrations\MagicPage; class BasicPagePage extends Page { use MagicPage; public function init() { // $this->setPageNameFromTitle(); // would also be possible :) $this->createOnTop(); } }

https://github.com/baumrock/RockShell#how-to-use-rockshell It's a command line interface for installing PW (php rockshell pw-install) and it also has an opinionated setup command (php rockshell pw-setup). Creating commands is very easy. You can list all available commands via "php rockshell" I'm afraid I don't understand what you want to say. But here's the conditions from their FAQ page: teppo was faster ?

Hey @Jan Romero and @AndZyk what is missing for a proper PR? I don't want to forget about that necessary feature ?

You can enable that in the field's settings on the "input" tab.

That's one of the things that "php rockshell pw-setup" does. DDEV is supposed to be used with docker, so you can use it on any OS. You'll get exactly the same environment no matter who is working on the project - that's especially great in teams. Laragon is not by far easier to use but a lot easier to setup. But you only need to setup DDEV once. Then it runs and runs and runs. And with ddev setting up a new project is by far easier then it was with Laragon for me. It's just "ddev config" and you are done. The biggest benefit for me is that you get a real unix dev environment. So if you have some special need for your server (eg creating thumbnails from PDF via poppler-utils you are out of luck with laragon). With DDEV you simply add poppler-utils to the config of the web container and you can develop everything locally and it will work the same on the live server. Also the config of the project can be added to the project's git repo. That means everybody can just do a git pull && ddev start and will have a working version of the project with all the settings and tools needed for it to run. You can't do that with laragon.

You can do that. RockMigrations will only do what you tell it to do. You can also do that and sometimes I do it myself. It's just a reminder that if you apply changes that are somewhere in code of a migration your changes will get overwritten. If you apply changes via GUI that are not set in any migration than you'll be fine and your manual changes will be kept. That indicator could be improved I guess. For example it could only appear on fields or templates that received changes from a migration. And changes done via RockMigrations could be listed instead of the generic warning. If that is an important feature for you (or anybody else) I'd be happy to merge any PR in that direction and provide all the help needed.

Hey @teppo finally ? Hope you enjoy it! Here you go: https://packagist.org/packages/baumrock/rockmigrations Let me know how it goes

Hey @adrian I'm using SSE in another module as well (it's so great ? ). There I also hook before Session::init and then disable tracy: public function __construct() { if ($this->wire->config->ajax) return; if (!array_key_exists(self::getParam, $_GET)) return; $this->addHookBefore("Session::init", function (HookEvent $event) { $event->wire->config->tracy = ['enabled' => false]; $event->object->sessionAllow = false; $this->liveLog(); }); } It's the same principle as with RockFrontend, but it's another self::getParam here as it's another module! So instead of checking against RockFrontend::getParam - which would obviously not work with this other module - could we disable tracy by default if $config->sessionAllow === FALSE ?

Hey @gornycreative thx for the reports! I've just pushed an update that removes all hardcoded /site paths. See v2.1.13 No, not in this case. RockFrontend has the "smart paths" feature so you can simply do $rockfrontend->styles->add("/site/foo/bar.css") and it should work no matter if the installation is in a subfolder or not. It will automatically do what you have suggested, then get the modified timestamp of that file and then use $config->paths->url... to output that style in the page <head> and append the modified timestamp for cache busting. So you'd end up with something like this: <link href='/project-x/site/foo/bar.css?m=1666772973' rel='stylesheet'><!-- _main.php:10 --> Magic paths do not work in CSS files of course, so I have fixed those hardcoded /site urls there ? Let me know if everything works now as expected!

Sounds reasonable!! Please check v2.1.12 @Andi Thx for your help!

Thx @gornycreative I understand now! So it's only about the generated CSS of the webfont downloader? Or any other spots where you see wrong paths/urls?

Great to hear that ? Interesting. I don't have any issues with that and I also don't have a "partials" folder for example. So I can't really do anything about the issue as I'm not seeing it. Would be great if you could track that down further. I'm quite sure it is in getPath of RockFrontend.module.php so maybe you could just add an early return there at the very top and then move that return down line by line and see when the error starts showing up?

Meanwhile we have a great new feature: You can now simply paste a google fonts url into the module settings and RockFrontend will automatically download all files to /site/templates/fonts (this is not new) and (this is new) also create the file /site/templates/fonts/webfonts.css and add this file to the sites' styles array. That means if you need another weight of your font (eg you need Gudea 900) you simply add 900 to the url, hit save and your frontend will have that font available ? I realised that before this update there were still some steps required with the old webfont downloader to copy and paste the whole CSS to the correct file etc etc... Now RockFrontend does all that for you ?

Sorry @Andi just pushed another fix in v2.1.10 - that should work! Though I'd be interested why it is trying to access something in / Could you do a bd($dir) above https://github.com/baumrock/RockFrontend/blob/5a9ee3ab7d78481ba2bfecb81c03d32556476525/RockFrontend.module.php#L838 and let me know what dirs it tries to access?

Can you please see if v2.1.9 fixes your issue? ?

The issue is most likely RockFrontend->getPath() not returning the correct path for your setup. Can you check this: Add 2 bd() calls in AssetsArray::addAll /** * Add all files of folder to assets array * * Depth is 2 to make it work with RockPageBuilder by default. * * @return self */ public function addAll($path, $suffix = '', $levels = 2, $ext = ['js']) { /** @var RockFrontend $rf */ $rf = $this->wire('modules')->get('RockFrontend'); bd($path, 'before'); $path = $rf->getPath($path); bd($path, 'after'); $files = $this->wire->files->find($path, [ 'recursive' => $levels, 'extensions' => $ext, ]); foreach ($files as $f) $this->add($f, $suffix); return $this; } The output should look something like this:

Could you please give some more details of where it assumes that and how it should behave? Could you please also give me more details here? Please give me a longer explanation so that I can better understand, thx!

Hey @Andi not sure but I think I'd add a bd(Debug::backtrace()); right above WireFileTools.php:765 to see which files are triggering the error, can you try that and see if you find something useful?

Did you do a modules refresh? Module version changes are only applied after refreshing the modules cache.

I already have this in place: https://github.com/baumrock/RockFrontend/blob/ec26e031d60245a871e1615c1346fdccd726fb7d/RockFrontend.module.php#L126 Not sure if an early exit would be better? You could check if a GET parameter with the name RockFrontend::getParam exists ?

Update: I tried using Guzzle and also get an error. My research shows that it seems to be a server setup issue! I'll keep you posted - thx for your help so far!

Hey guys thx for your help. I've changed the line in question to $url and now I get this: The certificate is a letsencrypt wildcard cert. I'm totally blank on that topic - is there anything I can do about that? Or is it an issue with WireHttp?

Sorry, checked getErrors() instead of getError() so I thought that did not help! Here is the error: 2: fsockopen(): php_network_getaddresses: getaddrinfo for failed: Name or service not known, 2: fsockopen(): Unable to connect to :80 (php_network_getaddresses: getaddrinfo for failed: Name or service not known), 0: php_network_getaddresses: getaddrinfo for failed: Name or service not known What does that mean?