bernhard

Hey @eydun The module uses PHP8 syntax/features on several spots. All my modules do, as PHP7.4 is end of life and updating should be very easy. There will definitely be some challenges. Most likely a lot more than upgrading your site to PHP8.1 or 8.2 which would be the best thing to do anyhow ?

Ok great, I thought I might be missing something, which can easily happen if you don't use the "regular" approach any more ? For me the runtime approach in general is a huge benefit. Once you start defining things in code all the little details that you would usually avoid because the GUI does not support it suddenly become a no-brainer and very easy to add. All the little customisations that you'd usually need a hook or a module for. They are simply there in your pageclass and you start to develop the backend (page editor) similar to how you'd develop your frontend. <?php public function editForm($form) { if ($f = $form->get('title')) { $f->appendMarkup(" <div>Custom field markup without any hooks...</div> <style>#wrap_Inputfield_title {border: 5px solid red;z-index:1;}</style> <script>console.log('js-demo');</script> "); } } PS: Note that this code will only be added on the page editor of pages having the pageclass where you defined your editForm() method! So if you added that in HomePage.php you'll only get the red border on the "home" page ?

Hey @gebeer working with fieldsets in migrations has always been a bit of a pain for me. That's why I'm using them only at runtime in all of my projects. I don't see any drawback with this. Using MagicPages it is as simple as doing this: <?php ... public function editForm($form) { ... $rm->wrapFields( // current form wrapper $form, // fields inside the fieldset [ 'foo' => ['columnWidth'=>33], 'bar' => ['columnWidth'=>33], 'baz' => ['columnWidth'=>33], ], // fieldset settings [ 'label' => 'Your Runtime Fieldset', 'icon' => 'bolt', ] ); } This is a lot quicker than messing around with fields, field order, moving the ending field to the correct place etc. I only place the fields on the correct template, which is necessary for the fields to be queryable by selectors etc and all the rest is done in code in the pageclass. That also makes it possible to switch layouts based on the user's role for example. So the approach is very powerful. I don't see that as a limitation. Or are there any things that I'm missing?

<?php public function editFormContent($form) { $form->add([ 'type' => 'text', 'name' => 'published', 'label' => 'Published at', 'value' => date("Y-m-d H:i:s", $this->published), ]); } public function onProcessInput($form, $input) { $pub = date("Y-m-d H:i:s", strtotime($input->published)); $query = $this->wire->database->prepare( "UPDATE pages SET published=:pub WHERE id=:id" ); $query->execute([':pub' => $pub, ':id' => $this->id]); } ?

Using RockMigration's MagicPages feature: <?php public function editFormContent($form) { $form->add([ 'type' => 'markup', 'label' => 'Published at', 'value' => date("Y-m-d H:i:s", $this->published), ]); } No additional fields needed as @Jan Romero said ?

As I've had the exact same issue yesterday (and also have been adding those rules to every single project) RockFrontend v2.34.0 adds those rules in the defaults.less file wich you simply have to add to your styles array: $rockfrontend->styles() ->add('/site/modules/RockFrontend/less/defaults.less') // add this line // uikit styles ->add('/site/templates/uikit-3.16.3/src/less/uikit.theme.less') ->add('/site/modules/RockFrontend/uikit/defaults.less') ... // minify on production ->minify(!$config->debug);

@Stefanowitsch you can have a look at this old thread: https://processwire.com/talk/topic/13418-prevent-hover-click-on-multilevel-menu-on-touch-devices/ Maybe some similar approach could serve as a simple fix? Or is that something totally different?

Yes, the blog is a PW website. I've had the honor to write one post there some time ago ? I agree that it would be nice to have it on github so that everybody can contribute. But we have lots of blog posts and converting all of them would be a lot of work I guess. But realistically I think nobody would ever contribute a lot except from maybe reporting typos... So I doubt it would make a huge difference if everything was hosted on github.

Thx for reporting back @Stefanowitsch It sounds like this might be a feature (snippet) that we could add to rockfrontend? How does that fastclick work or what does it do? Not sure if I'd feel good using this script on one of my websites ?

Exactly. I'm happy that you see and understand the potential and that you share that ? Definitely ? Thx for the comment! Having everything in one huge migrate.php does not only have the drawback of getting messy quickly. It does also mean that your migrations get slow, because whenever you change anything in that file all migrations will run, no matter if they are necessary or not. If you have everything in separate files on the other hand you get cleaner code, easier to understand chunks and RM will only trigger the migrations that have changes since the last page load, which makes page loads usually be ~1s here even when migrations run. Yep! ? If you understand the principle once, then you will instantly understand every project you are working on that follows the same simple principles.

Had the same need today and using the latest dev version of RockMigrations + MagicPages you can do it like shown in the other post: https://processwire.com/talk/topic/23385-solved-how-to-remove-dropdown-items-from-submit-button/?do=findComment&comment=231535

Had the same need today. When using the latest dev version of RockMigrations you can use MagicPages to achieve this: public function editForm($form) { $this->removeSaveButton($form); }

Or maybe better update the docs so that they can reference blog posts. We have many important explanations in blog posts and the should be linked from/to the docs imho ?

Yes, that's easy of course, but UIkit relies on the primary color in many places... there is .uk-background-primary, .uk-section-primary, .uk-button-primary etc etc. All those places would still show up with the less-defined primary color. I think porting all that to css variables would be a huge effort. But I'm happy if I'm wrong and you show me how it can be done easily ? https://github.com/uikit/uikit/issues/4534 --> my like has been there for quite a while ?

Yeah I'm having these css variables in my head for a long time. Though I'm not sure if it would be wise to jump onto that train. UIkit is built in a very modular way, but it relies heavily on LESS all over. It's super flexible and easy to customize just by setting different variables: I don't think that we'd get this level of control with using css variables? The drawback of less variables is that you need to recompile everything on change whereas when using css variables you can apply changes on the fly via JS, which is cool. For working with dark and light mode there is also https://getuikit.com/docs/inverse. It's a huge topic ?

Hey @adrian I'm getting an error when having a Nette ArrayHash in a session variable: Error: Object of class __PHP_Incomplete_Class could not be converted to string in /var/www/html/site/assets/cache/FileCompiler/site/modules/TracyDebugger/panels/RequestInfoPanel.php:813 Stack trace: #0 /var/www/html/site/assets/cache/FileCompiler/site/modules/TracyDebugger/tracy-2.10.x/src/Tracy/Bar/Bar.php(143): RequestInfoPanel->getPanel() #1 /var/www/html/site/assets/cache/FileCompiler/site/modules/TracyDebugger/tracy-2.10.x/src/Tracy/Bar/Bar.php(115): Tracy\Bar->renderPanels('') #2 /var/www/html/site/assets/cache/FileCompiler/site/modules/TracyDebugger/tracy-2.10.x/src/Tracy/Bar/Bar.php(89): Tracy\Bar->renderPartial('main') #3 /var/www/html/site/modules/TracyDebugger/tracy-2.10.x/src/Tracy/Debugger/DevelopmentStrategy.php(123): Tracy\Bar->render(Object(Tracy\DeferredContent)) #4 /var/www/html/site/assets/cache/FileCompiler/site/modules/TracyDebugger/tracy-2.10.x/src/Tracy/Debugger/Debugger.php(309): Tracy\DevelopmentStrategy->renderBar() #5 [internal function]: Tracy\Debugger::shutdownHandler() #6 {main} This fixes it for me: try { if (is_object($value)) $value = (string)$value; } catch (\Throwable $th) { try { $value = json_encode($value); } catch (\Throwable $th) { $value = $th->getMessage(); } }

ChatGPT helped me to improve RockMigrations - it's a little scary but it really saved me time today. First, I wanted to support single paths (not json) in the workflow file definition: That worked after I adjusted the variable defaults of input.PATHS to "{}" so that the parsing does not throw an error. No idea why it actually seems to parse the json even if the if-condition is not met, but it works now, so I'm happy with that. Then, as that worked quite well, I tried to fix a warning that I've been getting for quite some time and that worked even better: All updates are on the dev branch.

Hey @Stefanowitsch thx, I've pushed that update to v2.33.0 ? Not sure if it's intentional, but you don't need the class "rf-scrollclass" on your <header>, you only need the attribute. Also I've been thinking if something like this would make sense: rf-scrollclass="show@300-800" ? But I can't think of a scenario where I'd really need that?! The feature was only developed for to-top scrollbuttons that appear when scrolled down for a certain amount. Not sure if it could be helpful for anything else?

Sure, I forgot to mention that I've also added the suggested fix and it works for me on 3.0.214 ?

Great ? It's been some time that I had my head into admin style development, so I'd have to invest time to get into it again. Maybe it just needs better docs to get started and to clearly communicate what module authors need to watch out for so that everything works in every scenario? Where is that variable coming from? Is that already part of uikit or did you add that? Nothing to be sorry about. Didn't want to sound offending, sorry if I did. You might have a look at https://github.com/baumrock/Scss - I developed it for the purpose of quickly creating PRs as the core uses SCSS and not LESS. I'd not really care about what to use, but I think as AdminThemeUikit uses LESS it might be better to stick to less. Also it just works for me and I have no experience when it comes to compiling uikit from scss sources (which exist I think). Not sure if that is anything helpful but I wanted to add that to the brainstorming ?

I've also had issues with that on RockMigrations when testing some yaml features so I'd be happy for a good solution ?

Hey @Richard Jedlička am I missing anything or are you asking for a PR to remove one slash in one file as @szabesz already explained? I think it would be less effort if you just changed that file yourself (you could do that even in the browser) than having someone make a pr and approve and merge that ?

Hey @flydev it's a nice theme, just tried it again as I'm getting more used to dark mode in general. I'm not sure about how we should approach this. I think before we ask module developers to adopt to our workflow we'd need to find a solid workflow for ourselves and find standards that we can agree on. For example it seems that your style does not use my rock-primary convention? Also why are you suggesting SCSS when the module and AdminThemeUikit use LESS for everything? Here's a project with your style: And here it is with my style: What I find great about the rock style is that I can simply set a primary color in the module's settings and the backend instantly fits to the clients CI: Your module has this yellowish primary color which in my case should be #00bb86 ? Another thing is that my PageBuilder uses SVGs for showing available content elements: I'd not be extremely happy if I had to add support for dark themes here. But that's obviously only a topic of lazyness efficiency ? I'm happy that you try to move forward here and I agree that module authors should provide the stylesheets for supporting dark styles. But I also think we should make it as easy as possible so that it's as little effort as possible.

Hey @flydev great to hear that ? Unfortunately there is an issue with my approach of reading the version number from the json. It will break the version number in the PW modules directory (as you mentioned). I've asked Ryan to make the modules directory grab the version from package.json if it does not find a version in the info file/method. Hopefully he will add that. The workflow is a huge time and brain saver for me every day. See https://github.com/processwire/processwire-issues/issues/1690 I'm also using this approach now not only for my modules but also for the project's main repository. It's great. I push to dev and github deploys the site to staging. I push to main and github creates a new release and then pushes that release to production ?

v3.19.0 comes with a new magic method to easily set the page name whenever a page is saved: public function setPageName() { if (!$this->year()) return uniqid(); return $this->title . "-" . $this->year(); } It will also lock the page name field and show a hint so that everybody understands what's going on: