adrian

Just wanted to wrap this up and let folks know that the problem that @Christophe discovered has been fixed.

Hi @fablei - sorry for the rough start. Can you tell us if it makes a difference if you upload the image to the images field directly, rather than via the CKEditor upload? If that works ok, what about if you subsequently insert them into a CKEditor field and save the page again? Also, is there any difference if you upgrade to the latest stable 2.7.2, or the main dev version 2.7.3?

Just wanted to wrap this up and let folks know that the problem that @Christophe discovered with AdminRestrictBranch has been fixed.

Just wanted to wrap this up and let folks know that the problem that @Christophe discovered with AdminRestrictBranch has been fixed.

I see that PW is using the procedural date() in many places, rather than Datetime() which supports dates before 1901: http://stackoverflow.com/questions/18579567/change-the-format-of-dates-before-1900-without-using-explode I wonder if this should be a Github issue? EDIT: https://github.com/ryancramerdesign/ProcessWire/issues/1624

I am also one of those weirdos without a Facebook or Twitter account - I'd much rather read the PW forum or Github activity. That said I am often accused of staring at my wife's computer when she is looking at friend's photos on FB, so I guess I am a social media voyeur rather than exhibitionist.

Thanks for those settings - everything looks normal for using the "specified_parent" option. I wonder if the "Branch parent to restrict access to" setting on the user's setting page was set to something unexpected before you changed it to "home". Can you try resetting it to the desired branch to see if the problem returns? If it does return I wonder if you'd consider giving me access to the PW so I could investigate if there is some strange conflict?

@Christophe - sorry you are having trouble - I am curious about "all of a sudden" - I feel like something must have changed. I did add some new functionality yesterday, but this shouldn't be an issue - what version of the module are you running? Did you update PW or anything else between when it was working as expected and now? I don't really understand this - "restricted to everything" - does that mean the user is restricted from access to everything or that they can see everything when they shouldn't? I see in one of the threads you linked to that you are also using code in your ready.php - is the problem still there if you remove that code? @adrianmak - no it doesn't support multiple branches - it would have to be re-written completely for that and there are some core PW issues that would currently prevent this from working perfectly. It is also not really the goal of this module - it was designed for sites that have user specific parent branches - it is not really for hiding or restricting to a variety of sections. You might look at: https://processwire.com/talk/topic/1176-hiding-uneditable-pages-from-users/?p=84916 as a usable but not ideal solution. I still don't fully understand what is going on - does restricting to the homepage mean they now have access to everything, but before they weren't getting access to anything? I wonder if maybe there are some config setting being left in the system that are conflicting? Can you post the contents of the data field for module's settings - you'll need to get this via PHPMyAdmin or similar - modules table - grab the entry for this module - maybe there will be a clue in there?

@Gideon So and @regesh, I am pretty sure this is a bit of an abandoned experiment - it was never officially released in the modules directory, so I don't think it will see anymore updates. Also @kongondo has a new module that will do all this and lots more: https://processwire.com/talk/topic/11224-media-manager/

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.