Leaderboard

@DrQuincy, responding to the title of the topic: PW allows for access control at the field level as well as the template level. I don't think you need to do anything special with repeaters or child pages to achieve what you're describing. In your template settings: Do you want to manage view and edit access for pages using this template? > Yes Allow view access for "guest", seeing as you generally want the page to be viewable by everyone. Prevent direct access to file assets owned by pages using this template? > Yes always, regardless of page status or access control In the fields listing for the template, click to edit the files field in template context. Enable access control for the field and remove view access for "guest" (and any other roles who are not allowed to view the files). Now guest users will be able to view the page, but not access the files.

Interesting. I tend to handle Repeater Matrix items with /site/templates/fields/ files, so not sure if I've actually attempted this 🙂 If you're doing this in the context of another page, one option might be using Wireframe::page(). I seem to recall having used it for rendering Repeaters. Though not sure if that's exactly what you're looking for here?

This week I’ve been working on some useful additions to our Markup Regions system, but I don’t have those additions quite ready to commit to the core just yet. Hopefully next week they will be ready. What it involves is the ability to populate regions within CSS, JS, SCSS, LESS files. So I might output a <style> tag in my markup (for example), but the styles go into a CSS file rather than in the HTML output. That CSS file combines and contains all such instances, and can then be loaded from a dedicated <link> tag in the document head. You could do the same with JS, but using <script> tags instead. I’m not sure I’ve explained it well just yet, so I’ll have a better description of it next week, along with some practical examples. It’s very simple and I think examples will make it obvious. Stay tuned, have a great weekend and thanks for reading!

Field Access A Process module that provides an overview of field access settings, including template overrides. Usage The table has a sticky header so that the columns can be understood when the table is scrolled. The empty space underneath the table is to allow scrolling to the bottom of the table. There are fields for filtering the table by field name or by template name. The field names link to the Access tab of the field settings, and the template names link to edit the access settings for the field in the context of that template. A collapsed field at the top of the page has information about the meaning of the table column headers, and tips for understanding the values in the table: Table column headers Control: Is access control enabled for this field? View: Roles that can view the field Edit: Roles that can edit the field Show: Show field in page editor if viewable but not editable (user can see but not change) API: Make field value accessible from API even if not viewable Overrides: Overrides of the field access settings in template context Tips If the guest role has view access then it means that all roles have view access. You can hover the guest role in the View column to see a tooltip with all the role names if you want a reminder of those. Overrides: when access control is enabled as a template override, the Control, View, Edit, Show and API columns only display settings that are different from the field access settings. If a column is empty it means the field access setting applies. https://github.com/Toutouwai/ProcessFieldAccess https://processwire.com/modules/process-field-access/

I like NativePHP. I like Laravel. I love ProcessWire. I'd rather use ProcessWire to build desktop apps. Now it looks like I might be able to! Very early days.... https://bosonphp.com/ Hopefully it catches!