Robin S

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.

Thanks @BitPoet! I think there might be some typos in the mutator example - maybe you meant: $blogposts = $pages->find("template=blog-post, sort=created"); $grouped = $blogposts->groupBy(function($pg) { return array(strftime('%Y', $pg->created), strftime('%m', $pg->created)); });

@ridgedale, the essence of your scenario is that you have some newsletters, and for each newsletter you have: 1. A file 2. Some metadata about that file (its month and its year) You want to associate the metadata with the file. Using a file naming scheme and a folder structure is one way to associate the metadata with the files, but it's not the only way, nor is it the "ProcessWire way". The ProcessWire way is to use pages and/or the metadata fields that are built into File fields. If you have a lot of metadata to associate with a file then the most powerful approach is the "one page per file" approach, which is what @LMD is suggesting. This way you can use all the available PW fields in your file page to store different kinds of metadata about each file. But the downside to this approach is that the UI/workflow can be a bit less than ideal for clients, especially if they have a lot of files that they want to upload at once and populate metadata for. That's because, generally speaking, they will have to edit each file page individually (although there can be solutions to this such as Lister Pro inline editing, Batch Child Editor, and automatically creating a page for each file similar to what is done in AutoImagePages). But you only have a little bit of metadata per file so I don't think you need to go this sophisticated. Instead I suggest you use a repeater for the years, and file tags for the months. See these screenshots... Then you can get the latest newsletter like this... $newsletters_page = $pages->get("template=newsletters"); $latest_year = $newsletters_page->newsletters->find("newsletter_files.count>0, sort=-year")->first(); $latest_newsletter = $latest_year->newsletter_files->sort("-tags")->first(); $month = substr($latest_newsletter->tags, 3); echo "<a href='$latest_newsletter->url'>$month $latest_year->year</a>"; The pages that visitors browse the newsletters through can be completely decoupled from the storage of the newsletter files. You just get the relevant repeater items by year according to the page being viewed, e.g. $years = $newsletters_page->newsletters->find("year>=1980, year<1990, sort=year"); You could even do it without actual pages for each decade, and use URL segments to get any range of years.

@bernhard, you are of course free to put whatever you like into your modules. However, having your modules "phone home" like this discloses data that users may not want shared. At the minimum the website URL is disclosed. Not every site that exists on the internet is intended for public access. There are things like staging servers, and probably a whole range of other sensitive sites. My personal opinion is: 1. I think there should be a very clear and prominent statement so that users know that the module will send data to a third party, and what data will be sent. And I'm not sure that only a notice in the module readme would be satisfactory because users might download via the PW admin without seeing the readme. And if you start adding this to existing modules that didn't have it before it could pass by unnoticed when the module is updated. Basically there needs to be informed consent before data is sent, and probably also a privacy policy. 2. I think this crosses a line that shouldn't be crossed, and sets a dangerous precedent that if followed by others could be harmful to the PW project/ecosystem. There is a huge amount of trust placed in third-party modules by users. Modules can potentially access any website data. The very notion that a module phones home erodes trust. We don't want to create a sense of unease where every time a user contemplates installing a module they feel like they ought to comb through the source code to see what the module might be disclosing to a third party. In the bigger picture, I'd like to see PW get a reputation as being a system suitable for large institutional and government clients. Here in New Zealand, SilverStripe is in the enviable position of being seen as the go-to system for government websites. I think PW should be competing in this space. But government and institutional clients won't touch PW with a pole if there is a perception that there are privacy issues with modules in the PW ecosystem. I think the right way to track software popularity is by counting downloads, not phoning home. Sadly GitHub and GitLab don't provide useful tools for this, but that is another discussion.

PW does not really use the concept of folders. I agree with @flydev - you should use pages in place of folders. I've used a repeater for doing something quite similar to what I think you are describing. Create a page that will be the central place where all files are uploaded. Add a repeater to that page's template, containing an integer field for year and a files field to hold the uploads. Users will upload their files to the relevant year item. Using API code you can get the most recent year (i.e. the highest integer) and the most recently added file in that year (the last file in the field). For automatic upload renaming there is @adrian's Custom Upload Names module.

Would you mind clarifying what you mean here? Are you saying the PW modules you share here with the community might start sending data to your Google Analytics account?

You have to check from the module which has its class name stored in the modules directory. For Hanna Code this is TextformatterHannaCode (not ProcessHannaCode). For modules such as Hanna Code that contain additional sub-modules the simplest way to update is probably via ProcessWireUpgrade - then you don't need to think about which class name is the one stored in the modules directory.

Hi @adrian, I'm seeing an issue in the Console panel where the indentation (tabs) of saved snippets gets lost when the page is reloaded. In the screen capture below I save the snippet with the correct indentation and I can load that snippet again okay until I reload the page. After that the snippet doesn't load with the correct indentation.

Not sure what you mean here. When you use the feature I mentioned to select a page that will hold the default value for the image field, the image field will have the value of the default field when it is empty on a particular page. The value will be a Pageimage object or a Pageimages object depending on the field settings (and assuming you have one or more images in the field on the page used for the default value). You shouldn't need to do anything different to get the object or any of its properties (url, etc) than you would do if the field was populated on the page. In other words, you can do something like... $page->image->size(400,300)->url ...and it will work the same regardless if the image is coming from an image that is actually in the field on that page, or the default value when the field is empty.

There is a feature for this built into image fields (Details tab):