bernhard

class Webhooks extends WireData { I guess WireData does not support hooks whereas Wire does.

TracyDebugger d($pages->find("template=foo, include=all")); d($pages->find("title%=foo, include=all")); // with one of the old titles that are now gone in case the template changed

Just tried and it works just as you expected it to work: That's why I was asking what the process() does exactly (code!). <?php namespace RockSearch; use ProcessWire\Wire; class Matcher extends Wire { public function ___foo() { return 'foo'; }

@Robin S I voted for that in 2016... Why did that take so long? ? Just kidding ? Thank you for creating this and sharing it with us! ?

Everybody please take this pandemic really seriously!! Panic does not help for sure, but ignorance or underestimating this situation will cost the life of thousands of people all over the world! As the following chart shows, the mortality highly depends on the amount of people that are in need of medical care at one time! Taken from link 2, see below. I have underestimated it myself just like almost anybody in europe has, as nobody of us here has ever experienced a situation like this before (in contrast to asia). Here are two links that I encourage everybody to read, even if you live in an area that has not (yet) been affected: 1) https://www.washingtonpost.com/graphics/2020/world/corona-simulator/?fbclid=IwAR0ABgvQGxm005seLywxDkZScKImi53Du9lzAlMwrDH6qsaaefW-Oux-Gao They have great simulations of how such an exponential growth can/will happen and what every single person can do against it! 2) https://medium.com/@holger.heinze_81247/coronacodex-my-commitment-during-the-covid-19-pandemic-76613656dac0 I hope that was not offending the forum rules that don't want political discussion... I work 100% remote now and I encourage everybody to do the same if at all possible. Not because I'm afraid (luckily I'm not at high risk as I'm young and healthy), but to take responsibility for all the people around me and keep the number of people needing medical care as low as possible so that the staff in the hospitals does not have to decide which patient (with severe symptoms) is treated and which is not (and will likely die).

Hey @Gadgetto did you find a solution for your problem? What does that do? I'm still not sure I understand the problem completely and the best solution in more complex setup always depends on the situation, but maybe you could make a proxy method in your main module that is hookable instead of making all methods in the helper module hookable? Some untested pseudo-code: // main module SnipWire public function webhooks(...$args) { $helper = $this->get('webhooks_endpoint') if($args['foo']) return $helper->foo(...$args); // returns "foo" if($args['bar']) return $helper->bar(...$args); // returns "bar" ... } // site/ready.php $wire->addHookAfter("SnipWire::webhooks", function($event) { $name = $event->arguments('name'); if($name != "foo") return; $event->return .= " hooked"; } // then the foo webhook should return "foo hooked" instead of "foo"

Hi @teppo yeah, that would be awesome! Carbon has a great translation tool: https://carbon.nesbot.com/contribute/translate/ I've recently suggested an improvement for de_AT and it's already in the package, available for everybody. I just opened a new ticket right now - see here how this looks like: https://github.com/briannesbitt/Carbon/issues/2036

That's why I shared my idea about a module that handles this... @LostKobrakai has even submitted a PR and nothing happened. I don't see any real drawbacks of packing such a feature into a 3rd party module. If one wants to ship a module with translations everybody can do so. If not - no harm, as everybody can still translate everything like before. Having translation files in the modules folder does not only have the benefit that others don't need to translate the module (or copy over files) it does also make it easy to handle translations in a proper place for the module author and make changes to the translation across multiple installations instantly and easily (git push).

I guess that's a unique hash that represents the translated string (including options)

Thx @dragan that are really some old threads! ? That doesn't make me feel very confident that such a feature finds its way into the core soon. I could also think of a module that copies over translation files from modules folders to the assets folder of the language. The translation module could also lock the translation screen of the json file to prevent unwanted overwrites (or show a warning). And the module could make the necessary links between the sites language names and the standardized translation directories in the module, eg a site having language "german" could link to the module's translation folder DE. On another site the superuser could make the link deutsch-->DE instead of german-->DE We could also ship some common translations directly in that module (eg for ListerPro)...

I wonder what is currently the best way to ship a module that defaults to english let's say with german translations? I think the translation files have to be uploaded to the relevant language page (eg german) and are then stored in /site/asstes/files/my-german-page-id/... What if I want to ship a module with translation files included? That's currently not possible, is it? I wonder if the PW core should be modified to not only look for translations in /site/assets/files/german-id/my-module-transation-file.json but also in /site/modules/my-module/translations/german/my-module.module.php.json What do you think? Am I missing anything?

Hi @ryan another tedious task came up today where this could be helpful! This is what I'd wish we had in the API: $files->path("mytheme/foo/bar.php", $config->paths->templates); This could make sure to return the full disc path to the given file relative to the templates folder. In the example it looks as if that could easily done like this: $path = $config->paths->templates . "mytheme/foo/bar.php"; But unfortunately things are not always that easy! What if the file was already a path? What about trimming slashes? What about normalization? ... $file = "/var/www/site/templates/mytheme/foo/bar.php"; $path = $config->paths->templates . $file; // fails! Would be great to get these little helpers soon ?

Hi @Jofra, welcome to the forum. Did you already read the getting started docs? https://processwire.com/docs/start/ Or do you have any specific questions?

Hey @tpr found this little glitch on mobile: AOS sets display: none !important for all icons in the pagelist on small screens. This also hides the show more icon of pagelistactions:

v0.0.4 adds support for LESS variables set via $config->lessVars

@adrian could you please add the name of the field in the admin actions panel so that it is more obvious and secure? Here I'm deleting the field "summary" but it looks more like I am deleting the field "Text". A simple "Delete field > summary < " would do. I think it's a little dangerous as it is now - it's common to have many tabs open at the same time, so there's a high risk of clicking that button in the wrong tab accidentally. Thank you ?

Memo to myself and mybe to safe someone else from losing hours trying to understand why a multi-language Inputfield does not render() as expected... Learnings: 1) Inputfield::render() is only hookable for single-language Inputfields! When PW renders a multi-language Inputfield the LanguageSupport module adds a hook that fires after the original Inputfield::render(). This hook calls the render() method for each language and to avoid circular references it does that directly on $inputfield->___render() and not $inputfield->render(): https://github.com/processwire/processwire/blob/51629cdd5f381d3881133baf83e1bd2d9306f867/wire/modules/LanguageSupport/LanguageSupport.module#L445-L453 2) When building a custom Inputfield that supports a multi-language setup it is critical that its render() method is defined with 3 underscores! Otherwise the LanguageSupport hook that adds the markup for the other languages' fields would not fire.

Thank you @ryan this is an awesome update! Really looking forward to replacing lots of hook-chaos by well organized and easy to maintain PageClasses ? ? So far, so ??? BUT: I've put together this quick testing module: <?php namespace ProcessWire; /** * Custom page classes for ProcessWire * * @author Bernhard Baumrock, 07.03.2020 * @license Licensed under MIT * @link https://www.baumrock.com */ class RockPageClasses extends WireData implements Module { public static function getModuleInfo() { return [ 'title' => 'RockPageClasses', 'version' => '0.0.1', 'summary' => 'Custom page classes for ProcessWire', 'autoload' => true, 'singular' => true, 'icon' => 'bolt', 'requires' => [ 'ProcessWire>=3.0.152', // custom page classes update ], 'installs' => [], ]; } public function init() { $this->classLoader->addSuffix('Page', __DIR__ . '/PageClasses/'); $file = $this->classLoader->findClassFile("HomePage"); bd($file); } } Now I deleted the file in /site/classes/HomePage.php and added it to /site/modules/RockPageClasses/PageClasses/HomePage.php and this is the result: Strangely, the file is found but not loaded for the HOME template! Any ideas? I think 95% of my custom classes will live in a folder inside /site/modules ? PS: This is the HomePage class:

Just had to look something up in the Tracy Docs and found their donation button ? So if anybody wants to thank the guys behind Tracy, here's the link: https://nette.org/en/make-donation?to=tracy Can't thank you enough (Adrian and the guys from Nette) for this awesome tool!

Anybody ever had horizontal scrollbars in the PW admin? It's a known issue and I've just pushed a fix for it to the PwQuickFixes module: https://github.com/BernhardBaumrock/PwQuickFixes/commit/4db6b4659692e3888a20ea89752fdce40d4425fe Before: After:

Just wanted to share another use case for $files->url() and $files->path() // old version function mirrorFilesfromLiveServer(HookEvent $event) { $config = $this->wire('config'); $file = $event->return; if ($event->method == 'url') { // convert url to disk path $file = $config->paths->root . substr($file, strlen($config->urls->root)); } if(!is_file($file)) return; This example is taken from this recent post by @gebeer and it would be a lot better to read and maintain with the new methods: // new version function mirrorFilesfromLiveServer(HookEvent $event) { $file = $this->wire('files')->path($event->return); if(!is_file($file) return; In the old version he gets the filename from the $event. He then has to check for the $event->method, because in one case the file is a PATH and in the other it is a URL. That's why he has to modify $file if the method is "url"... And then he does what many of us do in such situations: Use string operations. They are not only ugly but also error prone: Think of different directory separators, missing or doubled slashes (eg /foo/bar//myfile.js or /foo/barmyfile.js). This was all not necessary if we had $files->path() and $files->url() ? See the second example. In one single $files->path() call all the complicated code from example 1 is obsolete. $files->path() returns the path of the file, no matter if it was provided as url or path. So simple, so beautiful.

@porl could you please try if the fork linked above resolves your problem? It has a very active commit log and 72 contributors so that should be a solid choice.

Hi @ryan thank you very much - that will be a tiny but very helpful addition! ? You might be right about it belonging to files instead of config - I really don't care about that. One thing that might be helpful would be a second parameter wheter it should return a trailing slash or not: $less = __DIR__ . "/my/great/file.less"; if(is_file($less)) echo $files->url($less); // /site/templates/my/great/file.less $dir = __DIR__ . "/blocks"; // see comment 2 $blocks = ['file1.php', 'file2.php', 'file3.php']; foreach($blocks as $block) { $file = $files->path($dir, true).$block; // see comment 1 if(!is_file($file)) continue; echo "<link rel='stylesheet' href='{$files->url($file)}'>"; } // comment 1 // see how that is better compared to something like this: $file = "$dir/$block"; // this could fail when $dir is dynamic (eg user input from module config) $file = rtrim($dir, "/")."/".$block; // better, but tedious // and finally, what if somebody used DIRECTORY_SEPARATOR --> it could fail on windows because of the backslash Comment 2: This could also be a relative path, eg $dir = "blocks" (being the blocks folder of the current module). Checking for is_file() can then become tedious as you might have to add $config->paths->whatsoever. $files->path($dir, true) would make sure to return the path with a trailing slash. Or maybe it would be better if the trailing slash was returned by default? I'd really vote for $files->url(...) and $files->path(...) instead of diskPathToUrl/urlToDiskPath; I know one should not be too short in variable/method names, but we already have the equivalents $config->paths and $config->urls that do the same, so I think this would be perfectly reasonable. ? And yes, I think you are right about it being a file tool, therefore we'd better use $files->url(...) instead of $config->url(...) ? Really looking forward to that, thank you again! ---------- Regarding my datetime request: Please disregard this one. First, I didn't know about the WireDateTime at all (Sorry!) and second, the reason why I didn't like PHP's features was that it doesn't provide a nice and easy to understand API. But that's solved when using carbon and that can perfectly be built into a 3rd party module (not bloating the core).

@Gadgetto has fixed it - it also works for me now ? Thx @Jens Martsch - dotnetic

Hi @porl sorry for the delay! It's this one: https://github.com/oyejorge/less.php I see that the repository is archived/read-only. Maybe you want to fork it and I can include the fixed version? Or we can take one of the 186 available forks ? https://github.com/oyejorge/less.php/network/members; maybe https://github.com/wikimedia/less.php ?