Robin S

I'm yet to find the perfect solution but so far I have found... Search by location name (somewhat clunky and slow): https://www.geonames.org/ Click on map (can't search by name): https://askgeo.com/ Enter latitude and longitude (can't search by name): https://timezonedb.com/ For my needs I prefer a web interface but if I wanted or could be bothered with an API I found several listed in this StackOverflow answer.

Does anyone know of a website/tool that will let me type in the name of a city, or maybe click on a map, and get the PHP-compatible timezone name for that location? So for example if I typed or clicked on the location Christchurch, New Zealand I would get "Pacific/Auckland". It doesn't need to be an API or anything - I just need some way to manually look up timezones for different locations.

If you're using non-core inputfields beyond those described in the module readme it will be a case of "your mileage may vary" and I can't really offer support for those kinds of cases. I suggest just using a normal InputfieldSelect and setting the options from files in Files field(s) on the page, or via $files->find()/DirectoryIterator/glob.

If you don't like to use a hook for this, there is a module: https://processwire.com/modules/process-page-list-multiple-sorting/

Thanks for the report @adrian. The newly released v0.3.6 adds support for ProcessProfile and ProcessUser, and also adds a config field to show the Tracy debug bar in the dialog which can be helpful for debugging if you are building the dialog form with a hook.

@horst is right. Here's a demo:

Check out the Multisite module: https://github.com/somatonic/Multisite/

I think what you're looking for is the "name" attribute. So if $inputfield is an Inputfield object: $inputfield->name // The name of the input element within the form, which has a suffix when inside a repeater $inputfield->hasField->name // The name of the corresponding field (if the inputfield is associated with a field)

Both. It causes the inputfield to be rendered via renderValue() so there's no input, and even if somebody manually added an input in their browser any processing of the inputfield is prevented.

The AdminOnSteroids module has a feature that allows formatted dates in Page List via the template settings. See the "Date filter" section in the documentation here.

This is the crux of the issue. If the user shouldn't be able to edit a field then you don't want it included in the ProcessProfile form, but as you say this causes issues with inputfield dependencies. My suggestion is: 1. Only include editable fields in ProcessProfile. 2. Remove the showIf condition when the dependent fields appear in ProcessProfile. 3. Implement the same showIf logic to determine which fields are editable in ProcessProfile. Example... In this case I have fields text_1, text_2 and text_3 in the user template. The text_2 and text_3 fields have the showIf condition "text_1=foo". But I don't want the user to be able to edit text_1 in ProcessProfile so I disable that field in the ProcessProfile module settings: In /site/ready.php: $wire->addHookBefore('ProcessProfile::execute', function(HookEvent $event) { /** @var ProcessProfile $pp */ $pp = $event->object; // The fields that have a showIf dependency on a field not editable in ProcessProfile $dependent_fields = ['text_2', 'text_3']; // If dependency condition not met, remove dependent fields from the ProcessProfile editable fields if($event->wire()->user->text_1 !== 'foo') { $pp->profileFields = array_diff($pp->profileFields, $dependent_fields); } // Remove showIf condition from dependent fields $event->wire()->addHookAfter('Field::getInputfield', function(HookEvent $event) use ($dependent_fields) { $inputfield = $event->return; if(!in_array($inputfield->name, $dependent_fields)) return; $inputfield->showIf = ''; }); });

Another way? // Make all field inputfields non-editable in Page Edit $wire->addHookBefore('ProcessPageEdit::execute', function(HookEvent $event) { if(!$event->wire()->user->hasRole('read-only')) return; $event->wire()->addHookAfter('Field::getInputfield', function(HookEvent $event) { $event->return->editable(false); }); }); // Remove the Settings tab $wire->addHookAfter('ProcessPageEdit::buildForm', function(HookEvent $event) { if(!$event->wire()->user->hasRole('read-only')) return; $form = $event->return; $tab = $form->find('id=ProcessPageEditSettings')->first(); $form->remove($tab); $event->object->removeTab('ProcessPageEditSettings'); });

Getting OT here, but if the page names are publicly accessible anywhere but the email addresses are supposed to be private then you risk leaking the users' emails because base64 encoding is pretty recognisable and easily decoded by anyone. In that case it would be safer to encrypt the email addresses for the name using something like openssl_encrypt(). Also base64 strings can contain characters that are not URL safe so you'd need to replace those, e.g. "+" and "/".

You can hook the render of a normal text inputfield and use a <datalist> element. Code example here:

The core Page Reference inputfields output only a page ID and expect a page ID as input. Possibly you could create your own custom inputfield module that works with a page path instead of an ID. Or here's a hacky solution that involves adding an extra "path" attribute to your Hanna tag... Hook: $wire->addHookAfter('HannaCodeDialog::buildForm', function(HookEvent $event) { // The Hanna tag that is being opened in the dialog $tag_name = $event->arguments(0); // The form rendered in the dialog /* @var InputfieldForm $form */ $form = $event->return; $config = $event->wire()->config; $modules = $event->wire()->modules; if($tag_name === 'select_page') { /* @var InputfieldPageListSelect $f */ $f = $modules->InputfieldPageListSelect; $f->name = 'selected_page'; $f->id = 'selected_page'; $f->label = 'Selected page'; $f->parent_id = 1268; $form->add($f); // Add JS file to Hanna Code Dialog form $js_file = $config->paths->templates . 'hannas/select_page.js'; if(is_file($js_file)) { $js_url = $config->urls->templates . 'hannas/select_page.js?v=' . filemtime($js_file); $form->appendMarkup = "<script src='$js_url'></script>"; } } }); select_page.js $(document).ready(function() { // Must use mousedown instead of click event due to frustrating event propagation issues across PW core // https://github.com/processwire/processwire-issues/issues/1028 $(document).on('mousedown', '.PageListActionSelect a', function(event) { var path; // Adapt unselect label to suit your language if($(this).text() === 'Unselect') { path = ''; } else { path = $(this).closest('.PageListItem').children('.PageListPage').attr('title'); } // Adapt path field ID to suit $('#path').val(path); }); });

It's too early to access page fields/properties in the constructor. There is a ___loaded() method that's called when the page is loaded and ready. So you could have this: public function ___loaded() { $this->header = $this->title; }

I don't mind about the sort order if you guys think changing it will be an improvement. Having "Main setup" in the middle seems a bit unusual but not a big deal.

Page::__construct() takes a Template object as an argument: /** * Create a new page in memory. * * @param Template $tpl Template object this page should use. * */ public function __construct(Template $tpl = null) { if(!is_null($tpl)) { $tpl->wire($this); $this->template = $tpl; } $this->useFuel(false); // prevent fuel from being in local scope $this->parentPrevious = null; $this->templatePrevious = null; $this->statusPrevious = null; } So I think the constructor in your child class should be: public function __construct(Template $tpl = null) { parent::__construct($tpl); $this->header = 'some text'; }

As long as the user has edit access for the template, you can use "Additional edit permissions and overrides" at Edit Template > Access:

In the "Selector string" setting for "Selectable pages" you can use "page" to refer to the current page, but only if you also specify a subfield using dot syntax. In your case you would use page.id to exclude children of a parent: template=item, parent!=page.id Unfortunately I don't think this is documented anywhere.

I haven't used it, but I think that is what Croppable Image module is intended for: https://processwire.com/modules/croppable-image3/

Both client-side and server-side resizing strip the EXIF data. If you are able to get the EXIF data with the server-side option then possibly you are hooking before the resize and might be able to access and save the EXIF data then. But in my opinion PW shouldn't be stripping any data from an uploaded image that is to be the "original" from which variations are derived. There's an open issue about this, with fixes for both client-side and server-side resizing (ImageMagick only): https://github.com/processwire/processwire-issues/issues/1055 Just hoping and waiting for it to be applied to the core...

There's an open GitHub issue about this: https://github.com/processwire/processwire-issues/issues/956 Simplest solution for now is to create a different CKEditor field for use in the repeater.

Do you mean that editors are pasting absolute internal links into the link dialog in CKEditor? If so you could try an education approach first, i.e. "Please create internal links via the fields in the link dialog". That way you won't get absolute internal links in the first place. Beyond that you could use a saveReady hook to do a string replacement in the relevant field(s): $pages->addHookAfter('saveReady', function(HookEvent $event) { $page = $event->arguments(0); // Perhaps limit by template as needed if($page->template == 'basic-page') { // Internal links: replace absolute href with relative href $page->body = str_replace('href="https://www.domain.com/', 'href="/', $page->body); } });

Not a solution for you sorry, but I can't reproduce this issue or the other one with the source dialog on a clean PW installation. In such cases the first thing to check is if the issue is reproducible on a clean installation of the latest PW dev version. If it is reproducible then there's a good chance it's a bug and you can create a GitHub issue that describes the steps needed to reproduce the issue. If the issue isn't reproducible on a clean PW installation then it's probably due to a third-party module or some issue with your own code. To isolate the cause you often need to follow a process of elimination. Progressively uninstall modules and remove any customisations you have made until you find the cause. It can be a tedious process but that's just a fact of life when debugging. The Module Disabler panel in Tracy Debugger is an easy way to disable selected modules.