Leaderboard

But this isn't a solution for touch devices which don't have a hover state, and we all know that touch devices are a big share of internet use. There's discussion in the Invision Community support forums about how to bring back reputation points into the author pane (some of which I can't see but maybe @Pete can)... https://invisioncommunity.com/forums/topic/462326-current-ranks-–-and-–-reputation/ https://invisioncommunity.com/forums/topic/462099-bring-back-reputation-in-userinfopane/ Could we implement that here? Also, it would be nice to bring back custom member titles for those who had them (e.g. Ryan's reiska title): https://invisioncommunity.com/forums/topic/462409-46-how-to-restore-custom-member-titles/

Ah, perfect, thanks! So, this is what I've got and seems to work so far but I need to test it a bit more. public static function freezePages($selector) { // Make name and template read-only \Processwire\wire('pages')->addHookAfter('ProcessPageEdit::buildForm', function(\Processwire\HookEvent $event) use($selector) { $wrapper = $event->return; $page = $event->object->getPage(); if ($wrapper->has('_pw_page_name') === false || $wrapper->has('template') === false || $wrapper->has('parent_id') === false) { return; } if ($page->matches($selector) === true) { $inputState = \Processwire\Inputfield::collapsedNoLocked; $labelPostfix = ' (page frozen, value not editable)'; $wrapper->_pw_page_name->collapsed = $inputState; $wrapper->_pw_page_name->label .= $labelPostfix; $wrapper->_pw_page_name->description = null; // Hide note about 09, etc $wrapper->template->collapsed = $inputState; $wrapper->template->label .= $labelPostfix; $wrapper->parent_id->label .= $labelPostfix; $wrapper->parent_id->contentClass = 'parent-disabled'; // Setting to Inputfield::collapsedNoLocked shows the ID so instead just disable via a CSS class from custom CSS file } }); // Remove “Move” button \Processwire\wire('pages')->addHookAfter('ProcessPageListActions::getActions', null, function(\Processwire\HookEvent $event) use($selector) { $page = $event->arguments(0); $actions = $event->return; if ($page->matches($selector) === true) { unset($actions['move']); } $event->return = $actions; }); } Usage is then like this: Hooks::freezePages('template=settings|site-map'); Any matching pages cannot be moved or have their name, parent or template changed. Note the parent part is blocked via a CSS class so in my case I have some custom CSS included from admin.php: .parent-disabled { opacity: 0.5; pointer-events: none; } I would've used an inline style but couldn't find that option.

I added this to my search.php template file. Hope that helps. $searchEngine->addHookAfter('Renderer::renderResult', function($event) { $p = $event->arguments[0]; $image = $p->getunFormatted('pdf_images|image|images|video_images')->first(); if($image) { $thumb = $image->size(0, 260, array('upscaling' => false)); $event->return = ' <div class="row"> <div class="small-12 medium-4 large-5 xlarge-4 xxlarge-3 columns teaser__image"> <a href="'.$p->url.'"> <img style="max-height: 300px" src = "'.$thumb->url.'" /> </a> </div> <div class="small-12 medium-8 large-7 xlarge-8 xxlarge-9 columns teaser__content"> ' . $event->return . ' </div>'; } });

No, it does prevent a bunch of downstream hooks from firing, but specifically it doesn't include Pages::save and Pages::saveField (and I think it should include those methods). And to avoid confusion it would be good if the documentation explained exactly which hookable methods are affected by the noHooks option when it used in any of Page:save(), Pages::save() and Pages::saveField(). I've opened a GitHub issue so that Ryan is more likely to notice the problem and our discussion of it: https://github.com/processwire/processwire-issues/issues/1405

I've got some core updates in progress but nothing major committed yet, so we'll save that for next week. But I wanted to briefly tell you about a module I'm working on here, which I plan to eventually put in core. I built it for some needs I've had here, but it will first be released in ProDrafts (so ProDrafts may start using its API), and in ProDevTools too, since it is also a developer tool. It's a snapshot versioning system for pages, but more of an API tool at this stage, kind of like the $pages API var, but for snapshots/versions of pages. It lets you create a snapshot of any page, including its fields and files (including core fields, ProFields, 3rd party fields, repeaters, nested repeaters, table fields with a million rows, etc.). The snapshots can be restored at any later time. Snapshots may also be restored to a different page, such as a new or existing page. In this manner, a module like ProDrafts may be able to use it to manage draft versions even better than it currently can, or at least that's the plan. Though since it's an API tool, my hope is that when/if it winds up in the core, others may be able to use it for stuff we've not thought of yet too. The module is a little different than my previous attempts (like what's in ProDrafts now) in that it does most of its work directly at the database level (and file system level, where applicable), which enables it work without needing to know much about the Fieldtype. Currently it is fully functional, but I have a few less common cases to work out before it's ready for release. Once installed, every page includes a Snapshots fieldset, which can be located in the settings tab of the page editor, or a separate tab in the page editor (configurable). When installed, every page has one, so long as the user has the appropriate permissions. There's a screenshot of what it looks like in the page editor below, but it is very simple at this stage, basically just enough for testing purposes. Every snapshot has a name that is unique on the page. You can overwrite a snapshot just by saving a snapshot with the same name on the same page. So you could for instance have a hook that creates a snapshot named "undo" right before a page is saved (in a Pages::saveReady hook), and in that way a module could add a basic undo capability to the page editor. This is just a simple example though. Thanks for reading, have a great weekend!

Hi there, My company, Fixate, has been building and supporting ProcessWire sites for a number of years now. I've recently accepted an offer for a position at another company, and as the last dev on the team (the team is now primarily UI/UX), we need to find someone who can assist with client requests. We have clients in Canada, Zambia, and South Africa, so we're comfortable with any timezone you may be in. The projects predominantly have this setup: Dockerised services for quick setup Gulp to automate: builds and file revisioning SSH deployments backups / restorations Some of our client's sites: blu-line.co.za biocarbonpartners.com knowledgehub.southernafricatrust.org We're looking for someone to work directly with our clients when they need assistance. Feel free to contact me at larry U+0040 fixate.it Thanks! Larry

+1001 (for permanent visible reputation count and for individual member titles like: captain earth, manager of expectations, ... etc.) ??

I had been struggling to implement the 'noHooks' option in $page->save(). $page->save(['noHooks => true']) does not seem to work, nor does $pages->save($p, ['noHooks => true']) Then I found the following documentation in wire/core/Pages.php: * - `noHooks` (boolean): Prevent before/after save hooks (default=false), please also use $pages->___save() for call. So $pages->___save($p, ['noHooks => true']) does work. Just thought I'd mention it as it is a bit buried (and a bit unusual). Also, I'm not sure if it is possible to use the noHooks option with $page->save().

ProcessPageEdit has a getPage() method you can use: $page = $event->object->getPage();

Does it make a difference if you move the negation? $items = $pages->find("template=basic-page, limit=$limit, !body=''");

@wbmnfktr Ah awesome, thank you! That's a great post. I've taken those steps now as they definitely seem like good additions!

Thanks for your help @Robin S I sort-of get it: $page->save(['noHooks' => true]); just prevents hooks running on Page::save - it does not prevent downstream hooks on Pages::save etc. My hook was on before Pages::save as advised elsewhere on this forum. See image below (ready() is needed to load the hook, debug_backtrace is running in the beforeSaveThis hook on Pages::save). However, if I try $pages->save($page, ['noHooks' => true]); then the hook on Pages::save still runs! EDIT: Ironically, this still only prevents hooks running on Page::save but $pages->___save($page, ['noHooks' => true]); works, as does plain $pages->___save($page); This all seems pretty confusing and inconsistent though (at least to my little brain). Perhaps @ryanor someone with greater knowledge than me could shed some more light on this (and clarify the documentation?).

By default, the "Forgot Password" module is not turned on in v2.1. My thought was that lack of such a function is technically more secure (on any site or CMS). Why? Because having such a function active means your password is only as secure as your email (*though see note at end of this message). So I thought we'd start things out as secure as possible and let people adjust it according to their own need. But I'm rethinking that decision, and may change it to be 'on' by default. If you don't already have that "Forgot Password" module installed, it is relatively easy to reset your password with the API. Lets say that you lost the password for your account named 'admin' and you wanted to reset it. Paste this code into any one of your templates (like /site/templates/home.php in the default profile, for example): <?php $admin = $users->get('admin'); $admin->setOutputFormatting(false); $admin->pass = 'yo12345'; // put in your new password $admin->save(); …or if it's easier for you to copy/paste everything on one line, here's the same thing as above on one line: <?php $users->get("admin")->setOutputFormatting(false)->set('pass', 'yo12345')->save(); Replace "yo12345" with the new password you want and save the template. Then view a page using that template (like the homepage, in our example). The password for that account has now been reset, and now you are ready to login. Don't forgot to now remove that snippet of code from the template! Otherwise your password will get reset every time the page is viewed. Once logged in, here's how to install the Forgot Password capability: 1. Click to the "Modules" tab. 2. Scroll down to the "Process" modules. 3. Click "Install" for the "Forgot Password" module. That's all there is to it. You will now see a "Forgot Password" link on your login page. *ProcessWire's "Forgot Password" function is actually a little more secure than what you see in most other CMSs. Not only do you have to have the confidential link in the email, but the link expires in a matter of minutes, and PW will only accept password changes from the browser session that initiated the request. So an attacker would have to initiate the password change request and have access to your email at the same time, making it a lot harder for a man-in-the-middle snooping on your email.

I found (after 2-3 Projects using PW) that it's a good technique to use templates in a way I think hasn't been thought of yet really by some. (Although the CMS we use at work for year, works this way.) I'm sure I'm maybe wrong and someone else is already doing something similar. But I wanted to share this for everybody, just to show alternative way of using the brillant system that PW is. Delegate Template approach I tend to do a setup like this: - I create a main.php with the main html markup, no includes. So the whole html structure is there. - I then create page templates in PW without a file associated. I just name them let's say: basic-page, blog-entry, news-entry... but there's no basic-page.php actually. - Then after creating the template I make it use the "main" as alternative under "Advanced" settings tab. So it's using the main.php as the template file. - This allows to use all templates having the same php master template "main.php" - Then I create a folder and call it something like "/site/templates/view/", in which I create the inc files for the different template types. So there would be a basic-page.inc, blog-entry.inc ... - Then in the main.php template file I use following code to delegate what .inc should be included depending on the name of the template the page requested has. Using the TemplateFile functions you can use the render method, and assign variables to give to the inc explicitly, or you could also use just regular php include() technic. <?php /* * template views depending on template name * using TemplateFile method of PW */ // delegate render view template file // all page templates use "main.php" as alternative template file if( $page->template ) { $t = new TemplateFile($config->paths->templates . "view/{$page->template}.inc"); //$t->set("arr1", $somevar); echo $t->render(); } <?php /* * template views depending on template name * using regular php include */ if( $page->template ) { include($config->paths->templates . "view/{$page->template}.inc"); } I chosen this approach mainly because I hate splitting up the "main" template with head.inc and foot.inc etc. although I was also using this quite a lot, I like the delegate approach better. Having only one main.php which contains the complete html structure makes it easier for me to see/control whats going on. Hope this will be useful to someone. Cheers