Robin S

You'll know more about this than me, but my understanding is that what is available in a dump from __debugInfo() depends on what the developer of the class makes available in the method. So if that method in a class was quite limited in what it made available (either intentionally or not intentionally) then the Tracy user potentially misses out on a lot of relevant information. To give a silly example, if I do this in a class... public function __debugInfo() { return ['Nothing to see here.']; } ...then dumping an instance of it will be useless. It looks like most of the __debugInfo() work is done in the dedicated WireDebugInfo class. If you think that Ryan has covered everything that anyone could ever need here then I guess shorter/tidier is better. But if you have doubts I'd rather get all the data as per the status quo than be wondering about what might have been overlooked.

Is your page unpublished? InputfieldPassword is set to required on unpublished pages regardless of what you might have chosen in the field settings - see here. Probably only @ryan could tell you why this is so. You can work around the issue with a hook in /site/ready.php: // You may need to modify "pass" to whatever your password field is named $wire->addHookBefore('Field(name=pass)::getInputfield', function(HookEvent $event) { $page = $event->arguments(0); $field = $event->object; // Do some test on $page and/or $field to identify the cases where the password field should not be required // Then... $field->required = false; });

Thanks for the heads up - I've fixed that. I don't think it's strange. The href property in getModuleInfo() is optional so getting any link is like a bonus - Ryan rarely uses it in his modules for example. If a developer does choose to use the href property then the guidelines are "URL to more information about the module" - I think the GitHub readme satisfies that guideline quite well. The online repository is the primary home of the module - the module directory listing just pulls the readme from the repo. Also, at the time I'm filling out getModuleInfo() the repo URL is the only one that exists. The module doesn't have a directory page or support thread at that point, and some modules never will, so using the repo URL keeps things consistent across all my modules.

The method @LostKobrakai mentions above gives you a clue about how you can make a simple function for the purpose... // Get the page from a path which might include URL segments function getPage($path) { $page = wire('pages')->get("path=$path"); if($page->id) return $page; // If the path matches a page return that $pieces = explode('/', $path); // Break the path into pieces while(!$page->id) { // Until a page is matched... array_pop($pieces); // Pop off the last piece (a URL segment) $path = implode('/', $pieces); // Make a path from the remaining pieces $page = wire('pages')->get("path=$path"); // Try and get a page at that path } return $page; // Return a matching page or a NullPage if no match } If you wanted to get the URL segments from the path it would be easy to modify the function to return those also.

You won't be able to use $log->save() for the reason @alxndre mentioned, and you won't be able to use the admin log viewer because a) it uses new lines to identify each log entry so therefore one entry cannot contain more than one line, and b) it entity encodes HTML for security reasons. But you can use PHP functions like error_log() or file_put_contents() to create your own log file (create the "custom-logs" folder first). $text = date("Y-m-d H:i:s") . "\nHello, how \nare you?\n\n"; // your text, include newlines if needed error_log($text, 3, $config->paths->assets . "custom-logs/mail.txt")

I prefer the responsive embed method... ...and this applies a class to a containing div element.

Browsing to the already selected item gets to be a pain, but thankfully the AdminOnSteroids module has an enhancement that lets you clear the selection more easily.

Those two things contradict each other somewhat. If you are creating a new custom fieldtype then there won't be any existing field data until you create your fieldtype module and start using it in pages. There is the Events fieldtype and inputfield which was created specifically as a proof-of-concept for developers to learn from. But it extends FieldtypeMulti (each field instance saves/shows multiple repeated items) so that might not suit what you are wanting to do. I don't think Ryan made a similar proof-of-concept for a straight Fieldtype. But in a way all the Fieldtype modules in the core and in the modules directory are a proof-of-concept - find a fieldtype that is broadly similar to what you want to do and check out (borrow from ) the code. Also, the documentation for the Fieldtype class will be useful. Perhaps if you describe exactly what you want the fieldtype/inputfield to do people can give you more suggestions.

Right - I forgot that your Page Reference field is inside a repeater, so that means in the hook $page is the repeater page and we need to get its container page. I edited my post above and it should work now.

It's true that UI preferences played a part in my not liking the System Notifications module, but I'm sure I struck some problems also. Some forum topics indicate that others have too. Overall it seems like a module that was released partly finished with the intention of being completed (or at least further developed) but that went off the boil and it somehow ended up in the stable core despite its "under development" status.

The selectors documentation is focused on PageFinder operations that query the database - $pages->find(), $page->children(), etc. When you use find() on a Repeater field value you are searching a PageArray in memory and the database is not involved, so that is probably the reason for the difference. You could use a different operator like ~= or %= for a case-insensitive search. It would be good if the selectors documentation had more information about the differences between selectors used in PageFinder::find() vs WireArray::find().

You shouldn't need to create that file - it is part of every core site profile and should already exist. If it doesn't then you must have deleted it at some point, which is likely the cause of the issues you mention. You could try creating a new admin.php based on the file here. The hooks I mentioned have nothing to do with AJAX, and I can't reproduce any problem here. Incidentally, PW does not include any AJAX notifications by default. Maybe you installed the System Notifications module - if so, I don't use that module and I don't know anything about it apart from that it gave me a bunch of problems years ago when I tried it. Off topic, but frankly I think that a module that is clearly beta and labelled "currently in development"... ...has no business being in the PW stable core. It should be in dev branch only, or better yet a module outside the core. That is a method of the base Fieldtype class that all fieldtypes extend.

Try this in /site/ready.php... $wire->addHookAfter('InputfieldPage::getSelectablePages', function($event) { if($event->object->hasField == 'your_page_reference_field_name') { $page = $event->arguments('page'); if($page instanceof RepeaterPage) $page = $page->getForPage(); $event->return = $page->variants; } });

Add the following to the top of /site/templates/admin.php if($user->hasRole('some_role')) { // Replace 'some_role' with the role you want to customise the page list for $wire->addHookAfter('FieldtypePageTitle::wakeupValue', function(HookEvent $event) { $page = $event->arguments(0); // Should be able to match 'Pages' page by ID if($page->id === 3) { // Change 'Pages' to 'Streams' $event->return = 'Streams'; } }); $wire->addHookBefore('ProcessPageList::execute', function(HookEvent $event) { $ppl = $event->object; // Start ProcessPageList from a particular parent page $ppl->id = 1234; // The ID of the 'Streams' page }); } If you are already logged in as this role, log out and then log in again to clear the cached top-level menu.

I'm afraid I'm not able to understand your scenario any better than the last time you raised it, but I think you might be asking about how to send data from PHP to Javascript. If your Javascript will run in the back-end then you can use the ProcessWire.config object via $config->js(). In your PHP... $config->js('my_data', [ 'noun' => 'dog', 'verb' => 'barking', ]); In your Javascript... alert('The ' + ProcessWire.config.my_data.noun + ' is ' + ProcessWire.config.my_data.verb); If your Javascript will run in the front-end then you can do this in your template file... <?php $my_data = [ 'noun' => 'dog', 'verb' => 'barking', ]; ?> <script> // Create Javascript object var my_data = <?= json_encode($my_data) ?>; </script> ...and later in your Javascript... alert('The ' + my_data.noun + ' is ' + my_data.verb);

@teppo, do you have any advice if I want to add support for fieldtypes beyond those in the core? Does the module have any hookable methods that allow for that? For instance, I tested with FieldtypeMapMarker and the history and diff parts seemed to work okay but the restore action failed because the saved data needs to be converted into an object of the right class. It looks like the module saves the string value of a field - am I able to hook into the restore action to control how the string is restored back to the field value?

Welcome to the forums @redpanda Community member @dadish kindly released a PW3-compatible version of the Skyscrapers profile here: https://github.com/dadish/pw-skyscrapers-profile

Another approach besides the one @flydev mentioned: $pages->addHookAfter('saveReady', function(HookEvent $event) { $page = $event->arguments(0); if($page->template != 'newsletters') return; // Only for specific template $page->newsletters->sort('-year'); // Sort the repeater how you want // Sequentially set the sort property of the repeater items $i = 0; foreach($page->newsletters as $item) { $item->sort = $i; $i++; } });

Another minor UI thing: the new UI can look a bit funny with AdminThemeDefault and AdminThemeReno because opening the history doesn't trigger the core column sizing JS, so the height of fields in the same row isn't updated to match. It's not a big deal, and the issue doesn't occur for AdminThemeUikit so maybe not worth doing anything about. If there is a column to the right of an open history container then the history gets overlapped by 1 pixel on the right edge. Again, not a big deal, but maybe these things could be avoided by using absolute positioning for the history container so it appears in a layer over the Page Edit interface and doesn't expand the inputfield column. Using the core panel UI could be a nice alternative too, but I don't know how easy it is to inject HTML directly into this. I think it's only set up to handle iframes (which if so is a bit of a shame because it reduces the range of things the panel can be used for).

Hi @teppo, There is a little UI issue with accessing version history for checkbox fields. When a checkbox field doesn't use a separate label (and it doesn't by default), the icon for accessing the history UI doesn't appear. And if the checkbox field is rendered collapsed by default the icon does appear but disappears when the field is opened.

I just tested it and it seems to work fine in PW 3.x. What kind of problem are you seeing? Or do you just mean the modules directory doesn't specifically say it is compatible with 3.x? All that means is that the module author hasn't recently updated the directory info. If in doubt about compatibility for any PW module my suggestion is just install it and give it a try - most older modules work fine in 3.x. And something like a Textformatter module isn't that sensitive to updates in the core.

I suggest just hiding the controls with some custom CSS in the admin (you can add this with Admin On Steroids or Admin Custom Files). That way it's easier to update the core without losing your customisations. One approach is to intercept and modify images in CKEditor fields using a textformatter. Take a look at Image Interceptor.

I've opened a GitHub request: https://github.com/processwire/processwire-requests/issues/172

Yeah, it is a concern for all external links in the admin, as the referrer will leak the login URL. It's straightforward to fix with a hook... $wire->addHookAfter('AdminTheme::getExtraMarkup', function(HookEvent $event) { $parts = $event->return; $parts['head'] .= '<meta name="referrer" content="no-referrer">'; $event->return = $parts; }); ...but perhaps this should be in the core admin themes.

The great thing about PW is that there's never just one solution to a problem but usually half a dozen. Thanks again for sharing the module and the background behind it.