Robin S

I was running quite a recent version (only a few weeks old) but not the very latest. Upgrading to the latest has reduced the number of times the textformatter is called, going from four times down to two times. This is not including any field usage in the template file (i.e. I don't get the field value in my template file, so without the Request Info panel active the textformatter isn't called at all). So it's quite an improvement, but still being called one time more often than I would expect. This is the textformatter I'm using for testing: <?php namespace ProcessWire; class TextformatterTest extends Textformatter implements Module { public static function getModuleInfo() { return array( 'title' => 'Textformatter Test', 'version' => '1', 'summary' => 'Testing', ); } public function formatValue(Page $page, Field $field, &$value) { bd('formatValue'); } } The rest of the setup is basically a clean installation of the blank profile. I can definitely live with it as is, but I'll PM you login details for the test site in case you're interested in investigating.

Hi @adrian, I was doing some testing with a textformatter module and was wondering why the formatValue() method was firing so often, even when my template file does not get the field with the textformatter applied. I traced it back to the Request Info panel - when this panel is active the textformatter formatValue() method fires four times (not including any usages of the field in the template file). I see that the panel shows the value of each field in the template in the "Field List & Values" section, but I would have thought this would only account for one firing. Just wondering if something in that panel is getting the field values more often than necessary and could be optimised perhaps?

Not sure if that was a reply to my comment, but Adrian's idea isn't working when I test it with sort settings applied to the parent page or template. I think it would have to be something like this: $parent = $this->editedPage->parent; if($parent->id) { $sort = $parent->template->sortfield ?: $parent->sortfield; } else { $sort = 'sort'; } $first = $this->editedPage->siblings("sort=$sort, limit=1")->first(); $last = $this->editedPage->siblings("sort=-$sort, limit=1")->first(); Getting a single page could be simplified with findOne(), but not sure if you care about supporting < PW 3.0.3 scratch that

What I meant is that they have to learn how to use the core link dialog regardless because I'm sure they'll need to create non-file links, and then they have to also learn a different method if using this module for file links. Glad you have it working how you like. This module isn't likely to get many updates now that it is merged into AOS, but bear in mind if you do see an update available you will need to either avoid updating or reapply your changes to the updated module files.

I have a feeling this won't work where a sort setting has been defined on the parent page or template. When that is done the sort property of the child pages does not change, so doing a reverse sort on that property would result in the wrong order.

@Arcturus, this module's functionality has been merged into AdminOnSteroids. If you are a user of that module it might be better to post your request in the support thread for AOS. If you're not an AOS user then I guess I could make a config option to reverse the click/Alt-click behaviour. Let me know. I'm not keen to go down this road. There are a large number of attributes a link can potentially have and I don't want to try and support them all. This module is intended as a time-saving tool for power-users who are tasked with loading/editing large amounts of content - I have in mind the superuser who must do an initial loading of content supplied by a client. The module isn't intended to be a full replacement of the PW link dialog. For anything beyond what this module provides I suggest you use the link dialog, or perhaps a textformatter module to apply link attributes like target in a systematic way. TBH, if my clients were 60+ and not all that computer literate I would have them stick to the core link dialog so they don't have to learn something new. Edit: you can also add a target attribute to internal file links via a simple piece of jQuery on the front-end: // Add target attribute to internal file links $('a[href^="/site/assets/files/"]').attr('target', '_blank');

For any field that references a page, the syntax to access and search content in the referenced page is the same. You use dot syntax in the form page_reference_field_name.field_name. This applies equally to Page Reference, PageTable and Repeater / Repeater Matrix field types. So if you use a Page Reference field called "social_networks" that contains pages for Facebook, Twitter and LinkedIn, and those pages contain a "body" field that you want to search, your selector would be: social_networks.body%=foo This will match the page that contains the social_network field rather than the referenced pages. So exactly what you are wanting to do.

Yep, sounds good.

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