bernhard

Thx @Stefanowitsch fixed in v2.31.2 ?

@Stefanowitsch thx for the report. Could you please provide a step by step instruction what you did so that I can try to reproduce the issue?

Hi @maetmar thx for spotting! Please check v2.31.1 ?

Hey Adrian I get this error on the latest version. Thx in advance ? ErrorException: Undefined variable $toMethodName in /var/www/html/site/assets/cache/FileCompiler/site/modules/TracyDebugger/panels/DebugModePanel.php:216Stack trace:#0 /var/www/html/site/assets/cache/FileCompiler/site/modules/TracyDebugger/panels/DebugModePanel.php(216): Tracy\Bar->Tracy\{closure}(2, 'Undefined varia...', '/var/www/html/s...', 216)#1 /var/www/html/site/assets/cache/FileCompiler/site/modules/TracyDebugger/tracy-2.9.x/src/Tracy/Bar/Bar.php(145): DebugModePanel->getPanel()#2 /var/www/html/site/assets/cache/FileCompiler/site/modules/TracyDebugger/tracy-2.9.x/src/Tracy/Bar/Bar.php(117): Tracy\Bar->renderPanels('')#3 /var/www/html/site/assets/cache/FileCompiler/site/modules/TracyDebugger/tracy-2.9.x/src/Tracy/Bar/Bar.php(91): Tracy\Bar->renderPartial('main')#4 /var/www/html/site/modules/TracyDebugger/tracy-2.9.x/src/Tracy/Debugger/DevelopmentStrategy.php(139): Tracy\Bar->render(Object(Tracy\DeferredContent))#5 /var/www/html/site/assets/cache/FileCompiler/site/modules/TracyDebugger/tracy-2.9.x/src/Tracy/Debugger/Debugger.php(321): Tracy\DevelopmentStrategy->renderBar()#6 [internal function]: Tracy\Debugger::shutdownHandler()#7 {main}

Thx for the feedback @wbmnfktr I'm a little confused - are we talking about RockMigrations or RockFrontend? Or both? I know that the docs can be improved in most of the modules. The problem is that it's really not an easy task for me. Any help like this great post by @Stefanowitsch is very welcome. The problem that I have with the github readme is that it get's too long for modules like RF and RM. That's why I started using github wikis - but I'm not really happy with them. They are not part of the version controlled files and so they are not connected with specific releases of the module. But I already have a plan to improve that ? Maybe you can share your experience a little more detailed? What is your goal? Why do the modules look interesting? What parts do you want to use? How did you try that? Where exactly did you fail?

FYI RockMigrations has a nice helper for using xdebug on ddev:

Yeah just my RockMigrations checkbox is only for VSCode. But if you tell me what is necessary for PHPStorm I can maybe add that as well?

Very interesting: Mapping Heritage: Geospatial Online Databases of Historic Roads. The Case of the N-340 Roadway Corridor on the Spanish Mediterranean https://www.mdpi.com/2220-9964/7/4/134/htm

Thx again for the great post! Just realised that you are using old-school paths, this would also work (I call it smart paths): <?php $rockfrontend->styles() ->add('styles/less/uikit/_custom-import.less') // add single LESS or CSS file ->addAll('styles/less/project') // point to folder to include files automatically ->addAll('styles/less/custom') // or this would also work (even if pw lives in a sub-folder!) $rockfrontend->styles() ->add('/site/templates/styles/less/uikit/_custom-import.less') // add single LESS or CSS file ->addAll('/site/templates/styles/less/project') // point to folder to include files automatically ->addAll('/site/templates/styles/less/custom')

v3.16.0 adds an xDebug launch.json file to the .vscode folder and a checkbox to control whether you want to use that feature or not. That means if you are using DDEV all you need to do to is to check the checkbox and then run "ddev xdebug on" Thx @dotnetic for the hint about xDebug on DDEV! I've just tried it today and it works great! compared to my last experience with xdebug on laragon where performance was really bad the performance on my ddev container is so good that I even forgot to turn it off today ? Page load times without xdebug: 100ms; with xdebug: 150ms ? And all that with zero-config!!! You have to try it ? See here how to use xdebug in vscode: https://www.youtube.com/watch?v=HrQWtbxY1Hs&t=331s

I haven't read everything carefully and I have never used the feature myself, but TracyDebugger has a feature to render different template files with a customizable suffix. Here is how adrian implemented it: https://github.com/adrianbj/TracyDebugger/blob/f2fbcd88fcecad45b2ce7b428cfe80c1527c1122/TracyDebugger.module.php#L1481-L1494

I've created a new thread for that topic:

I'm creating a new topic in response to @cst989's question in the RM thread as I think this is a common question and misunderstanding when evaluating RockMigrations. It's also easier to communicate in separate threads than in one huge multi-page-thread... Hi @cst989 thx for your question and interest in RockMigrations. This sounds like you have a misconception in your head which is quite common I guess. Did you watch my latest video on RM, especially this part? https://www.youtube.com/watch?v=o6O859d3cFA&t=576s So why do you think it is a good thing to have one file per migration? I know that this is the way migrations usually work. But I don't think that this is the best way to do it. I'm not saying one way is right and the other is not. I'm just saying I'm having a really, really good time with RockMigrations and it makes working with PW in a more professional setup (meaning either working in a team and/or deploying PW to multiple locations and of course managing everything with GIT) a lot more fun an a lot faster and more efficient. If we look at how migrations usually work we can have a look at the other PW migrations module, which works just like usual migration modules work: You create one file per migration and you end up with a list of migrations that get executed one after another. See this screenshot from the modue's docs: In my opinion that screenshot perfectly shows one huge disadvantage of that approach: You don't see what's going on. You end up with a huge list of migrations that you can't understand on first sight. In RockMigrations this is totally different. You don't create one file per migration. You put all the necessary migrations where they belong and - in my opinion - make the most sense. An example: Let's say we want to add 2 fields to the homepage: "foo" and "bar". Ideally you are already using Custom Page Classes (see my video here https://www.youtube.com/watch?v=D651-w95M0A). They are not only a good idea for organizing your hooks but also your migrations! Just like adding all your HomePage-related hooks into the HomePage pageclass init() or ready() method, you'd add the migrations for your 3 fields into the HomePage pageclasses migrate() method. This could look something like this: Now let's say we develop things further and realise we also need a "bar" field: Do so see what we changed? I guess yes ? Now one big difference to a regular migration approach is that you don't write downgrade() or reversion migrations - unless you don't want to revert the changes! In real life I've almost never ever needed to revert changes. Why? Because you develop things locally and only push changes you really want to have on your production system. If you happen to have to remove some changes that you applied on your dev it's easy to do, though: You see what we did? Nice! So does everybody else that has access to the project's GIT repo! So all your team mates will instantly see and understand what you did. Pro-tip: You don't even need lies 43-45 if you didn't push those changes to production! If you only created those fields on your local dev you can simply restore the staging database on your local dev environment and remove the migrations that create the fields. Pro-tip 2: Also have a look at RockShell, then restoring staging or production data is as easy as "php rockshell db-pull staging" Pro-tip 3: When restoring a DB dump from the staging system it can easily happen that you have data in your database that was created only on the remote and you don't have on your dev system (like new blog posts for example). If you then open those new blog posts on your dev system processwire and the blog post contains images processwire will not be able to show those images (as only the file path is stored in the DB and not the whole image!). Just add $config->filesOnDemand = "http://yourstagingsite.example.com" to your config.php file and RockMigrations will download those files once PW requests the file (either on the frontend or also on the backend)! Having all your changes now in your git history you can even jump back and forth in time with your IDE: You could. I thought about that as well. But I think it does not really make sense and I hope my examples above show why. I'm always open to input though and happy to try to think about it from other perspectives. One final note: I'm not sure if what you say about $rm->watch() makes sense here. If you watch() a file that means that RM checks it's modified timestamp. If that timestamp is later than the last migration that RM ran, then RM will automatically execute the migrations that are in that file. All other files and migrations will be ignored. That makes it a lot more efficient when working on projects that have many migration files in many different places. When triggered from the CLI though or if you do a modules refresh then it will always trigger all migrations in all watched files. I hope that makes sense! --- Ok, now really a final note ? One HUGE benefit of how RockMigrations works (meaning that you write migrations in page classes or in modules) is that you create reusable pieces of work/code. For example let's say you work on a website that needs a blog. So you create a blog module and in that module you have some migrations like this: <?php $rm->createTemplate('blogparent'); $rm->createTemplate('blogitem'); $rm->setParentChild('blogparent', 'blogitem'); $rm->migrate([ 'fields' => [...], // create fields headline, date, body 'templates' => [...], // add those fields to the blogitem template ]); You'd typically have those lines in Blog.module.php::migrate() What if you need a blog in another project? Yep --> just git clone that module into the new project and execute migrations! For example in migrate.php this: <?php $rm->installModule('Blog'); If you follow a regular migrations concept where all project-migrations are stored in a central folder you can't do that! Of course you don't have to work like this. You can still write all your migrations in the project's migrate.php file. Because I have to admit that it is a lot harder to build a blog module that can be reused across different projects than just creating one for one single project! It always depends on the situation. But - and now I'll really leave it for today ? - you could also make your Blog-Module's migrate() method hookable and that would make it possible that you build a generic blog for all projects and then you add field "foo" to your blog in project-a and you add field "bar" to your blog of project-b. Have fun discovering RockMigrations. I understand it can look frightening at first, but it is an extremely rewarding investment! Ask @dotnetic if you don't believe me ?

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!