Leaderboard

ProcessWire version 3.0.102 on the dev branch contains more than a dozen commits and PRs. I'll save the blog post till next week, as I continue reviewing pull requests and covering issue reports as they come in. But core updates are really going smoothly while the progress and fun continues, with ProcessWire getting better every week, thanks to your reports and PRs. This week I briefly had to do a small WordPress-to-ProcessWire conversion, but the site wasn't quite big enough to warrant automating the content conversion like I usually would. So I did a copy/paste job for the content, which I always kind of enjoy, so long as there isn't too much of it. But it was the first time that I had really used the new copy/paste images feature that we recently added to our CKEditor (outside of testing it during development). And I have to admit this feature is really handy for a case like this. Being able to “Copy Image…” (from another site), and paste at the location I want it to go in CKEditor …while the image uploads and inserts itself into my images field automatically… is pretty awesome. No more downloading images from the old site, on to my computer, then uploading to the new site, then placing them in CKEditor. What used to be several steps now feels like a single natural step. The new copy/paste process is so much simpler, and was a huge time saver this week. I mention it here because it's easy to forget that it's there at all (just like the drag-n-drop into CKEditor option). So if you haven't had a chance to try out the copy/paste image option in CKEditor, give it a try. It's a good thing to know about for those times when the need presents itself, because it'll save you (or your clients) a ton of time. More details about this feature can be found in the post for core version 3.0.87 (if you haven't read it already) where we covered the additions of drag-n-drop and copy/paste images uploads into CKEditor.

Not a question, but just something I discovered that I wanted to share on the forum since I haven't seen it discussed anywhere. If you are familiar with the "autojoin" option on individual ProcessWire fields, enabling this feature means that every time a page with that field on it is loaded into memory, the field will be included with it immediately. (Normally just the page's name and meta data is included, and getting a specific field from the page requires a separate trip to the database. This is to conserve memory) Normally this is fine and it keeps things simple, but occasionally you may be loading a lot of data in a consistent fashion (for, example, to populate a table) and know exactly which fields you need. With the autojoin option on fields, you would have to enable autojoin for all pages at all times, which you probably don't want. With the following code, you can do a $pages->find() and specify exactly which fields you want to autojoin with it: $pages->find("template=whatever", ['loadOptions' => ['joinFields' => ['filed1','field2','field3']]] ); I tested out in debug mode on one of my projects, and it seemed to significantly reduce the number of SQL queries required for an html data table I was building. Hope that helps someone!

So to get it working, nothing fancy, all easy. In this example, only the email user field is used. Thanks @daniels for this module ? Assuming the checkbox field is called "subscribe_newsletter" and added to the "Registration form fields" in LoginRegister settings, in ready.php : wire()->addHookAfter('LoginRegister::processRegisterForm', function($event) { $form = $event->arguments[0]; foreach($form->getAll() as $f) { $name = $f->attr('name'); if(strpos($name, 'register_') !== 0) continue; if($name == 'register_subscribe_newsletter' && wire('input')->post->register_subscribe_newsletter == 1) { $mc = wire('modules')->get("SubscribeToMailchimp"); $email = wire('input')->post->register_email; // Do not forget to saninitize the email field $mc->subscribe($email); } } }); Result:

@teppo, This module is ready to use with the current stable and dev versions of PW (3.0.99+). I know that many users (and me too) actively uses it in many sites. It is also simple to use in conjunction with MarkupSourceSet. So, I think I will not add new features to it, but I will maintain the compatibility of it with future PW versions! Some time ago, it becomes compatible with new UIKit-AdminTheme. Here is a screen:

I have done several integrations and I just basically grab this library through composer and use a private app credentials, the library also handles the API throttling which is extra nice when working with large amounts of data.

Adds a Service Worker to your Processwire site which can be customised. The service worker script itself is heavily based on Jeremy Keith’s work – thank you Jeremy! More information: https://github.com/johannesdachsel/processwire-serviceworker

Seems to work!!! Thanks!!!!!

Does this help? $this->addHookBefore('ProcessPageEdit::processInput', function($e) { if (wire('input')->post('submit_save')) { $e->message("This page has been saved by pressing the 'Save' button."); } });

Also, this: https://jakearchibald.github.io/isserviceworkerready/ ? And the latest Edge version now supports PWA features. https://blogs.windows.com/msedgedev/2018/04/30/edgehtml-17-april-2018-update/#bu5H7OqbuguSwr2B.97

It's annoying, right? You could thumbs-up the existing request for a change to this behaviour: https://github.com/processwire/processwire-requests/issues/186 And as a workaround in the meantime try this hook in /site/ready.php: $wire->addHookAfter('ProcessPageListActions::getExtraActions', function(HookEvent $event) { $page = $event->arguments(0); $actions = $event->return; if(isset($actions['copy']['ajax'])) { unset($actions['copy']['ajax']); $actions['copy']['url'] = "{$this->config->urls->admin}page/clone/?id={$page->id}"; } $event->return = $actions; }); If you find it's not working for you then it might be getting called before the equivalent hook inside ProcessPageClone, in which case you could try experimenting with the "priority" option for hooks: https://processwire.com/api/ref/wire/add-hook-after/

For this job you have this module available :

@MarcoPLY feel free to ask your question in this thread or this , as I am building a companion module for LoginRegister, all feature are welcome.

I've created an issue regarding features of MailChimp, that currently can't be used with the module. Also I'd like to make it more flexible, if Mailchimp roles out new stuff. My question to you: Do you currently use this MailChimp features or would like to have it in the module? - Groups (Interests) (Setup up - VIP - manually fill IP, Language and/or Location

Also consider to use selector as an regular array https://processwire.com/blog/posts/processwire-3.0.13-selector-upgrades-and-new-form-builder-version/#new-selectors-as-regular-arrays

For redirection (PRG), you can use http://processwire.com/api/ref/session/redirect/ Since you're using POST values in your selectors, you should sanitize them first. To customize the selector based on which fields are submitted in the POST, I would do something like this: $temp = []; if ( $input->post->product_brand_name ) { $temp[] = 'product_brand_name=' . $sanitizer->selectorValue($input->post->product_brand_name); } if ( $input->post->product_type ) { $temp[] = 'product_type=' . $sanitizer->selectorValue($input->post->product_type); } // ... and so on $selector = implode(',', $temp);

PW's `$session` stores data in `$_SESSION` but it's "namespaced" in the array. E.g. `$session->value` != `$_SESSION['value']` I'd recommend using the PW `$session` if possible instead of mixing and matching with `$_SESSION`. In PW3 you can also use `$input->requestMethod()` for request method checks. https://processwire.com/api/ref/session/ https://processwire.com/api/ref/input/

What I meant was whether PW was using the same basic flow: Converting a selector to an SQL select statement, getting the IDs of the matching pages, and then calling getById() to load the actual pages into a PageArray. I spent this morning doing a deep dive into the core and have confirmed that this is how it's working. I was also able to simplify the example by @LostKobrakai to the following: $pf = $this->pages->getPageFinder(); $query = $pf->find($selector, ['returnQuery' => true]); # Show sql //$query->getQuery(); # Modify query //$query->where($sql); $statement = $query->execute(); $statement->execute(); # Load the pages $ids = array(); while($row = $statement->fetch()) $ids[] = $row[0]; $myPages = $this->pages->getById($ids); I haven't solved the pagination side of things yet. Unfortunately PagesLoader::find() is doing quite a bit of work that we're not able to take advantage of due to the fact that we have to bypass it completely and go straight to PagesLoader::find() in order to get the DatabaseQuerySelect() object. I'm not sure if this problem can be solved without modifying the core or duplicating a lot of its code. For future reference, this is the basic flow of a Pages::find() call (sans various options and some intermediary methods): Pages::find() Does nothing on its own. Delegates to PagesLoader::find() PagesLoader::find() Checks for page in runtime cache, returns cached page if it's in memory Creates a selector object from your selector string (PageFinder::find() can also do this, as I discovered) PageFinder::find() Turns selector object/string into a ProcessWire DatabaseQuerySelect object (via PageFinder::getQuery()) Turns DatabaseQuerySelect into an SQL select statement and queries the database Returns a multidimensional array with the ID, parent ID, and template ID of each matching page (OR a ProcessWire DatabaseQuerySelect object if the $returnQuery option is true) PagesLoader::getById() Takes an array of IDs Creates a page object for each ID and populates it with fields from the database (an additional database query). This is where any autojoin fields are pulled from the database. PagesLoader::find() Sorts pages by template (?) Sets up pagination Returns final PageArray

The example you are referring to was not markup regions, but region() function calls. They are very different things. I think Horst may have thought I was talking about region() functions since the terminology is similar. Though I can also recommend region() / wireRegion() function calls (even if I don't often use them myself), as they are also quite useful, and I would certainly be happy to inherit a project using them. Depending on your code editor used to edit site files, they may be preferable to traditional delayed output. What you've described is not consistent with markup regions. You mentioned you would never use them, but I recommend enjoying some time with them before coming to that conclusion because I think you may view them as something different than what they are. Just like in any other methodology, it's your decision as to how you delegate front-end or back-end code, markup regions dictate nothing about that. Markup regions merely designate the target for markup, and are not really any different than delayed or direct output in that respect, other than that it's a little bit simpler to use, and a little more flexible in practice. Markup regions do not use class attributes. You can use id attributes if you want, but using pw-id attributes is independent of whatever is used in the markup. Of course, everyone prefers different methodologies, not to mention different projects have different needs, so there is no one-size-fits-all. PW supports a lot of different options, use whatever works best for your context.

I'll later take a look at it, but this could benefit of an inputfield selector. In my use cases I wouldn't hide these tabs for all pages.