Leaderboard

Following up from the module mentioned last week, the PageEditRestore module has been released and here's a new blog post with all the details. This module helps to prevent page edits in the admin from getting lost when the user’s session is lost— https://processwire.com/blog/posts/page-edit-restore-module/

Support thread for the PageEditRestore module. This module helps to prevent page edits in the admin from getting lost when the user’s session is lost. Blog post about Page Edit Restore Module directory page GitHub page

I did my first talk ever yesterday @ PHP Meetup Vienna!! Once more everything was a lot more work than I first thought, but I'm quite proud of the result ? What do you think? Did I forget something important? It was really hard to put 10 years into one hour... The recording was not planned at first, but I thought I'd just give it a try and everything worked quite well ? If you like what you see please share it with others so that ProcessWire gets the attention that it deserves ? Special thanks to @gebeer for showing me ProcessWire in 2013 ?

This is awesome!

@bernhard The Pastefilter may be good for this specific case, since you are wanting to filter pasted content. But also have a look at the valid_elements and/or invalid_elements options, which give you control over what tags and attributes are supported in the input.

Thank you Ryan, reading the blog post I have one question: is it possible to somehow create a white/blacklist of roles/users/templates/fields so that we could fine tune when the restoring the operation should be offered in the first place?

What about this in ready.php? if ($user->name !== 'thatsme') \Tracy\Debugger::$showBar = false;

Open /wire/modules/Inputfield/InputfieldTinyMCE/InputfieldTinyMCE.module.php and comment lines 289-291 and see if this helps.

Haven't used it yet but I think this is something you can control in the module’s (or even in the field’s?) settings with the pastefilter whitelist:

@wbmnfktr this module is for you : https://processwire.com/modules/blackhole/ Then add the 3 `wp-` magics folders and you will get rid of most bots :

Sure - I added 2 files with adminonsteroids: site/template/admin/admin.css site/template/admin/admin.js With these codes I hide following features: Image Cropping Image Variations Image Title change Image Actions Image Change on Drag & Drop /* added ot admin panel sites */ .InputfieldFileActionSelect, .InputfieldImageEdit__info, .InputfieldImageEdit__buttons button { display: none !important; } .InputfieldImageEdit__buttons button.InputfieldImageButtonFocus { display: inline-block !important; } .InputfieldImageEdit__name span { cursor: default; } .InputfieldImageEdit__imagewrapper .detail-upload { visibility: hidden !important; } // added ot admin panel sites $(document).ready(function() { $('.InputfieldImageEdit__name span').removeAttr('contenteditable'); });

If you wanted all grandchildren, and nothing deeper, you could do this: $page->find("parent=$page->children"); If you wanted grandchildren and anything deeper, you could do this: $page->find("parent!=$page"); If you wanted children, grandchildren and anything deeper, you could do this: $page->find('');

This doesn't work because $page->children is an array of pages (PageArray), not a Page. Think of it like a boat carrying a bunch of people. The boat can't have children, but the people in it can. I'm also not sure $page->children->children would be all that useful, because they would have lost all sorting context. However, I'm only thinking in context of the sites I make and know everyone has different needs. So if you want to have something equivalent to $page->children->children, it would be $page->find('id>0'). But I would suggest using Soma's examples as they are more specific to a template, and it's better to be specific. Nearly any search that gets passed through a selector is fully indexed, so it doesn't have to scan the whole site. If you put in "template=video" it [mysql] heads straight to an index of pages with the video template, so it's not scanning or considering other pages. You'd want to limit that if you were using the video template elsewhere in the site and didn't want videos from one branch getting mixed in with videos from another. However, if you know where you are using the video template and aren't going to be using it on other branches in the site, there's no speed advantage to performing the search within a parent $page rather than just using $pages->find() to do it. Technically, there's slightly more [minor] overhead doing a $page->find() than a $pages->find() because it's adding a lookup table to the search that may or may not need to be there.