bernhard

Hey @uliverse two days of refactoring later...

You can also use createField, just make sure to use the same settings that I provided. The "field code" in the backend is not 100% accurate all the time. Most importantly you need to change this from "text" to "options".

This is my snippet that I'm using: // Add a options field via RockMigrations 'your_field_name' => [ 'type' => 'options', 'label' => 'Your Field Label', 'icon' => 'cubes', 'options' => [ 1 => 'ONE|This is option one', 2 => 'TWO', 3 => 'THREE', ], ], You get those snippets when using VSCode + enabling them from the module settings: Does the snippet's code work for you?

That's a very good question 😅 I think that should work as well. One benefit I see with the approach above is that we can define the $schema[] array in one place and then reuse this for the ALTER TABLE statement. Ok you could extract that array into a dedicated method as well, then you'd have basically the same with a Module::upgrade() approach. Another thing is that I find it easier to read like this: if($schemaVersion < 2) ... compared to this: if(version_compare($oldVersion, $newVersion) < 1) ... I never know which operator to use here 🙂 And module versions can be confusing, as they can be integers like 104 or version strings like 1.0.4 And last but not least this approach is what I found in FieldtypeComments which is built by Ryan, which should be argument enough 😄 But thanks for the question! If you want to try another route please let us know what you find out 🙂

Sorry don't have more time for the other questions but this one is quickly answered: https://processwire.com/blog/posts/pw-3.0.173/

Ah, sorry, didn't read carefully enough! Hope it was helpful nonetheless 🙂

Congrats and welcome to a new world of superpowers 😉 I don't have details but I'm always using pageNameTranslate: Not sure why that would work differently on new or existing pages... Instead of if(...) { ... } you can use early exit strategy which is usually cleaner in hooks. This is also called "guard clause": So you could write it like this: /* NEWS pages only: prepend date in page-name */ $wire->addHookAfter('Pages::saveReady', function($event) { // get current Page object — in this case this is the first argument for the $event object $page = $event->arguments(0); // Only for pages with news template if($page->template != 'news') return; // Test if field day exists, otherwise exit if (!$page->template->hasField('day')) { $event->message("Field 'day' is missing!"); return; } $title = $page->get('title'); // Sanitize title and substitute special characters $optimizedTitle = wire('sanitizer')->pageNameUTF8($title); //$optimizedTitle = wire('sanitizer')->pageName($title, Sanitizer::okUTF8); // or translate option $date = wireDate('Y-m-d', $page->day); // Set output formatting state off, for page manipulation $page->of(false); $page->name = $date.'-'.$optimizedTitle; //$page->save('name'); $event->message("New saved name is $page->name"); //$event->message("Path of new saved page is $page->path"); }); The difference is minimal here but using if(...) { ... } is usually harder to read, because you could have an else { } somewhere further down the hook, so when trying to understand your hook you have more workload for your brain. When using if($template != 'whatever') return; you instantly know the hook only applies to 'whatever' templates.

Just wanted to mention that nowadays I always use https://caniuse.com/css-text-wrap-balance for this. We have 84% coverage and if it doesn't work it does not really hurt 🙂

True, thx! I've just added it. I guess some others are missing as well... I guess I should go through my github repos and update my website 😅

Hey @FireWire please grab the latest version from the dev branch 😎😍 Note that you even have tabs for latte/php to show both the latte file and the compiled php file!! I got so used to these unhelpful error messages on a white screen that I didn't even think of looking into it. Thx a lot! This improves the dev experience a lot!

@Jonathan Lahijani as I know you are (or have been) a RockMigrations user I'm wondering whether you switched to ProcessDbMigrate or you are using both modules in parallel? Would be interesting to hear the reasons for your decision and how everything went or what you are using which module for.

Hey @FireWire Thx for the great meeting, I created a question in the Nette forum: https://forum.nette.org/en/36655-how-to-get-useful-debug-screens-for-latte-file-errors#p227620

Thank you too! It was great and I learned a lot 🙂 I'll try to remember using fn(...) => and also try to experiment with strict types 🙂 Please mark this topic [solved] thx 🙂

Then you can do this: $field = $modules->get('InputfieldText'); $field->collapsed = wire()->user->isSuperuser() ? Inputfield::collapsedNo : Inputfield::collapsedHidden; ...

if(wire()->user->isSuperuser()) { // your code } ?

Same here, let's have a meeting!

Hey @FireWire let's have a meeting to look into that issue together?

You could ask an AI to provide additional search terms:

Hey @netcarver very interesting 🙂 I've never worked with them but from the demos these two look like very good candidates: http://fabricjs.com/ https://github.com/bubkoo/html-to-image

Hey @uliverse sorry for the trouble. This cost me some headache today 😞 I can confirm there is an issue and I have to look into that as soon as possible. I really did a lot to make the experience as smooth as possible, but somehow something broke...

Hey @uliverse thx for asking. Please invest 15 minutes to understand what npm is and does: I've added this section to the readme: https://github.com/baumrock/site-rockfrontend Does that help?

Hey @Stefanowitsch I'm not using SCSS in any project so I don't have a quick answer and I'd appreciate if you could debug this on your own and let me know if anything has to be changed in the module to make it work. The SCSS support has been added by a PR: https://github.com/baumrock/RockFrontend/pull/29 Maybe you can ping the author about the problem?

Thx @adrian I don't know why but now it works. Maybe I had a typo, maybe something else, I don't know 🙂

Hey @adrian I'm using ProcessPageList() to render a pagelist in my custom process module. I wondered why I only get bd() calls in the debug bar for ajax requests when collapsing a tree item, but not for the very first one. This is my code: <div id='pageviews'></div> <script> $('#pageviews').ProcessPageList({ rootPageID: 1, showRootPage: true, ajaxParams: {'rockcounter': true}, }); </script> I then tried wrapping that code in setTimeout() with a delay of 1000ms and then I got the bd() calls also for the very first request. Is there any recommended way of dealing with this? I tried to wait for dom ready, but that seems to be too early and tracy didn't catch the first request. On my laptop it works with a delay of 100ms, but in other setups it might be different, so I'm wondering if there is a solid way of waiting for tracy to capture the ajax call?

Does anybody of you guys have some numbers in how much faster PW gets when using nginx instead of apache?