bernhard

And another thing to mention / take care of. Just because ProcessWire seems to be running fine that doesn't mean that you are all done. For example what if one of the installed modules had a custom .htaccess in it's module folder that has some custom rules that are necessary to protect some files from direct access? As far as I understand nginx will not be able to read these instructions and you might be open to attacks, no? I think it should at least be clearly mentioned in this thread that anybody trying to use non-apache webservers for running ProcessWire has to take care of this risk on his own and check every single module and every single update or is otherwise really highjacking one of ProcessWires main strengths: Security. For me this seems like a very high risk to take and I'd really be interested in numbers of how much faster nginx is compared to apache so that one can decide whether it's really worth the risk and additional effort.

Hey @FireWire sorry to hear that you are having troubles. It seems that you are doing some quite complex stuff. I've never experienced any of these problems - maybe because I keep things very simple! What is "better" is a very subjective thing, but there are two things I want to mention upfront: Instead of listing all API variables you can just pass the $wire variable and then access anything you need in your template from there: // if you passed the wire variable you can do this: {$wire->pages->find(...)} {$wire->modules->get(...)} {$wire->...} // if you passed "page: $page" do this {$page->wire->pages->find(...)} // or this {var $wire = $page->wire} {$wire->pages->find(...)} I guess I don't have these problems because I'm always working with custom page classes, so I most of the time add those things to the pageclass and then I can just use $page->myMethod(). That has the benefit that template files stay very simple and I have all the logic in PHP and not in Latte, which has a ton of benefits. For example you can do this for debugging: // in site/ready.php bd(wire()->pages->get(123)->myMethod()); Or you could access ->myMethod from anywhere else, like in a cronjob etc. If you have your business logic in latte then you have to refactor at some point or you are violating the DRY concept if you are lazy and just copy that part of your logic from the latte file to the cronjob. I'm not sure I can follow... I put this in whatever.latte: {block foo} <h1>Hello World</h1> {/block} {define bar} <h1>Hello World</h1> {/define} {include foo} {include bar} And I get 3 times "Hello World" as expected. {block} does immediately render while {define} waits for the final include Also I don't know why you make things "complicated". When I need a reusable portion of code like for a button, I simply put that into /site/templates/partials/my-button.latte and then I use {include ../partials/my-button.latte} in my latte file. I'm usually always either in /site/templates/sections or in /site/templates/partials. That's it. Sections are full width elements, like hero, slider, breadcrumbs, main, footer, etc. and partials are things like buttons, cards, etc. Having said that I see that there might be potential to improve the experience though. For example we might make the functions api available to all latte layout files or we might make API variables always available. But to make that happen I'd need some easy to follow real world examples and not complex code examples like your specific setup. Also I'm hesitant as I didn't experience any of these "problems" for maybe two years or so. So we have to identify the real problem first. Maybe the problem is only lack of documentation for example.

Here you go @FireWire thx for your suggestion! Please check out v1.1.1 Now that I tried the different sort settings I must say that sorting by name rather than by group feels better, so I made that the new default 🙂 See the selected icon and the one to the right - same name, different group (filled/outline)

Just added docs to https://www.baumrock.com/en/processwire/modules/rockcolorpicker/docs/ with lots of examples and added some minor improvements 🙂

Sorry, wire() is not available in a latte file, because wire() is actually \ProcessWire\wire with the namespace. In PHP files where you have "namespace ProcessWire" at the top just adding wire() will work. In latte it is a different story, because the latte file has no namespace and it will be compiled. Therefore "wire()" is not available. But all ProcessWire API variables are, so please just use $wire instead of wire(). Pro-Tip: From any API variable you can access the wire object via ->wire, so this would also work: $block->wire->... or $config->wire->... etc.; So in hooks you might see $event->wire->... and that's the reason for this. PS: $block is not an API variable but is available in RockPageBuilder blocks! And as it is also extending "wire" it will also have its methods. Edit: I've just updated the example above and realised that it was using wire('modules') syntax that I'm never using. In that case you need to use $wire->modules->... or simply use $modules->... as $modules is also an API variable and therefore directly available.

And I've just pushed extensive docs to https://www.baumrock.com/en/processwire/modules/site-rockfrontend/docs/ If you haven't tried this site profile this might be a good opportunity to do so 🙂

The page transitions are very cool. Do you have any details about how you built those?

Ok this is solved now. I totally missed the corresponding PR to the SCSS module. It's now there in the dev branch and will be merged to main begin of October. Please mark this topic [solved] thx!

RockFrontend / Latte doesn't provide this syntax as far as I know. What are you referring to? Ah sorry, now I see $map should be a map marker object. The docs there state this: <?php $map = wire('modules')->get('MarkupLeafletMap'); ?> Which you could do in latte like this: {var $map = $modules->get('MarkupLeafletMap')}

This <?php echo $map->render($page, 'YOUR MARKER FIELD'); ?> would be this {$map->render($page, 'YOUR MARKER FIELD')} Your error message means, that $map is NULL. That means $map is not available in your latte file for whatever reason. That means you are not struggling with latte syntax, you are struggling with PHP 😉 😛 You can easily debug this via TracyDebugger: {bd($map)} {bd($page)} To help you with your specific problem I'd need more info in where you are trying to use this markup...

These videos are so much work 🙈 I have tried a different software and a different technique. What do you think?

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; ...