bernhard

Ah, that's a different question then ? You can look into TracyDebugger's module disabler feature then. There might be some helpful snippets?

You can provide a selector or a callback as "autoload" property of your module config: https://processwire.com/talk/topic/3768-processwire-dev-branch/#comment-36787

The most important question would be how you save dates in the DB. How do you handle endless recurring dates? Do you set a hard limit on numer of recurrences? Or do you set a limit on the year in the future? etc etc.

The reload part is already there: Inputfields.find('title').trigger('reload'); I don't know if there is a way to update the field's value. I don't think so. But it would be great to have such a feature ?

Great to see someone tackling this ? I wish you all the best for the challenge ? Do you have some screenshots? And maybe a short description how the module works from a technical point of view? Why did you split the finding part in a separate module?

alias time again I'm so used to using the list-long (double-L) command that I'm always using it within my ddev web containers as well. It wouldn't be ddev if they had no solution for that ? Here's the docs: https://ddev.readthedocs.io/en/latest/users/extend/in-container-configuration/ Or just go to your host computers home directory, there you'll find the file ~/.ddev/homeadditions/bash_aliases.example --> rename that to .bash_aliases and you'll have those aliases in all your ddev webcontainers as well ? Update: I'm using this alias now: alias dds='ddev ssh && alias ll="ls -alh"'

Hey @dotnetic would it be possible to rename "bewegen" to "verschieben" in the page tree translation?

TL;DR Just copy this folder to your module and get fully automated releases, tags, changelog and with one additional line of code (see note below!!) also fully automated version numbers for your PW modules! Background/long story: @dotnetic asked me some time ago to use conventional commits for my modules. It was totally new to me, here is the link: https://www.conventionalcommits.org/en/v1.0.0/ I've since adopted that workflow to most of my modules, as it is really just copy and pasting the .workflow folder (and you can simply copy that folder from RockFrontend: https://github.com/baumrock/RockFrontend/tree/main/.github/workflows) This workflow is great, because It will create new releases automatically for you: https://github.com/baumrock/RockMigrations/releases It will create new tags automatically for you: https://github.com/baumrock/RockMigrations/tags (This is something that I always forgot and someone was asking for it long time ago, because tags are important if someone uses composer to manage their modules, as far as I understood. Now I can't forget them any more ? ) It will create a changelog for you automatically: https://github.com/baumrock/RockMigrations/blob/main/CHANGELOG.md And last but not least: It will create version numbers automatically for you. One thing that has always been annoying though is that you have to make sure that the version number that is automatically created matches the version number that you set in your modules .module.php or .info.php file. I have always tended to have everything in my .module.php file, but I just recently noticed that this can lead to problems if you are using PHP8 syntax in your module and the website still runs on PHP version <8 --> You end up getting a fatal error whenever the module is loaded, which totally breaks ProcessWires module backend. The solution is easy though: Just split your module config into two files - the .module.php with all the module's logic and the .info.php file with only the array that defines the module's info array. Thx for that reminder @BitPoet! Here is the HelloWorld's info.php file with some helpful comments: https://github.com/ryancramerdesign/Helloworld/blob/master/Helloworld.info.php I did that today for RockMigrations and I realised that you can even fully automate the version numbering of your module, because the conventional commit workflow creates a package.json file that holds the version number in a json string: https://github.com/baumrock/RockMigrations/blob/main/package.json All you have to do is to grab that json string and write that version into your module's info.php file: https://github.com/baumrock/RockMigrations/blob/92a33ba4e7146a69fb1f52d5b67270b66d9f1e54/RockMigrations.info.php#L5-L9 Afraid of a performance penalty? You don't have to. The module's info is cached by PW and only updated on modules::refresh! Maybe other module authors like @adrian or @Robin S or @kongondo or @teppo or @netcarver or @Macrura or @flydev want to adopt that workflow as well. Thx for reading and have a great weekend ?

I've never worked with mysql spatial functions but I have a little background in GIS so I know things are usually a lot more complicated than you'd think before ? I've done a little research and found some helpful and interesting resources: Youtube video with a good overview over GIS and mysql: https://www.youtube.com/watch?v=6zJ0swD17ow A blog post how to find points contained in a polygon using mysql: https://marcgg.com/blog/2017/03/13/mysql-viewport-gis/ And a little more details about performance (link from article 2): https://www.percona.com/blog/new-gis-features-in-mysql-5-7/ I've done this mysql query on one of my VPSs (3vCPU, 4GB RAM) with - as far as I understand - 50k calculations and got a result in 3.7ms: MariaDB [(none)]> select benchmark(50000, st_distance_sphere(point(-78.7698947, 35.890334), point(-122.38657, 37.60954))); +--------------------------------------------------------------------------------------------------+ | benchmark(50000, st_distance_sphere(point(-78.7698947, 35.890334), point(-122.38657, 37.60954))) | +--------------------------------------------------------------------------------------------------+ | 0 | +--------------------------------------------------------------------------------------------------+ 1 row in set (0.037 sec) I might be wrong but I think that means that you can expect your calculations to be similarly fast. The same benchmark using 1 million instead of 50k tests took around 500ms. Maybe @Mats knows more? I think he also has a lot of experience with (web) maps?!

Spatial operations are not trivial and in general not supported by PW. The problem is that you can't do simply "greater than" or "less than" operations like you can do with simple number fields. I think you have two options: 1) Use mysql's spatial functions. That would mean you'd have to create a custom DB table and use spatial analysis functions: https://dev.mysql.com/doc/refman/5.7/en/spatial-analysis-functions.html 2) If you don't have too many pages you could also transfer an array of all coordinates of your pages to the client and then use a client-side libary to check which entries are within the polygon and which are outside. Then you could just add the ones within the polygon to the map. https://github.com/hayeswise/Leaflet.PointInPolygon

Hey @adrian I'm working on a PW site in a team and we have the problem that we need different "localRootPath" settings for different users. Is that already possible? The problem is not for local development - there we can have different config.php files. The problem is on the remote server (staging and production system). It would be nice to be able to click on tracy dumps there, but obviously there we only have one config for multiple developers. I tried this but it seems to have no affect. Maybe it's too late? But I can't set different paths in config.php as we don't know the user at that point: if($user->name == 'bernhard') { $tracy = $modules->get("TracyDebugger"); $tracy->set('localRootPath', '/foo/bar/baz/'); bd('test'); } Thx!

Thx @Rudy but the error comes from the first colon that comes from PHP8's named arguments Ah! Thx about that reminder. I got used to writing everything into the .module.php file as I saw no benefit in having a separate file, but that totally makes sense ? Thx!

The latest version of RockMigrations (and many other of my modules) require PHP8.0 as minimum version. PHP7.4 is end of life, so everybody should update anyhow. But I'd be interested if there is a better solution to the following problem: When on a PHP7.4 system and you install (or try to install) RockMigrations you'll end up with an error like this: The module has PHP>=8.0 in its requires array, but it can not check for that dependency because PHP complains before even executing the check. That means the modules backend is unusable until you remove the module manually and/or update your PHP version. Any ideas?

Hey Stefan thx for sharing! Your screenshots show me that we might need a feature to show available formattings in the field's notes? Or maybe that would be too much? It's actually not that easy to do if you want to support multilang setups for example...

Thx for the great writeup!! ? Also thx for the great feedback over the last few weeks! I've added a link to this tutorial to the wiki! ?

I agree it's not the best UX, but have a read here: https://processwire.com/talk/topic/14979-why-is-a-value-required-to-pre-check-checkboxes/?do=findComment&comment=134243 I think that makes sense and your Pages::added hook seems to be a good solution as it's the only other possible option that ryan mentioned. PS: If you are using custom page classes you can make it a MagicPage and then it's simply this: public function onCreate() { $this->youroptions = [1, 2]; }

Glad it helped. $page is not available OUTSIDE of your hook in init.php, but INSIDE the hook it is available since the inner part of the hook is executed at a different time (after/before Pages::saveReady or Pages::saved). In your hook you get the saved page from the first argument of your HookEvent. That's why you do $page = $event->arguments(0) See also https://processwire.com/talk/topic/18037-2-date-fields-how-to-ensure-the-second-date-is-higher/?do=findComment&comment=158164

I've had a look and found the issue: ready.php is never triggered on frontend editing. You can attach your hook in /site/init.php for example and then it should work. The hooks are the same as for regular page saves: You can hook into Pages::saveReady or Pages::saved for example.

This might also be a good read/watch for you https://processwire.com/talk/topic/18037-2-date-fields-how-to-ensure-the-second-date-is-higher/?do=findComment&comment=158164

This error means that you call ->saveField on "null". That means that $pages is "null" in your case. Why is it null? Because it's not defined in your hook. Inside the hook you don't have access to all the PW API variables (like $pages, $sanitizer, etc). There you either need to first make them available (like $pages = $this->wire->pages) or just use the object-syntax: $this->wire->pages->saveField(...) Of course as you mentioned $page->setAndSave(...) does also work (because $page is defined in your hook, so you can work with it). It depends a lot on your use case. You could also add a checkbox to your page and then hook into Pages::saveReady or Pages::saved - there is a small but important difference here: "saveReady" is triggered BEFORE the page is saved, "saved" is triggered AFTER. That means in a saveReady hook you can just set page properties (aka field values) without saving the page (because the page is saved afterwards). In a "saved" hook it's not enough to just change page properties, because the save has already happened so you just change the field values but don't save your changes. // ##### in a saveReady hook $page->foo = "My foo value"; // page save happens here // ##### in a saved hook // page save happened here $page->setAndSave('foo', 'My foo value'); In your case the example with a checkbox could look like this: <?php namespace ProcessWire; // site/ready.php $wire->addHookAfter("Pages::saveReady", function($event) { $page = $event->arguments(0); // only execute on yourtemplate pages if($page->template != 'yourtemplate') return; // checkbox not checked --> dont execute if(!$page->yourcheckbox) return; // checkbox is checked, send email $mail = new WireMail(); // ... $mail->send(); // reset the checkbox $page->yourcheckbox = false; // 0 would also work // page will be saved after this hook // here you could also change other field's values $page->otherfield = 'new value'; });

While @gunter's wording is maybe not the nicest (!, !!, !!!) I understand and also think that having markup regions in the blank profile is not a good idea. For someone not familiar with markup regions (or PW in general) that's an additional step to take and an additional thing to understand. It might be obvious for us, but I doubt it's obvious for many newcomers. I've realised that when working on the video about RockFrontend (https://youtu.be/7CoIj--u4ps?t=78). I'd much more prefer if the blank profile would really be a blank profile. Without markup regions. Just plain PHP. With all the tools waiting for you if you want them, but not forcing you to use them in the beginning. You can read about the background here: https://processwire.com/blog/posts/starting-with-the-blank-profile/

@Sonia Margollé have you seen RockFrontend? It's zero-setup and comes with livereloading both in the backend and frontend. There's also a tailwind starter profile for it. If you find there's something missing let me know and I can see if we can add it.

While I don't see any problems in making it work as you expect here is a quick and easy workaround: $wire->page = $pages->get(1); $page->trash(); $session->redirect(...);

It might be too late but this would work: $array = $pages->findRaw("id>0,limit=3", "title, created"); db($array, 'array'); $wire->cache->save('test', $array); db($wire->cache->get('test'), 'cache');

Thx @ryan again for the updates - we finally have translatable strings in LATTE files ? This is what you have to do: https://processwire.com/talk/topic/28202-rockfrontend-now-supports-translations-in-latte-files-?/ Are you talking about smarty files in RockFrontend or in general? This is how I'm doing it for latte files: https://github.com/baumrock/RockFrontend/blob/main/translate.php --> these functions are injected before any latte file get's rendered so that they are available to the compiled php file that latte creates. I don't know how smarty works (I've been using it in 2003, but I guess some things have changed since then and my memory is not the freshest any more ? ), but if you are talking about smarty in RockFrontend I'm happy to assist you to bring support for it into the module ?