Leaderboard

We have a hook for that by now: https://processwire.com/api/ref/pages/published/ <?php $wire->addHookAfter("Pages::published(template=yourpagetemplate)", function(HookEvent $event) { $page = $event->arguments(0); $mail = new WireMail(); $mail->subject("Page {$page->title} has been published..."); ... $mail->send(); }); Not sure if that is really what you want though... Maybe you want to send an email when the page is created? Then Pages::added is for you: https://processwire.com/api/ref/pages/added/

@psyThat's exactly what I was looking for...a way to make sure the entities are eager loaded. Just didn't know it was a thing and what it was called :) Well, turns out that when I tried to use "join"...it didn't work because my processwire wasn't on a recent enough version. So when I upgraded to latest master version...it works! And furthermore...it works WITHOUT using the join feature as well. Just needed to upgrade...must have been a bug somewhere that got fixed in the past year. Thank you everyone!

Just a thought... maybe change it to findJoin and add the task.tast_status field to ensure it's included in the query? https://processwire.com/api/ref/pages/find-join/

Hi @Crowdland Technology There has been a lot of changes in 3.0.185 that relative to ML support and other part of request handling so it's better to stay for some time on the stable 3.0.184. There is already an opened issue https://github.com/processwire/processwire-issues/issues/1447 So you can describe your case there

My question relates to one of my live sites. I empirically managed to solve my login issue of "This request was aborted because it appears to be forged" [details below], but I don't understand the inner workings of PW, so I don't understand the theory behind why/how I fixed it, and thus, I don't know if I've managed to inadvertently introduce a security issue/loophole. Would anyone please be willing to let me know if my change, moving forward, is likely to cause any such issues? I don't have any reason to believe I *do* have a security issue (I made my change only an hour ago) but I am hoping other users can weigh in on this. DETAILS: The problem: Yesterday I updated 2 of my sites from 3.0.165 to 3.0.184 from within PW admin page, using the upgrade module - this is the way I've always done it. Immediately afterword, both sites appeared to be working fine from front-end and admin, and I even wrote and saved an (unpublished) article in what would become the problem site, then I logged out. Unfortunately, this morning, although both sites were fine from front-end, I could not log into the admin area of the problem site, getting "This request was aborted because it appears to be forged". The other site was fine and I could log into that. The solution: Since both my sites were on the same web host and had a lot of similarities, this was actually incredibly helpful as it let me narrow down where the issue might be. I won't go into everything that *didn't* work (although I noted it all down at the time so I have it if anyone asks for it), EXCEPT for 1 thing that might turn out to be relevant: the "good" site had site/config.php perms of 0644, and the "problem" site had perms of 0400. I tried changing the problem site perms to 0644 but that didn't fix the issue, so then I changed it to 0600 so I could at least write to it (e.g. to change $debug to true, etc). By comparing the contents of the 2 site/config.php files, I was able to narrow down the difference (this was AFTER ruling out a bunch of other things that I won't go into here). The difference is that the problem site had these extra lines which were absent in the good site: $config->sessionAllow = function($session) { // if there is a session cookie, a session is likely already in use so keep it going if($session->hasCookie()) return true; // if URL is an admin URL, allow session if(strpos($_SERVER['REQUEST_URI'], $session->config->urls->admin) === 0) return true; // otherwise disallow session return false; }; I commented out those lines and afterwards everything worked and I could log back into the admin area of the problem site. So, problem fixed, yay!! But - WHY were those lines there in the first place? They must have been from an older version of PW that I was running in the past. So they must have been doing SOMETHING, so have I caused a security issue in deleting them? Any advice you have about that would be very helpful. And also, was it therefore a bad idea to have my site/config.php perms on 0400? They're on 0600 right now on that site in case future PW upgrades need to change config.php. I thought 0400 was 'good' based on https://processwire.com/docs/security/file-permissions/#potential-permissions-for-site-config.php but perhaps I should have done 0600. Thank you for reading this and for any insight you can provide.

@jploch - it's definitely not out of scope for Migrator and it would be great to support it. There are a few places in the code where I have id!=2, has_parent!=2 - it's possible that removing those might take care of things. Can I leave it to you to test?

Try to change the trigger from "saveReady to "save"? // Before public function ready() { $this->pages->addHook('saveReady', $this, 'afterSaveReady'); } // After public function ready() { $this->pages->addHookAfter('save', $this, 'afterSaveReady'); }

maybe you are just missing a second & ? & --> && if($status & Page::statusUnpublished) {

Thank you @Zeka I'll explain the case on that thread then.

You can use RockMigrations for such tasks ? It's a very Powerful Module Or just look at the docs ? https://processwire.com/api/ref/page/delete/ // Delete a page and recursively all of its children, grandchildren, etc. $item = $pages->get('/some-page/'); $item->delete(true); It looks like the "true" is missing: $item->delete(true); "If set to true, then this will attempt to delete all children too."

@PascalKonings, the suggestion from @Zeka is probably the way to go, but in case you do want to stick with image tags you can set them dynamically in a hook in /site/ready.php: // Dynamically set the selectable tags for an images field $wire->addHookAfter('InputfieldImage::renderReadyHook', function(HookEvent $event) { /** @var InputfieldImage $inputfield */ $inputfield = $event->object; // The images field $field = $inputfield->hasField; // The page that the field is on $page = $inputfield->hasPage; // Only for a specific images field if(!$field || $field->name !== 'your_image_field') return; $config = $event->wire()->config; $js_name = "InputfieldFileTags_$field->name"; $data = $config->js($js_name); // Set the tags however you like, using $page if needed $data['tags'] = [ 'carrot', 'pumpkin', 'cauliflower', ]; $config->js($js_name, $data); });

This week I kept working on what's been in progress the last couple of weeks. That wasn't really the plan, as I was hoping to move on to other parts of the core. But I found it a took a lot of time to adjust everything to the new code and classes, and to refactor and remove other chunks of code that could either be simplified or removed. So these last few weeks of updates took a lot more time than I expected, and it's one of those things where once I got into it I felt I had to keep working until it was done as well as it could be. That meant getting pretty deep into some core logic. So in hindsight I'm slightly regretting refactoring so much code without major short-term benefits that can make more interesting reading here. And there are perhaps some short-term drawbacks in potentially introducing new bugs, as goes with any new code. But that's how it is sometimes. The good news is that it's a definite improvement in quality and I have no doubt there will be long term benefits especially in terms of improved performance and maintainability. But in any case, I'm glad to be wrapping up these particular updates so that I can move on to other parts of the core and Pro modules, and hopefully I'll have more interesting stuff to write about next time. One small addition you might find useful in these updates is that you can now identify the closest matching page when a 404 occurs. Maybe you want to provide a hint to users that land on a 404 as to what page they might have been looking for. Now you can do this in your 404 page template file: $p = $pages->request()->getClosestPage(); if($p->id > 1) { echo "<p>Were you looking for <a href='$p->url'>$p->title</a>?</p>"; } Like last week I'm not bumping the dev branch core version just yet because I don't want to trigger any upgrade alerts that might prompt people to upgrade immediately. I'd rather focus more on testing and leave these updates to those that are interested in that testing, helping to track down any issues. Thanks in advance for your help with testing these updates. Likewise, thanks for reading, I hope you have a great weekend!

EDITED It should work for 'usual frontend' pages. Since non-super users will have view permission for such pages. The added layer of restriction with respect to repeaters wouldn't apply. Hope this makes sense. For instance, if you had a 'members' field that is only viewable to 'members', logged in members (non-superusers) will be able to see the field as long as that field was on a page that members have page view or edit access to. Meaning, if that page is not a child of an admin page (e.g. repeaters, etc), the permission set will kick in.

Right - as part of my efforts to show off more of the work we've done recently, here's a site we launched earlier this year. On The Record are a not-for-profit that specialise in oral histories and creative media. We've done a few nice projects with them ( A Hackney Autobiography was a lovely project we did with them in our pre PW days). A creative design was very important to them as well as being accessible and usable. There's not too much bespoke backend coding going on. We needed to provide them with a way of easily adding audio and video files but that was mostly done using normal fields and a modified version of Ryan's TextformatterVideoEmbed module adapted for use on plain text fields. Apart from that, it's just the usual supects for extra modules: ProCache LoginPersist and Macrura's ProcessDocumention module which we normally use for provide help pages in the admin area. The front end is pretty much bespoke but with a few components lifted from various places; looks like we used Bootstrap grid for one. It's another site where we used CSS filter properties to apply a consistent look and feel to images the client uploads. I think it looks nice anyway and the client is very happy with it and took to using the PW admin with no problems.

See the attachment for the job posting. Contact information is in the posting. 2021-10 Lead Web Programmer.pdf

Hi all, how i can get total, start, limit etc from page object? $res = $pages->find("template=basic, limit=20"); Result from page 2: ProcessWire\PageArray Object ( [count] => 20 [total] => 95 [start] => 20 [limit] => 20 [pager] => 21 bis 40 von 95 [items] => Array ( [Page:0] => Array ( [id] => 17212

Ok, is no magic. $res->getStart(); etc. PaginatedArray class - ProcessWire API

As @LostKobrakai pointed out on the thread below: You can disable it though.