bernhard

Sure @snck that sounds like a great addition. I'm not using Scss at the moment though so I'd be happy if you can provide a PR maybe? The magic happens here: https://github.com/baumrock/RockFrontend/blob/e1ba2acb58967fe0cdf7cdc890b54870c5935082/StylesArray.php#L182 So we could just add another line below: $this->parseScssFiles($opt); You'd just need to implement that method based on the parseLessFiles() method ?

Hey @netcarver thx ssh config files are great for sure, but they do not work when using DDEV because you are in a container and not on your host's filesystem with the ssh config file in place. That's why ddev has the ability to do "ddev auth ssh" where it grabs all SSH keys from the host and copies them into the container. Then you can do ssh magic in the container just as if you were working on the host. Almost. The issue I explained above was only occuring inside the container. On the host machine "ssh foo" just worked because the ssh config file was in place. Hope that makes sense. RockShell's db-pull command uses exec() to connect to the remote server via SSH, then it creates the remote dump, it copies it to the local filesystem, then it restores the dump and then it triggers all migrations. That way you can quickly develop locally, do anything you want, try crazy stuff and if you want to start over you just do "php rockshell db-pull staging" and you get a clean version that you have on your remote. Same goes if you added a feature locally and you want to make sure that everything works when pushing to remote. Then you can do a db-pull as well and fire all migrations to see if you forgot anything. Hope that makes sense as well.

For several days I've had issues with connecting to my host from within the ddev container when using RockShell for a quick php rockshell db-pull staging I got the following error: Turned out that the problem was that I had too many SSH keys in my container (4) and the webhost seemed to block the request before ddev could use the correct key. The solution was to put only the two necessary keys in a dedicated folder ~/.ssh/ddev and then provide that folder as parameter on ddev auth ssh: ddev auth ssh -d ~/.ssh/ddev It have been tough days having to restore the database manually from staging to my local development ? I guess nobody will ever have problems with this as it's a quite specific situation but maybe it helps someone googling for it...

Not on my end and nobody else reported that. That's why I was asking for an exact step by step guide to try to reproduce this issue. If you can't do that I can't help.

Sorry, that's not precise enough for me to understand. Maybe you can make a short video? https://calipio.com/app/record

Then it would be nice to get a step by step guide to reproduce it ? I've seen that error here and then but don't know when it occurs or why. And a simple reload fixes it. This error does cause issues, because if it occurs then livereload is not working (since it needs the eventstream to work). So if you find anything helpful I'm happy to improve that piece of rockfrontend.

Yeah I think that would be a good addition. I'm happy to help whoever wants to tackle that ?

Yeah sometimes good old strings are just a whole lot easier/faster to write. $scripts->add("foo.js", "defer") vs. $scripts->add("foo.js", ["defer" => ""]); Why not add support for strings in your PR? if(is_string($suffix)) ... elseif(is_array($suffix)) ... else ...

By default LATTE echos the output that you put in { } {$foo = 'FOO!'} That would assign 'FOO!' to the $foo variable and as it is in { } output that. {do $foo = 'FOO!'} That would only assign 'FOO!' to the $foo variable and not output anything. If you want to run more complex code it's always good to have an MVC-like approach with custom page classes, then you could do for example: {$page->doFoo()}

RockFrontend does really not care what you output. But if you have troubles with latte files you can still include PHP files from your latte templates: {$rockfrontend->render('forms/yourform.php')} The only thing necessary might be to add the |noescape filter when rendering HTML markup in latte files

I think the best solution would be to ask Ryan to add an option "copyFiles" to the clone method. It would be very easy to add and I think everything that can help with performance is a welcome addition to Ryan ?

@maetmar I'm quite sure it's just a small thing and since I can't reproduce the issue on my end you could help me a lot in improving the module (for everybody). It would already help if you could provide the output of Debug::backtrace() for the file in question below the line with the $cache variable here: https://github.com/baumrock/RockFrontend/blob/71f8021c7333533d2e4e1753747a88648687ca03/RockFrontend.module.php#L1400

Nice, thx! There's also a version with more control: https://9elements.github.io/fancy-border-radius/full-control.html

Sticking to FA will probably be a good idea because there's a lot of javascript on the backend (for example for adding spinners that indicate loading) and that would likely break with other icon libraries that work differently or use other classes. On the other hand having more icons available would be nice, so the free subset of FA6 sounds like a good idea to me if it does not take up too much space just for the small benefit of having more icons. I think the best chances to get that into the core are if someone just tried it out and provided a PR and let Ryan know about it. Or maybe ask Ryan before doing it if he'd be willing to add it at all (to prevent useless work).

Hey @maetmar thx! It's still not enough information, but obviously it's ugly to use all those noescape filters! I tried on my end and if I put this in _main.php <body> <?= $rockfrontend->render('test.latte') ?> </body> Everything works as expected! Even if I do a {$rockfrontend->render('test2.latte')} in test.latte everything works as expected! I'd appreciate if you could try to debug and fix this on your end and let me know what you had to do. The code in question is here: https://github.com/baumrock/RockFrontend/blob/71f8021c7333533d2e4e1753747a88648687ca03/RockFrontend.module.php#L1397-L1409 There it decides if it returns $html (where you need noescape) or an HTML object via $this->html($html), where noescape is not necessary. Thx

But it worked without noescape before? Now that you say it I think there have been changes to that specific feature. But the goal is to get rid of those noescape filters as much as possible (as long as it is safe to do). Could you share more details about your setup? Where do you call that ->render() ? And what are you trying to render? The whole html markup??

No, it's not ? The mask does not stretch to the image below ? GOT IT!!! The key is to add this to your <svg> element: preserveAspectRatio="none" It's for sure an edge-case but I like solutions that work always, and not almost always ?

Look what you can do using RockFrontend GROW ? .ninifee { position: absolute; bottom: 0; /* right position: 0px on mobile, 150px on desktop */ right: rfGrow(0pxrem, 150pxrem); /* container width that scales the ladybug * 100px @ 1000 and grow to 500px @ 1920 */ width: rfGrow(100px, 500px, 1000, 1920); }

Hey @maetmar sorry for the trouble! I don't know what version you upgraded from and to - there have been several updates and you can see the commit log. But I don't remember anyone that should cause such an issue. But I might be wrong ? What I usually do in such cases is checking out the module commit by commit and see where the problem starts popping up. So in your case I'd clone RockFrontend to /site/modules and then use some kind of GIT GUI to checkout step by step. I'm using VSCode + Git Graph Extension: Then rightclick -> reset current branch to this commit -> hard (discard all changes) Let me know if you find something useful! From what I see this should still work!

IMHO that is something that the module's authors should fix. Adding style overrides to your module would be an ugly fix. What if the module author changed the markup or a style of his/her module? You'd need to update your module as well. And you'd need to somehow make sure that the versions match. It would be a lot better to make a PR and add the styles to those modules. Ideally we'd find a standard way of doing that that all modules could implement. For example having an /site/modules/MyModule/AdminThemeUikit/style.less or something But maybe that's even not necessary if the module's had proper styles? I'm still not 100% getting what you say I think and it's hard without having a specific example. It does not only add crazy styling it also adds crazy scripts and hooks that broke my admin several times. I'm sorry to say that but I'd be careful with that module ? And I'd be even more hesitant to build or use a module that fixes another module... That does not sound like a good idea. Yeah, that's why I think - if at all - such stylings should live in the module itself. I'd be interested in what you say but it would be easier if you were more specific and maybe add screenshots or something. It's very hard to follow and I can't install modules and click around to try to find the spot that you where talking about.

I'll try to provide one when I find the time!

Ok I get the part of conditionally loading LESS files. I think you'd have to do that on your own. See https://github.com/baumrock/AdminStyleRock/blob/4e1c42f0d09e090687fa1df8fa1a8bcfe6c9d065/AdminStyleRock.module.php#L38-L53 how that can be done. But I don't get why you have different modules with different LESS files?! And do they all depend on each other, like do they share color variables or such?!

I still don't get the problem here. Could you please explain that in detail if that does not feel too off-topic? Isn't the uikit grid very similar to the boodstrap grid? Isn't it just a matter of syntax where you write uk-width-1-3 (=1/3) in uikit and col-4 (=4/12 =1/3) in bootstrap?

Hi @Stefanowitsch at the moment it scales linearly, but you can define the min and max viewport for that. I've added a page to the wiki: https://github.com/baumrock/RockFrontend/wiki/PXREM---GROW-(fluid-font-sizes) Does that explain what you were asking? Or do you want to a custom non-linear scale function (like easing)? That would be possible I think but I'm not sure how practical it would be. Input is welcome. The scale factor in the code is basically there for RockPageBuilder ?

Be sure to checkout the new grow feature ?