Robin S

It's in the core but not installed by default. Modules > Install > ProcessPagesExportImport Blog posts: https://processwire.com/blog/posts/processwire-3.0.71-adds-new-core-module/ https://processwire.com/blog/posts/pw-3.0.70/ https://processwire.com/blog/posts/processwire-3.0.68-and-more-on-page-export-import/ https://processwire.com/blog/posts/a-look-at-upcoming-page-export-import-functions/

Not sure I understand the question. You can install or upgrade using the dev version to get the fix. https://processwire.com/download/core/ https://processwire.com/docs/start/install/upgrade/ Or if you want to look at the specific commit it is here: https://github.com/processwire/processwire/commit/a2d5d62131cb94d5a5955f2ace4ba4d37947616b

@Tintifax, thanks for reporting this. I made some markup changes in v0.3.0 and needed to update the resizing JS to account for this. Should be fixed in v0.3.1.

This is a ProcessWire Fieldtype/Inputfield module so use on the frontend isn't something that's supported directly. If you have FormBuilder then the readme explains how to enable InputfieldStars for FormBuilder. If you are using the PW forms API for the frontend then it's really beyond the scope of this module support topic, but you can refer to forum topics like this: Essentially you would do something like this: /** @var InputfieldForm $form */ $form = $modules->get('InputfieldForm'); /** @var InputfieldStars $f */ $f = $modules->get('InputfieldStars'); $f->name = 'stars'; $f->label = 'Stars'; $form->add($f); echo $form->render(); Plus seeing as you are outside the PW admin the inputfield-specific JS and CSS are not going to be automatically included so you'll need to add them to your template file manually: <link href="/site/modules/FieldtypeStars/InputfieldStars.css" rel="stylesheet"> <script src="/site/modules/FieldtypeStars/rater-js/rater-js.js"></script> <script src="/site/modules/FieldtypeStars/InputfieldStars.js"></script>

@ShadowByte first let me say welcome to the PW forums ? The module does work with repeaters, but perhaps not in the way you are expecting. If you are relatively new to PW you may not be aware that every repeater item is a page, and those repeater pages have their own template. Repeater template names take the form "repeater_[field name]" and to see them in the templates list you have to enable "Show system templates" in the Filters section. The Connect Page Fields readme says: The way you have configured the module you have connected the fields "Track lyric" and "Albums". But the Albums field allows pages using the album template, and the album template doesn't contain the lyric field. Instead the lyric field is used on the repeater template (if the repeater field is named "tracks" then the template will be "repeater_tracks"). So for Connect Page Fields to work you would need to have a Page Reference field that defines its selectable pages as those using the repeater_tracks template and then connect that field to the lyric field in the Connect Page Fields config. As a side note, it's redundant to double up the connections like this in the module config: The connections are two-way so you only need to link a Page Reference field to its partner once. Assuming you actually want to connect albums to lyrics and not repeater_tracks items to lyrics, and you want to still use Connect Page Fields to avoid writing your own API code to synchonise the Page Reference fields, here's how I would do it... 1. Create a new Page Reference field (multiple pages) named "track_lyrics" that allows pages with the lyric template. 2. Add this field to the album template. Later on you might set its visibility to "Hidden (not shown in editor)" but for now leave it visible so you can check that everything works as expected. 3. In the Connect Page Fields config, connect the albums field to the track_lyrics field. 4. Add a Pages::saveReady() hook to /site/ready.php that will populate the track_lyrics field with all the lyrics that have been selected inside the repeater items on the page, every time an album page is saved. It might look something like this (update the template/field names if needed): $pages->addHookAfter('saveReady', function(HookEvent $event) { /** @var Page $page */ $page = $event->arguments(0); // Album: populate the track_lyrics field from the "tracks" repeater items if($page->template == 'album') { $lyrics = new PageArray(); foreach($page->tracks as $track) { $lyrics->add($track->lyric); } $page->track_lyrics = $lyrics; } }); Hope this helps!

@lele_ballack, Ryan has fixed the issue in a recent commit on the dev branch.

You could use the Find Merge module and supply it with two selectors: one for products without an archived ancestor and one for products with an archived ancestor. You'd probably start by finding the archived categories, then your selectors would include "has_parent!=$archived" and "has_parent=$archived".

@lele_ballack, I believe it's a bug with the field export/import for repeaters. I opened a GitHub issue here: https://github.com/processwire/processwire-issues/issues/1792

Correct. Don't know, similar code works for me here. Trying to set a plain WireArray to a Page Reference field looks wrong to me. The acceptable value to set to a Page Reference field is a Page or PageArray. There is some example code in the post below that can help deal with Page Reference field values from before the module was installed:

For me it is exactly that.

For anyone interested, I've released a module that provides information about active sessions similar to SessionHandlerDB, but for file-based sessions:

Session Info Lists information about active sessions in a similar way to SessionHandlerDB, but for file-based sessions. Only install the module if you are not already using SessionHandlerDB. Installation 1. If you want to be able to see the pages that are being viewed by active sessions then set... $config->sessionHistory = 1; ...in /site/config.php If you have already set $config->sessionHistory to a higher number then you can leave it unchanged: 1 is the minimum needed for use in the Session Info module. 2. Install the Session Info module. A helper module named "Session Extras" will be automatically installed also. 3. If you want to be able to see the IP address and/or user agent for active sessions then visit the module config page for Session Extras and tick the relevant checkboxes. 4. You can now view information about active sessions at Access > Sessions. Screenshots With $config->sessionHistory set to 1 or higher: Additional information is listed when IP address and user agent tracking are enabled in Session Extras: https://github.com/Toutouwai/ProcessSessionInfo https://processwire.com/modules/process-session-info/

When I modify a module that exists in the modules directory I put my initials in the module title or summary as a reminder, e.g. "Some Module: RPS mod". Then I disable the download button and add a notice to the "Download and Update" form just in case I forget. $wire->addHookAfter('ProcessModule::buildDownloadConfirmForm', function(HookEvent $event) { $data = $event->arguments(0); /* @var InputfieldForm $form */ $form = $event->return; $modules = $event->wire()->modules; // Return early if the module isn't already installed if(!$modules->isInstalled($data['class_name'])) return; // Get info about the installed module $info = $modules->getModuleInfoVerbose($data['class_name']); // Return early if special string doesn't occur in the title or summary if(strpos($info['title'], 'RPS mod') === false && strpos($info['summary'], 'RPS mod') === false) return; // Disable download button and add warning notice $update_button = $form->getChildByName('godownload'); if($update_button) { $update_button->value = 'Update disabled (RPS custom mod)'; $update_button->attr('style', 'opacity:0.5;'); $update_button->attr('disabled', 'disabled'); $this->warning('Module has custom RPS modifications: update disabled'); } $event->return = $form;

The API documentation is the place to start. https://processwire.com/search/?q=render(&t=API

There is a way to have pages returned by $pages->find(), $pages->findRaw(), etc, in the order of some supplied IDs. You use "id.sort" in the selector: https://processwire.com/blog/posts/pw-3.0.200/#pages-api-additions $data = $pages->findRaw('id.sort=1014|1|2', ['id', 'name', 'title', 'url']); You have to supply the IDs for all the pages you want to match: https://github.com/processwire/processwire-issues/issues/1581

Oh right, of course it only appears when you have switched to a different user. I can't think of many cases where I would want to stay as the currently selected user without having the ability to switch back to superuser but nice to have the option in case it is needed.

@bernhard, I think your Tracy Debugger might not be up to date. There is no "End Session" button in recent versions. You just can just click any user in the list and immediately change to that user. So it's pretty quick to toggle between two users - remember you can use the "Find user..." filter to find a user by name. The "Logout to Guest" lets you temporarily switch so you can view the front-end as a guest would, but with the debug bar still available even on production. But if you are using ProCache you would need to switch it off before using "Logout to Guest" because otherwise PHP will be bypassed altogether if a cache file exists.

That sounds like the correct result. 1500 is greater than or equal to 1000 and less than or equal to 5000. That use of the pipe isn't valid selector string syntax. The pipe is used as an OR operator within the value... firstname=Mike|Steve ...or within the field... body|sidebar*=carbonated But in the example you give you would need to use OR groups. And as Ryan mentioned earlier you will want to use the @ operator too because you want conditions like "price_list.procedure_price>=1000, price_list.procedure_price<=5000" to be matched within a single repeater item, not a staff_profile page that has one price_list item where procedure_price>=1000 and a different item where procedure_price<=5000. template=staff_profile, staff_location=1119, (@price_list.procedure_price>=1000, @price_list.procedure_price<=5000), (@price_list.procedure_price>=10000, @price_list.procedure_price<=15000)

I can see a couple of problems. The purpose of strtotime() is to "Parse about any English textual datetime description into a Unix timestamp". But you are supplying it with a variable that is already a Unix timestamp. So that will cause strtotime() to fail and return false. And then that false return value is then being supplied to strftime(), which instead needs to be supplied with a Unix timestamp. Also not sure that ucwords() would be needed, as I think the date string returned by strftime() should already be capitalised correctly. So probably it should be this: function dateToItalian($unixtimestamp) { setlocale(LC_TIME, "it_IT.utf8"); return strftime("%a %d %B %Y", $unixtimestamp); }

This is likely to be the problem. As @ngrmm mentioned, selector operators like > and < depend on the fieldtype used, so for a price you would want to use an integer field if you only need whole dollars, or a decimal field for dollars and cents (the decimal field is the better choice for futureproofing).

The ProcessPageList.js is pretty complex and there are things in it I don't understand. I had to do some some rather hacky stuff to get the module working, but the stakes are lower in a module because each person can decide if they want the functionality and are willing to install a beta module to get it. Whereas if I make changes to the core in a PR it might break something for everyone. So I'll wait a while to see if any issues crop up before considering a PR.

The images field value will be a Pageimages object. So when you do... $page_add->field->add() ...this is Pageimages::add(), and according to the documentation for that method it accepts either a Pageimage object or a path to an image file. You can't supply a Pageimages object to Pageimages::add(). So the relevant part of your code would need to be: foreach($page->field as $pageimage) { $page_add->field->add($pageimage); }

Page List Auto Expand Automatically expands the next adjacent page when moving a page in Page List. Usage As you are moving a page in Page List, if you position the yellow move placeholder above a Page List item for a configurable period of time (default is 1000 milliseconds) then that item will expand, allowing the moving page to be dropped as child page. Configuration In the module config you can set the delay before the Page List item adjacent to the move placeholder will be automatically expanded. Restricting the module to certain roles If you want to restrict the module functionality to only certain roles then create a new permission named page-list-auto-expand. If that permission exists then a user's role must have that permission or the module will not have an effect in Page List. https://github.com/Toutouwai/PageListAutoExpand https://processwire.com/modules/page-list-auto-expand/

Tracy Debugger's Console panel can execute any PHP that you would otherwise run from a .php file. You can type code directly into the Console window, or if you prefer to code in your IDE you can save .php files to /site/templates/TracyDebugger/snippets/ and then run them from the Console panel. I also like to use custom actions for Admin Actions for more complicated or lengthy code, or for when I want to set various parameters using PW inputfields.

Sometimes you need to execute a slow task after some event occurs in the PW admin, and normally you have to wait for this task to finish before you can continue using the admin. This is because PHP is "blocking", meaning that while one thing is executing nothing else can execute. There are potentially lots of different kinds of tasks that could be slow, but just as an example suppose you want to generate resized variations of images on a page, and there are a lot of images. You might have a hook like this so that any non-existing variations are created when the page is saved: $pages->addHookAfter('saveReady', function(HookEvent $event) { /** @var Page $page */ $page = $event->arguments(0); // When a gallery page is saved if($page->template == 'gallery') { // Create an image variation for each image foreach($page->images as $image) { $image->size(1200, 1200); } } }); When you save a gallery page in the PW admin, the admin will be unresponsive and will only load again after all the variations have been created. I wanted to find a way for slow tasks to be triggered by events in the PW admin and for the website editor not to have to wait for the task to finish before continuing with other work in the admin. Inspired by this StackOverflow answer I came up with the following solution that seems to work well. Using the image variations task above as an example... First we make use of the URL hooks feature to set up a URL that can trigger tasks to run when it is loaded: // A URL that will trigger tasks when loaded $wire->addHook('/run-task/', function($event) { $input = $event->wire()->input; // A simple check to avoid unauthorised access // You could implement more advanced checks if needed if($input->post('key') !== 'cTdPMBQ7x8b7') return false; // Allow the script to keep running even though we have set a short WireHttp timeout ignore_user_abort(true); // The "create variations" task if($input->post('task') === 'create-variations') { $page_id = (int) $input->post('page'); $p = $event->wire()->pages->get($page_id); // Create an image variation for each image foreach($p->images as $image) { $image->size(1200, 1200); } return true; } return false; }); Then in the Pages::saveReady hook we use WireHttp to load that URL and post parameters that define what task to run and anything else needed for the task (in this case the ID of the page that has been saved). $pages->addHookAfter('saveReady', function(HookEvent $event) { /** @var Page $page */ $page = $event->arguments(0); // When a gallery page is saved if($page->template == 'gallery') { // Load the /run-task/ URL using WireHttp $http = new WireHttp(); // Set a short timeout so we don't have to wait until the script finishes // Timeout values shorter than 1 second can be tried once a core issue is fixed // https://github.com/processwire/processwire-issues/issues/1773 $http->setTimeout(1); $url = $event->wire()->config->urls->httpRoot . 'run-task/'; $data = [ 'key' => 'cTdPMBQ7x8b7', 'task' => 'create-variations', 'page' => $page->id, ]; $http->post($url, $data, ['use' => 'curl']); } }); By doing it this way the task runs in a separate request and the website editor doesn't have to wait for it to finish before they can continue working in the PW admin.