Leaderboard

That is a good concern ?

Hello @Martinus, maybe findRaw() could simplify your solution: $a = $pages->findRaw("parent=/products/, seller=amazon, rating>0", "rating"); print_r ($a); // check array echo array_sum($a); // sum of all values in array Regards, Andreas

WOW! Thank you so much for taking the time and putting that effort together! That did the job perfect. $wire->addHookBefore("Pages::saveReady(template=guest)", function($event) { $page = $event->arguments(0); $pages = $event->object; // Set the title $page->title = "{$page->firstname} {$page->lastname}"; // Sanitize the title as a page name $name = $event->wire()->sanitizer->pageName($page->title, true); // Set the page name while making sure it auto-increments if there is a sibling page with the same title $page->name = $pages->names()->uniquePageName($name, $page); }); My only concern is if I put it in the /site/ready.php and have some more stuff like that things get messy, but for now it is perfect.

Hello, In sort, you can do something like this in a saveReady hook: if($page->template == 'yourtemplate') {... It is also possible to use a "shortcut", like this: $wire->addHookBefore("Pages::saveReady(template=yourtemplate)", function($event) {... https://processwire.com/docs/modules/hooks/ Quote: Some hookable methods in ProcessWire have no implementation and exist purely for you to hook. Because hooks like this exist purely "to be hooked", it doesn't matter if you hook before or after them. Examples include Pages::saveReady which is called after it's been determined the page will definitely be saved, but right before it is done. Another is Pages::saved, which is called after a page has successfully been saved. These hooks provide more certainty and less need for error checking than hooking before or after Pages::save. You may see several other specific-purpose hooks like this in ProcessWire. Ryan in a pro module support thread provided this general example for repeaters, for example: Quote: A Pages::saveReady hook is your best bet for populating the value of some field on a page before it is saved. If you wanted to populate some page reference field on a repeater item when it is saved, you could do so like this in your /site/ready.php file. In my example below, I'm populating some_page_field with the page that owns the repeater item, since I think this is what you were trying to do (?). You'd want to update the first 2 lines to reflect your actual repeater template name and page reference field name. $pages->addHookBefore('Pages::saveReady', function(HookEvent $event) { $templateName = 'repeater_template'; $fieldName = 'some_page_field'; $page = $event->arguments(0); if($page->template == $templateName && $page instanceof RepeaterPage) { $ownerPage = $page->getForPage(); $page->set($fieldName, $ownerPage); } }); More examples: https://processwire.com/talk/topic/26897-add-new-set-title-of-new-page-with-a-select-field-combination-pagereference/?do=findComment&comment=222469 Modifying field values is easy, but if you need to do it based on the values of other fields then things might get "tricky" sometimes, depending on the types of those fields.

Post from 2011 and still valid... how crazy/great is that?!

I’ll look into it when I get a moment. Manual install seems ok.

Hi @bernhard. Just tried a different module (AppAPI) which is OK. The problem appears to be with your modules. I tried RockMigrations too - on v3.0.200 - both RockMigrations and RockCalculator give this error: ProcessWire: ProcessModule: No page specified

Hey @kaz, in /site/modules/FieldtypeLeafletMapMarker/InputfieldLeafletMapMarker.module try changing line 193 f. if( ((string) round($lat, $precision)) != ((string) round($this->defaultLat, $precision)) || ((string) round($lng, $precision)) != ((string) round($this->defaultLng, $precision))) { to if( ((string) round(floatval($lat), $precision)) != ((string) round(floatval($this->defaultLat), $precision)) || ((string) round(floatval($lng), $precision)) != ((string) round(floatval($this->defaultLng), $precision))) { that's hotfixing the issue over here. Don't know about the rest of the module, but I haven't gotten other errors so far.

I think you just need to set the property "rockcalculator" of your field (not inputfield!) before it is rendered. That should be possible from your code without any hooks. Maybe like this? <?php $f = $this->modules->get("InputfieldText"); if(wire()->modules->isInstalled('RockCalculator')) { // set the rockcalculator here // $f->attr("data-rockcalculator", 6); //6 digit precision $f->notes = __("Numeric or math formula"); $f->hasField->rockcalculator = true; } else { $f->notes = __("Numeric"); $f->precision = 6; $f->attr('type', "number"); $f->attr('step', "any"); }

This looks a handy little module. I'm hoping to add it as an enhancement to my FieldtypeMeasurement module, which it would complement very nicely. However, I'm scratching my head a bit as to the best way of incorporating it as I really need to embed it within my Inputfield::render() method - i.e. after the hook in your module has fired (?), but I think that's too late. The problem is that my field is an object. The magnitude property (which is where I'd like the calculator) is rendered as a text inputfield. So what I was hoping to do was something like this (where $f will be the inputfield for the magnitude): $f = $this->modules->get("InputfieldText"); if(wire()->modules->isInstalled('RockCalculator')) { // set the rockcalculator here // $f->attr("data-rockcalculator", 6); //6 digit precision $f->notes = __("Numeric or math formula"); } else { $f->notes = __("Numeric"); $f->precision = 6; $f->attr('type', "number"); $f->attr('step', "any"); } However, that doesn't work because the assets aren't loaded. It works OK if I remove the line if(!$this->isEnabled($inputfield)) return; from loadAssets(), but obviously if the module is used elsewhere in the site, that is not a great idea and isEnabled() is not hookable. I could just load the assets separately, I guess. Any suggestions@bernhard

In ProcessWire everything is a page. There is no separation between pages and posts like in WordPress. So yes, the solutions in this thread should work too. ?

Hi @AndZyk, Your code is what I needed. More small and easier to read. Thank you so much ?

Hy berhard, thank you very much for the video! It‘s awsome how quick everybody is here ? And you gave lot‘s of other useful information and put everything together in a very good way, good job! Danke dir vielmals ?

Hi, you could use PageSum for simplicity. Just install the module and then for example: $selector = "parent=/products/, seller=$item"; // your selector $cnt = $pages->count($selector); // number of pages that match $selector if(!$cnt) echo 'No rated product found'; $sum = $pages->sum($selector, "rating"); // get sum of all matched products from "rating" field with "PageSum" $avg = $sum / $cnt; // math echo "Average rating of {$item->title} product (x$cnt) is ". number_format($avg, 2); // format number as needed

RockFrontend got some really cool updates over the last days thx to some inputs from @gebeer! The latest additions improve SVG rendering and finally I found a way to get rid of the need to add |noescape to every alfred() call in latte files ?? SVGs You can use the render() method to write SVG markup directly to your template file: // latte // icon is in /site/templates/img/icon.svg {$rockfrontend->render('img/icon.svg')} // php echo $rockfrontend->render('img/icon.svg'); You can even provide variables to replace, so you can create completely dynamic SVGs with custom rotation angles or colors etc... {$rockfrontend->render('img/triangle.svg', [ // replace the {rotate} tag in the svg markup 'rotate'=>45, 'color'=>'blue', ])} // add the replacement tag to your svg file // img/triangle.svg <svg style="transform: rotate({rotate}deg); border: 2px solid {color};">... PS: You can also use $rockfrontend->svg('img/triangle.svg') if you want ?

Understood now. Thanks.

A quick update... Version 1.2.5 allows you to deactivate url hooks and fallback into the legacy ProcessPageView::pageNotFound behavior. That's now possible in the module config. I discovered, embarrassingly just after the release of the new version 1.2.4, a case where switching to the URL hook actually causes a breaking change. In all tests before this was not noticed, so sorry if anyone discovered something similar. Now, in any case, it is easy to switch back to the old hook. Now to the problem: Maybe someone reading this has some deeper insight and can help me to understand the issue. I have a page on which I have included @Wanze`s SeoMaestro field and wanted to read the values from it via Api: <?php $page = wire('pages')->get('/'); if ($page->template->hasField('seo')) { $seoString = @$page->seo->render(); } That actually works fine when it's done in an ProcessPageView::pageNotFound hook. But if I use a url hook and call it, the seo->render() call will throw the following error: { "error": "Method Page::localUrl does not exist or is not callable in this context", "devmessage": { "class": "ProcessWire\\WireException", "code": 0, "message": "Method Page::localUrl does not exist or is not callable in this context", "location": "\/processwire\/wire\/core\/Wire.php", "line": 564 } } I've managed to step through the code and find out the source of the exception. It's a call of page->localUrl in SeoMaestro's PageFieldValue class: https://github.com/wanze/SeoMaestro/blob/master/src/PageFieldValue.php#L158 Any ideas? ?

I'm not using yaml at all. That was just a quick test because many were asking for it. I'm still not convinced. For the same reasons as why I'm not convinced with your approach (at least how I'm understanding it). I guess the reason why our files are similar is no surprise, because our modules describe what PW has to do and of course the data structure of PW is the same for your module and mine. https://processwire.com/talk/topic/26635-add-better-configuration-for-fields-and-templates-and-make-them-version-controllable/?do=findComment&comment=220791 The point here is: I know that when it comes to migrations the "standard" way of doing it is to provide an upgrade() and a downgrade() code. I've started that way too (back in Jan/2019 https://github.com/BernhardBaumrock/RockMigrations/blob/a2b90ba4fc1aa2b4a6c4e1dc976ca644ae492888/.RockMigrationsDemoModule/RockMigrations/0.0.1.php ) Since then it turned out that writing downgrade methods is just a waste of time. I've never - really: never - had the need for a downgrade since then. Usually when developing and when reverting thins a simple db-pull from the staging system is enough and all the changes are gone. No need for a downgrade. If changes have already been pushed to staging/production then of course this method does not work. But the link above shows how easy it is to solve, eg by simply adding this to my migration: $rm->deleteField('my-old-field-that-is-not-needed-any-more') Some may call it an antipattern - but ProcessWire as a whole is a single antipattern and I really like that ? https://processwire.com/talk/topic/26635-add-better-configuration-for-fields-and-templates-and-make-them-version-controllable/?do=findComment&comment=220829 It's not really about liking it or not. It's just not usable for me. Why? It's simple. I like to do things in a modular, reusable way. Without any user input (beside maybe clicking an install button). I like to build modules that can be installed on many websites. And I like to deploy my websites on staging and on production automatically. Or to push changes to a project where another developer just has to do git pull and it will work. How would your module/approach do that? In case you hadn't realised, there is extensive documentation of the module at https://metatunes.github.io/DbMigrate/help.html. So you don't need to install and use the module to get an understanding of what it does. Specifically as regards running code on migrations, see the following sections: https://metatunes.github.io/DbMigrate/help.html#snippets and https://metatunes.github.io/DbMigrate/help.html#hooks. I was confused because you wrote a specific question in my module's thread that I tried to understand, that's why I was asking for a more detailed explanation. All I got was a RTFM-like answer. But you were right, I did not know about your docs. Looks like you have put a lot of effort into them. Still I don't get how you are actually working with the module. And that was what I was asking for. To understand and maybe find a way to get the best of both worlds. If you want to add some kind of yaml recorder or migrations GUI into RockMigrations I'm happy to pull that or to assist where I can. I'm just not adding it myself unless someone pays me to do it. Simply because I'm at the moment 90% sure that such a tool will not work for me and therefore I don't need it. But the "migrations code" inspector field is a feature coming from a push by the community, so maybe there'll be other useful things along the way as well.

With AppApi's new version 1.2.4 we now use URL Path Hooks! The old ProcessPageView::pageNotFound hook still remains, but is only used as a fallback if the ProcessWire version does not support the url path hooks. Thanks to @kongondo and @adrian who kept pushing me in the direction of including url path hooks! I also revised the logging a little bit. In the access log (which can be activated via the module settings) the correct paths from the request are now entered. And an entry in the access log really only occurs if no error has occurred. Otherwise an entry is triggered in the appapi-exceptions log. You can download the new version now in the ProcessWire modules page, Github or via auto-update in your ProcessWire UI. Thanks for using AppApi! ?

Hey, it seems to me that there is a wrong thinking or understanding to the whole subject that leads to the confusion. (?) If your comparison are between the compressed image from a third party tool, e.g. photoshop or others, and ONLY the webP output from GD or imagick, then this is comparing apples with bananas. If that's the fact, please read on. If that's not true, please excuse my post and my misunderstanding and forget / don't read the rest of the post. ? EDIT: maybe of additional interest:

I've created a PR for the documentation to prevent further confusions: https://github.com/processwire/processwire/pull/177 ?

How about this: <?php $p = $pages->findOne(1241); if ($p->id) : ?> <a href="<?php echo $p->url() ?>"><?php echo $p->title() ?></a> <?php endif; ?> Perhaps it's only a minor optimization, but it saves it returning any page object if the page isn't published. Be sure to read the docs on findOne() vs get() to understand fully, but basically find() and findOne() won't return unpublished pages unless to specifically request them to, but get() will ignore unpublished and hidden statuses and always return a page if everything else matches.