Robin S

It's not official documentation but the topic has been discussed here: The page and diagram that @teppo created and linked to is dead now but I've found it very informative so here's the diagram for posterity: It would be wonderful if @ryan or someone knowledgeable created an updated version of this.

Field Initial Value For most field types, allows the definition of an initial value that is automatically set when pages are created. The initial value can be set in template context if you want a different initial value in different templates. Example for a "Countries" Page Reference field using AsmSelect: Example with explanatory notes in a CKEditor field: Differences from "Default value" The core allows setting a "Default value" for certain field types. The "Initial value" setting added by this module is different from the "Default value" setting in the following ways: The "Default value" is a setting that applies only to the inputfield, meaning that the value is shown in the inputfield by default but is not stored until you save the page. By contrast, the "Initial value" is automatically saved to the page when the page is first created. Related to point 1, when a page is created via the API rather than in the ProcessWire admin the "Initial value" is saved to the page but the "Default value" is not. The "Default value" has no effect when a field is not "required", but the "Initial value" is set for both required and not required fields. Related to point 3, a user can empty a field that had an "Initial value" applied but a field with a "Default value" set cannot be emptied. The "Initial value" setting is available for more field types than "Default value". Supported field types The following field types are supported, along with any types that extend them: FieldtypeText (includes types that extend it such as Textarea, CKEditor, URL, etc.) FieldtypeDatetime FieldtypeInteger FieldtypeDecimal FieldtypeFloat FieldtypePage (with all core inputfield types) FieldtypeCheckbox FieldtypeOptions (with all core inputfield types) FieldtypeToggle FieldtypeSelector FieldtypeMultiplier (ProField) FieldtypeCombo (ProField, only supported when File and Image subfields are not used) FieldtypeStars (third-party module) If you want to try field types beyond this you can define additional types in the module config, but your mileage may vary. Unsupported field types It's not possible to set an initial value for these field types, along with any types that extend them: FieldtypeFile (and FieldtypeImage) FieldtypeRepeater (includes types that extend it such as Repeater Matrix and Fieldset Page) FieldtypePageTable FieldtypeTable (ProField) Notes Seeing as the initial value is defined in the field config it has no idea of the current page - for the purposes of rendering the initial value inputfield the home page is supplied as a dummy page. This probably isn't an issue in most cases but it might have an effect for some Page Reference fields if they use the current page to limit the selectable pages. https://github.com/Toutouwai/FieldInitialValue https://processwire.com/modules/field-initial-value/

If your two sites are on the same server then this blog post explains how to do it: https://processwire.com/blog/posts/multi-instance-pw3/

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); }