adrian

You may potentially want to revisit repeaters now that they are collapsed by default and AJAX loaded - there should be no more performance issues: https://processwire.com/blog/posts/more-repeaters-repeater-matrix-and-new-field-rendering/ Although to be honest I still think I would use pages for a staff directory because I like being able to have a direct URL to each staff member.

I know this is a little old, but perhaps this new module might help with the multilanguage issue: http://modules.processwire.com/modules/process-setup-page-name/ Have a read of this message in the support thread: https://processwire.com/talk/topic/8576-name-format-children/?p=110656 - maybe posting a followup there might also help to motivate kixe (the module author) to work on the multi-language stuff.

They don't really go together - ASM multi should be set to multi, but maybe I am misunderstanding. Anyway, glad it is working for you now.

In some cases it doesn't matter, and in some cases it does It depends on the scope and class context as to whether $this->user->name will work or not, but seems to have been common practice in various modules. With PW 3.x ramping up I would suggest reading this: https://processwire.com/blog/posts/processwire-2.6.21-upgrades-comments-more-on-pw-3.x/#more-updates-on-processwire-3.0 - scroll down a little to the "Multi-instance with 3rd party modules and PW 3.x" section where it explains what works where. Actually this is a good reminder for me to update my modules to use $this->wire()

Hi Charles, That is the expected output from the ProtectedMode module. I don't know all the inner workings of isit.pw, but I doubt it will be able to detect a ProtectedMode site. I have actually considered this as a desirable thing given that I usually only use protected mode during development. This is OT, but if you are wanting to protect your site long term, but PageProtector might be better as it provides the option of using your own custom template and embedding the login form within your site's html template. This may or may not help isit.pw to detect the site correctly depending on what is in your template. I also wonder how much testing of PW's "it" GET variable is used by isit.pw in which case PageProtector may be no better, although I am not totally sure.

Depending on how you have the page field configured remember that you might need first(): $page->sideBarURL1->first()->url;

I was wondering about that actually - how the id of the page could match the category id Good question - it is possible, but you need to do things a little differently. Try the following in the custom selector option - not the custom PHP option: parent=page.category

Is the category page field's "Dereference in API as" setting set to Multiple or Single?

Try: return $pages->find("template=subcategory");

This is consistent (although not intuitive) throughout PW. You need to click on the selected page and click "unselect". If you don't like this behavior, there is a new module that makes things more intuitive: http://modules.processwire.com/modules/page-list-select-unselect-button/

Actually I hadn't noticed that - thanks for pointing it out. Sorry it's taken so long to get to, but the latest version of the module now has a new config setting to optionally exclude pages outside the restricted branch from the search results of pages. Please test and let me know if you find any problems.

Looks like it might just be for 3.0 "This PW version is also the first to support ProFields Repeater Matrix" https://github.com/ryancramerdesign/ProcessWire/commit/eb8aa2f953154e34924081fcfc0f07bd748ceead

@Christophe, I am not sure about this module with repeaters, but the built-in field-level access control seems to work great with repeaters. If you have PW 2.6.2+ there is an "Access" tab for each field (in the field's settings) that controls which user roles can see and edit it. Does that take care of your needs?

Oops - I should have noticed your comments there. I actually didn't think about them not being added until the field is viewed in the editor. In reality when I have a PageTable field with the pages as children of the page, I just call the children, rather than the PageTable field, so it doesn't actually matter that they are not added until the editor is rendered. Perhaps that code could be changed to work on page save - check if the parent has a PageTable field in it and then check if the saved page belongs to the field?

Have you tried this: https://processwire.com/talk/topic/8177-page-table-howto/?p=89960 Not that I am suggesting you should use PageTables if the new repeaters work as required, but that does provide a way to have the new pages automatically added - I use it when I want separate URLS, but the client is confused about not being able to edit under the main parent page - like a list of staff for example.

Are you sure you only have Protected Mode installed? I wouldn't be surprised if there were some issues if you have both modules installed.

I think this: https://processwire.com/talk/topic/1176-hiding-uneditable-pages-from-users/?p=84916 is currently the best option for hiding specific pages from the admin tree, but I do agree that something better integrated in the core would be very useful.

Have you cleared the compiled templates? Modules > Site > Clear Compiled Files I think the error you are seeing is from a cached compiled template from before the problem was fixed in 3.0.4

You need to change the custom message on the Settings tab of the Home page. The message on the module settings page should populate newly added protected pages, but once a page has been protected, it stores its custom message separately. Let me know if you still have problems. I assume that the login template option is now working for you with the latest PW 3.x build?

Use sort in the children method like this, assuming the date field is actually "date": if($page->hasChildren) { $content .= renderNav($page->children("sort=date"), array('ul'=>'article-index list clearfix', 'li'=>'article-index__item'), 'post_date'); }

And the saving as "No" should be fixed now also! https://github.com/ryancramerdesign/ProcessWire/commit/c485972f70bc436bc203ceefb22bbf314ed826fd

The undefined variable error has been fixed in today's commits to the devns branch.

It was a bug with the File Compiler in PW 3.x - it has been fixed in today's commits to the devns branch. That does seem weird - the custom message should be between the <legend> tags. Can you provide a screenshot of the settings tab for the page in question?

Great work Bernhard! I think this should be in the core!

Fantastic writeup Ryan! Looking forward to an amazing new year with ProcessWire!