Robin S

I don't think you'll be able to use that combination because PageTable isn't supported inside a Repeater, and FieldtypeFieldsetPage is very closely related to FieldtypeRepeater (see the intro blog post). This post has a handy summary of fieldtype compatibility (written before FieldsetPage existed): So if changing your PageTable to RepeaterMatrix is an option then that will likely work inside FieldsetPage. AdminActions has an action for migrating PageTable to RepeaterMatrix.

Try using urlencode() on the image URL to deal with spaces and other potentially problematic characters.

The HTML Entity Encoder is probably applied to the title field (which is good). So you need to turn off output formatting for $quizPage... $quizPage->of(false); ...or at least get the unformatted value of the title field... $record->title = $quizPage->getUnformatted('title');

If the search phrase is coming from user input you'll need to sanitise it through $sanitizer->selectorValue or else there are a range of search phrases that will break your search and cause an error. But "%" is filtered out by $sanitizer->selectorValue by default, because it is a character that is used in a selector operators, e.g. "%=", "%$=", etc. So if it's important that "%" be allowed you'll need to add it in the whitelist option, but bear in mind that this will possibly allow some search phrases that could break the search or return incorrect results. Not sure how likely that is in practice. The basic operators that appear to work with % in the search phrase are *= and %=. The %= operator allows partial word matches so it depends what you want. If you want to match multiple words in any order you'll probably want use an approach where you explode to individual words then build up a selector string.

InputfieldWrapper extends Inputfield which implements Module. Do you get an error or something when you install this example module?

I don't understand the question. ConnectPageFields <= v0.3.1 requires PW >= v3.0.0 ConnectPageFields >= v0.3.2 requires PW >= 3.0.166

You're right, I think the vulnerability was only able to be exploited on systems where Adminer had been left in a publicly accessible location.

I believe so, give it a try. I can't test easily because my WAMP package has a mail sender built in.

It depends who needs to see these test emails. If only you, the developer, needs to see them you can use Tracy Debugger's Mail Interceptor panel and then (I think) you won't need an email server.

I did a bit of reading about this last night and reports are that in Adminer v4.6.2 and below there was a security hole that hackers exploited to attack WordPress and Magento sites - not sure if other platforms were vulnerable but given that Adminer is a general DB tool I assume so. But this hole was patched and consensus seems to be that recent versions of Adminer are safe. So I wonder if the OP's host has an overly broad rule that is simply flagging Adminer generally rather than detecting specific versions. Having said that, I checked the Tracy Debugger history and the first bundled Adminer version was v4.6.3 so it was kind of a near miss. Maybe it is better that the Adminer panel is separated into its own module so that having it present on a server is more of a conscious choice. I think it's an awesome addition to Tracy so I'll be installing it for sure.

Very interesting, although the visualisation doesn't quite demonstrate the fact that the bundled site profiles make up more than half of the total ZIP filesize when you download PW from the repo. I believe this has some negatives so I'm keen to start a discussion about moving most of the profiles to separate repos. For anyone interested, please participate here: https://github.com/processwire/processwire-requests/issues/415

You need to get the unformatted value of the Page Reference field in order to have unpublished pages appear: https://github.com/processwire/processwire-issues/issues/1159 $value = $page->getUnformatted('your_field_name');

When you say "uses", do you mean your module extends ProcessPageLister? If not that would probably be the simplest approach because then bookmarks will work out-of-the-box. Here's a bare-bones example: <?php namespace ProcessWire; class ProcessListerExtend extends ProcessPageLister { /** * Module information */ public static function getModuleinfo() { return array( 'title' => 'Lister Extend', 'summary' => 'An example of a module that extends ProcessPageLister', 'version' => '0.1.0', 'author' => 'Robin S', 'icon' => 'search-plus', 'requires' => 'ProcessWire>=3.0.0, PHP>=5.4.0', 'page' => array( 'name' => 'lister-extend', 'title' => 'Lister Extend', 'parent' => 'setup', ), 'useNavJSON' => true, ); } /** * Init * * Load the CSS and JS assets for ProcessPageLister rather than needing to duplicate them in this module's folder */ public function init() { $this->wire()->modules->loadModuleFileAssets('ProcessPageLister'); parent::init(); } /** * Install * * Call Process::install() to automatically create the admin page for the process on install * This is needed here because ProcessPageLister overrides with an empty install() method */ public function ___install() { Process::___install(); } /** * Uninstall * * Call Process::uninstall to automatically removes the admin page for the process on uninstall * This is needed here because ProcessPageLister overrides with an empty uninstall() method */ public function ___uninstall() { Process::___uninstall(); } } Wherever you need to modify a method of ProcessPageLister you can create a corresponding method in your module to override it, and you can make use of parent::methodName() within your method if you just want to add something to the ProcessPageLister method.

Generally speaking this is already possible. The syntax is: !your_field_name^=foo Paths are a special case though because these are only searchable when the PagePaths module is installed and that module doesn't support this kind of negation: But I don't think this actually matters because there is a dedicated selector option for when you want to find pages that do or do not have a particular ancestor, and that is "has_parent": https://processwire.com/docs/selectors/#finding2 So rather than needing anything like... ...you can instead do... has_parent!=/foo/|/bar/|/baz/

You have to first get the "itinerary" array as a variable distinct from the $session->itinerary overloaded property, modify it as needed, and then set it back to $session->itinerary. if(isset($_GET[$key])){ $itinerary = $session->itinerary; if(is_array($itinerary)) { // destroy a single element of an array unset($itinerary[$key]); $session->itinerary = $itinerary; $session->redirect($page->url); } }

The module readme says:

@neonwired, as explained a couple of posts above yours, you need to be using PW 3.0.166 or newer (currently on the PW dev branch) to install or upgrade to v0.3.2 of Connect Page Fields. If you don't want to use the PW dev version then you can manually download Connect Page Fields v0.3.1 by browsing back in the commit history: https://github.com/Toutouwai/ConnectPageFields/tree/99f5e06b959d100a57ab130fa6e6f57ffea19dc9 After you download make sure you rename the module folder from "ConnectPageFields-99f5e06b959d100a57ab130fa6e6f57ffea19dc9" to "ConnectPageFields" before you copy it to /site/modules/ and install it (see "Installing manually").

@hollyvalero, after these posts were written a powerful truncate feature was added to the core as a sanitizer method. https://processwire.com/api/ref/sanitizer/truncate/ https://processwire.com/blog/posts/processwire-3.0.101-core-updates/

FieldtypeDecimal uses InputfieldFloat as its inputfield, and it's the renderValue() method that determines what is shown when a field is not editable. So you could do this: $wire->addHookAfter('InputfieldFloat::renderValue', function(HookEvent $event) { /** @var InputfieldFloat $inputfield */ $inputfield = $event->object; $field = $inputfield->hasField; if($field && $field->name === 'your_field_name') { $event->return = '$' . number_format((float) $inputfield->value, 2); } });

Welcome to the PW forums @virgomania! I don't believe that's possible. The PW core philosophy is to have images and files connected to the pages they are uploaded to and not in one central repository. In the past Ryan (lead developer of PW) has discussed why he favours this approach. Here's one old topic... ...and maybe others will chime in with links to more background on this subject. So a few suggestions: 1. Consider if you absolutely must have a central image/file repository. Maybe you could try the PW-way and you might find it works pretty well for 99% of cases. I think a lot of people new to PW first thought they needed a media library and then gradually learned that they didn't. ? 2. If your main use case is linking/inserting files or images into rich text (CKEditor) fields then be aware that you can link/insert images from any page, not only the current page. Some people even create one or more dedicated "library" pages which hold a lot of files/images that they use on other pages. The Media Library module can help with this. 3. If your main use case is dedicated fields which will hold files/images then have a look at the commercial Media Manager module. I think this module also allows you to link/insert the media in CKEditor fields. 4. You mentioned the Select Images inputfield (used together with Dynamic Options I assume). Because you supply the selectable images via a hook you can make images from multiple different pages selectable. Here's an example hook that would make images selectable from any image field on any page using the basic_page or home template: $wire->addHookAfter('FieldtypeDynamicOptions::getSelectableOptions', function(HookEvent $event) { // The Dynamic Options field $field = $event->arguments(1); // For a field named "select_images" if($field->name === 'select_images') { $options = []; // For each page that uses the basic_page or home template foreach($event->wire()->pages->find("template=basic_page|home") as $p) { // Get the FieldtypeImage fields that are in the page's template $image_fields = $p->fields->find("type=FieldtypeImage"); // For each image field foreach($image_fields as $field) { // Get the images stored on the page in that field $images = $p->getUnformatted($field->name); // For each image foreach($images as $image) { // Add a selectable option $options[$image->url] = "{$image->basename}<br>{$image->filesizeStr}"; } } } $event->return = $options; } }); But be aware that this won't scale infinitely. At some point the number of selectable images might be unmanageable and you may strike performance issues in the page editor. I think Media Manager might be more scalable in this respect.

@rsi you can use $pages->sort() to set the sort value of the new page to zero after it is added, and that will make it appear at the top of its siblings but still be manually sortable. In /site/ready.php: $pages->addHookAfter('added', function(HookEvent $event) { $pages = $event->object; // The page that is being added $page = $event->arguments(0); // If the page passes some kind of test if($page->template == 'news_item') { // Set the sort value for the new page to zero (sibling sort will be automatically adjusted) $pages->sort($page, 0); } });

If you just want to do this from time-to-time you can add a filter row like this: Or if you want the default limit to always be 50 (or whatever limit you want) then you can add a hook in /site/ready.php: $wire->addHookBefore('ProcessPageLister::execute', function(HookEvent $event) { /** @var ProcessPageLister $lister */ $lister = $event->object; // Only for the "Find" lister if($event->wire()->page->name === 'lister') { $lister->defaultLimit = 50; } });

In most cases I expect people to use the Select Image inputfield in conjunction with the Dynamic Options fieldtype. And regarding the value of a Dynamic Options field: The Select Images input type is a bit of a special case because it can be a "multiple" or a "single" input type: And beyond that there is a config option for Dynamic Options that can be used if the values that are saved are paths or URLs to Pagefiles or Pageimages, and this could be a good option when you're using Select Images as the inputfield: When that option is enabled you could use the Pageimage sizing methods on the field value. Note that for multiple images the value is an array of Pageimage objects and not a Pageimages object. That's because these modules are intended to be flexible enough to allow selection of images from more than one PW page but a Pageimages object only supports Pageimage objects associated with a single page (see the class constructor). The readme for Select Images says: So you can have the value for each option (thumbnail) be any string you like and output that in a template file or use it in a conditional to affect the page markup in some way. But I think my most common use case will be as an "image reference" field to select URLs to Pageimages and have the formatted value be a Pageimage or array of Pageimage objects. People have suggested different use cases for an image reference field in the GitHub request linked to at the start of the readme: https://github.com/processwire/processwire-requests/issues/207 Personally I have used image references in these scenarios: To allow an editor to select a social media "share" image from among all the uploads to Images fields on a page. In cases where an editor may only select from a collection of existing images and is not allowed to upload new images. Similar to the previous example, but where the editor needs to choose images that have been prepared in advance to fit in spaces with particular aspect ratios. So for a landscape space they can only select landscape images, square space can only select square images, etc. The allowed options for a Dynamic Options field are determined at runtime according to the FieldtypeDynamicOptions::getSelectableOptions hook you are using. These allowed options are used to validate any stored value when it is accessed. So if an image that was referenced is deleted then it will no longer be in the value you get from $page->your_dynamic_options_field

v0.1.3 released. This version adds options to set a limit to the number of items that may be selected. When the limit is reached the supported core "multiple" inputfields become disabled. It adds an option for the formatted value to be Pagefile/Pageimage object(s) where that would be relevant. And it integrates with the newly released Select Images module to create a kind of "image reference" field. See the updated readme for more detail.

Select Images An inputfield that allows the visual selection and sorting of images, intended for use with the FieldtypeDynamicOptions module. Together these modules can be used to create a kind of "image reference" field. Integration with FieldtypeDynamicOptions InputfieldSelectImages was developed to be used together with FieldtypeDynamicOptions (v0.1.3 or newer): Create a Dynamic Options field. Choose "Select Images" as the "Inputfield type". Select Images appears in the "Multiple item selection" category but you can set "Maximum number of items" to 1 if you want to use Select Images for single image selections. Define selectable options for the field via a FieldtypeDynamicOptions::getSelectableOptions hook. See some examples below. FieldtypeDynamicOptions is recommended but is not a strict requirement for installing InputfieldSelectImages in case you want to use an alternative way to store the field data. Selection of Pageimages In this example the field allows selection of Pageimages that are in the "images" field of the home page. The field will store URLs to the Pageimages so it works as a kind of "image reference" field. You can use the "Format as Pagefile/Pageimage object(s)" option for the Dynamic Options field to have the formatted value of the field be automatically converted from the stored Pageimage URLs to Pageimage objects. $wire->addHookAfter('FieldtypeDynamicOptions::getSelectableOptions', function(HookEvent $event) { // The page being edited $page = $event->arguments(0); // The Dynamic Options field $field = $event->arguments(1); // For a field named "select_images" if($field->name === 'select_images') { $options = []; // Get Pageimages within the "images" field on the home page foreach($event->wire()->pages(1)->images as $image) { // Add an option for each Pageimage // When the key is a Pageimage URL the inputfield will automatically create a thumbnail // In this example the label includes the basename and the filesize /** @var Pageimage $image */ $options[$image->url] = "{$image->basename}<br>{$image->filesizeStr}"; } $event->return = $options; } }); Selection of image files not associated with a Page When not working with Pageimages you must add a "data-thumb" attribute for each selectable option which contains a URL to a thumbnail/image. In this example the field allows selection of image files in a "/pics/" folder which is in the site root. $wire->addHookAfter('FieldtypeDynamicOptions::getSelectableOptions', function(HookEvent $event) { // The page being edited $page = $event->arguments(0); // The Dynamic Options field $field = $event->arguments(1); // For a field named "select_images" if($field->name === 'select_images') { $options = []; // Get files that are in the /pics/ folder $root = $event->wire()->config->paths->root; $path = $root . 'pics/'; $files = $event->wire()->files->find($path); // Add an option for each file foreach($files as $file) { $basename = str_replace($path, '', $file); $url = str_replace($root, '/', $file); // The value must be an array with the following structure... $options[$url] = [ // The label for the image 'label' => $basename, 'attributes' => [ // An image URL in the "data-thumb" attribute 'data-thumb' => $url, ], ]; } $event->return = $options; } }); The field values don't have to be image URLs The values stored by the Dynamic Options field don't have to be image URLs. For example, you could use the images to represent different layout options for a page, or to represent widgets that will be inserted on the page. Also, you can use external URLs for the thumbnails. In the example below the options "calm" and "crazy" are represented by thumbnails from placecage.com. $wire->addHookAfter('FieldtypeDynamicOptions::getSelectableOptions', function(HookEvent $event) { // The page being edited $page = $event->arguments(0); // The Dynamic Options field $field = $event->arguments(1); // For a field named "calm_or_crazy" if($field->name === 'calm_or_crazy') { $options = []; // Add options that are illustrated with thumbnails from placecage.com $options['calm'] = [ // The label for the option 'label' => 'Nicolas Cage is a calm man', 'attributes' => [ // An image URL in the "data-thumb" attribute 'data-thumb' => 'https://www.placecage.com/260/260', ] ]; $options['crazy'] = [ // The label for the option 'label' => 'Nicolas Cage is a crazy man', 'attributes' => [ // An image URL in the "data-thumb" attribute 'data-thumb' => 'https://www.placecage.com/c/260/260', ] ]; $event->return = $options; } }); Field configuration If the inputfield values are Pageimage URLs then you can optionally include a button for each selected image to open the containing page for editing in a modal window. Note that if the selected image is contained in a Repeater item then it is the Repeater page that will be opened for editing. You can define labels for the button, notices, etc, that are used within the inputfield if the defaults don't suit. https://github.com/Toutouwai/InputfieldSelectImages https://processwire.com/modules/inputfield-select-images/