Robin S

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.

I'm not saying I think you definitely shouldn't do it the way you are - it's just that the extra page for users feels a bit redundant to me so my instinct is to try and avoid it where possible. This part will work fine without the extra pages, just directly selecting the user. This is probably the most persuasive reason for the extra pages, but I think if it were me I would still avoid it and deactivate the ability for old staff members to log in rather than delete them. This can be done by giving them the "login-disabled" role: https://processwire.com/blog/posts/pw-3.0.86/ This part I would do with URL segments on the "authors" template, matching the URL segment to a user name.

With what I was proposing you don't use the created_users_id at all - the author is always identified via the Author field. You can make it a required field, and even have it default to the current user with a hook to Pages::added() if you think that would be useful (I can explain that more if needed). One thing I'm not understanding is why you are creating extra pages for users when a user is a page already. Regarding the module naming, it's best not to use "Process" in the class name because your module doesn't extend the Process class.

Working great, thanks!

Thanks for sharing! I haven't used that blog module before so maybe there are different requirements there, but I have handled a similar situation like this... You create a Page Reference field for Author, and as the selectable pages you allow users with a particular role or pages with the "guest_author" template. So "guest_author" is used for any authors who are not users. The selector string for selectable pages looks like this: And if you want to easily add guest authors from the Page Reference field you can use the Page Field Edit Links module.

Did you find some problems with upgrading sites from 2.x to 3.x? Just wondering why you would export/import pages rather than duplicate the site then upgrade to PW3?

Thanks. Did you push the changes to GitHub? It's still showing 4.9.31 which is the version I was seeing the issue with.

Related issue: https://github.com/processwire/processwire-issues/issues/259 Ryan said:

I thought Google Analytics would log the origin of the event, but I tested it and it seems that it doesn't (unless that information is explicitly passed in the event, and I trust you won't start doing that). So that makes me feel a little better. This isn't true in the instances you mentioned, because Ryan has thoughtfully used the "noreferrer" keyword for the links, presumably because of the privacy concerns we're talking about here. And as a site developer you have control over referrers using the meta referrer tag if need be (in the past I have added this to the admin theme on some sensitive sites). By ecosystem I mean all the software associated with ProcessWire that isn't in the core. Rightly or wrongly, people's perception of a system is influenced by the third-party software associated with it. The WordPress plugin ecosystem is like the wild west, and that's a big part of the reason for WP's poor reputation as a platform for serious development. The PW module ecosystem is as good as we make it. You're absolutely right that the onus is on the user to check what they are installing to their site. But it has been quite nice so far to have a sense of trust that the folks who are contributing modules to the PW community are taking care of privacy and security in the ways that I think everyone expects. I completely get why developers are curious about how many installs, who is using their tools how often, and lots of other things I wouldn't mind knowing myself. I just don't think that curiosity in any way trumps the right of users to control what is being disclosed. Crossing this line to actively sending data to a third party makes me uneasy, and personally I won't be installing any modules that do this.