Soma

Just looks like the menu code isn't generating the menu properly and that if you look at the code source you can tell that there are the profile pages, but they're not showing in the boostrap menu cause no title or just an <ul class="drop-down"> so not valid code? So after all it looks like the menu code has problems (or not), but could easily spot with a glance at the console or html source... Just looking at the "/profile/" page it has no title field? So sorry but check your code and don't worry about PW setup or something.

I just tried on your site and I'm not sure I see what is exactly not working, it's all working fine. I can login and see profile page (actually am on profile page). So what exactly is not showing that you think it should, and post your (all) code related to that, not just the menu function because that works fine.

Let's keep conv. in thread and not in PM. How would that matter? I just changed the /profiles/profile1/ page to use profiles template too and there's no change in behaviour. Permission are inherited in PW so child pages inherit permission from parents. Not that it really matters here but it's good to keep in mind. Maybe it's me or you're not communicating clearly and with all details, but there's nothing really obvious that I see but then I maybe don't see/know all.

Yeah but that's just an option and nothing to do with your problem. Unless your custom login, doesn't log user in.

Took 10 min (ok 20min) to setup a site with this setup showing that it works just fine. http://lithium-r3t.lightningpw.com/ If you go to site http://lithium-r3t.lightningpw.com/profiles/ You'll get to login (not 404 as default), member member123 is a member user Once logged in you'll see the profiles page and the profile page under it in navigations. I added the menu code you posted in the profiles page, but you can also confirm it by the top default navigation or the sitemap. I sent you a admin login PW so you could see the setup (as you posted).

I think your op is confusing cause you now say userprofile template has view access removed for guests. Yet your screen shot indicates clearly the profiles page is restricted by the lock icon. Not sure if that helps. So your profiles page wouldn't be visible when not logged in but visible when logged in. An all user profile pages are then also viewable. Just judging from the screen shot.

Maybe we should make bug and issue reports have PW version mandatory or we just ignore them.

Your first post shows only profiles template. Not sure what profile. However I set up the same thing and used your function to create a list and it works fine as it should. Maybe we need to see all settings and whole code. Or you just need to try harder cause it isn't magic and just works.

Just a small detail but for "behind" the scenes hooks and such thing you don't need a Process module. Those are for admin pages that have a process added (the module). The ___execute is for returning markup that should show on the admin page with this process. You would create a simple WireData module like the HelloWorld.module. And you don't need that ProcessPageTrash module, that is also an admin page to delete trashed pages. So you need a WireData module that autoloads, Process module shouldn't ever be autoload. autoload on a selector "process=ProcessPageList" doesn't work, and if at all I think it's not suitable cause that's a module working mostly with ajax. Not 100% sure without trying. autoload=>true should be sufficient. You check anyway what you want to delete and already add the hook to users. $this->users->addHookAfter('delete', $this, '___execute()'); // is this correct This is a hook for when a page was deleted, but afterwards, so you never know what page was deleted. May it would be better to use addHookBefore("delete", $this, "hookDeleteUsers"); Then not "___execute()" but a custom function, and you use the $event to catch the page being deleted public function hookDeleteUsers($event){ $userpage = $event->arguments("page"); if($userpage->id){ // do some stuff example $userPage = $pages->get("created_users_id={$userpage->id}"); $this->pages->trash($userPage); } } http://cheatsheet.processwire.com/?filter=trash

Just to make clear my approach is just the way I prefer for members to a site only having their profile and maybe see things when logged in. The view permission is great for that and I keep things flexible on a per page or situation where not possbile with template permissions. Page edit permission isn't necessary really as they don't edit pages in "admin", if then I create forms tailored to the needs. Page editing isn't needed cause I edit them via API and not the page edit screen from the admin. Note that the new Dynamic Roles module may open up a lot more possibilities to fine tune permissions, but then I still wouldn't use that for simple frontend only users. Not saying it's not possible. About navigation, I'm not sure I can follow you. If a template (page) has guest view access removed, it doesn't show in navigations for guest user. One logged in with a role that has view access on that template it shows up. As explained in my post above. There's some settings on the behaviour one you untick the guest view access on a template below, like show 404 or redirect to a url etc and if pages with that template show in lists or not.

The approach: I'm not sure what really those front end user are and what they're for and what all they can do. Usually members that only interact on front end are members of some sort and not editors, they are not backend users. What I always do is not give them any page edit permisson or anything alike, just view access like a guest role. Then in templates use their role and $user->isLoggedin() && $user->hasRole("member") to conditionally give them what they need. For example show a login link, or a Profile link in a metanav, depending on user status. Backend user roles and permission are mainly for backend users, and I don't want to mix that up. I built specific forms and front-end pages solely based on what role a user has and if logged in. I have member pages with they're data stored in some branch and have a one "Profle" page that is used to build forms of they're profile with data they can edit. I don't need any page edit functionality of PW backend at all. This way I can specifically build functions and logic around what is needed without being caught in what PW is doing designed for backend usage. Also note that as soon as you give edit permission to a role they can access the admin, and you need to take care of that aswell. I tested a setup like you mention and it's working fine. If you have "profiles" template not giving "view" access you see a expanded settings at the bottom what to do when a user accesses this page. Default is showing a 404 page and that those page don't list in navigation. Now it depends how the navigation is built via API. It's still possible to load that page via API explict and show it to a not logged in member. But not showing in lists means for calls like children() and find() etc. I tested your menu code and all working as expected. $content .= renderChildrenOf($pages->get("/")->children); The profiles page don't show (when not logged in with that user), and show up when logged in.

Just have committed a little update and added the new category "Premium Modules" to exclude list, so they're not downloadable (cause they're commercial) http://modules.processwire.com/modules/modules-manager/

Just fixed some issue with new PW 2.5 while still compatible with 2.4. The module is now on v1.0.3 and updated on modules.processwire.com https://github.com/somatonic/TemplateNotes/commit/7a16e25126d1f2b2ef2b4792edc00f70b9c2db1b

There looks like there was some changes to the way the page edit form is built or css related. I just build a new wrapper and append it to form. The wrapper gets inserted at the end, but since the submit button is also a inputfield added to the form it is before newly added tabs afterwards the form is built already. I tried and found that prepend the wrapper to the form works around this issue (until next time). While at it I found a missing CSS class in Reno in 2.5.3 where hidden labels would show in the forms. Regarding tabs. I'm not sure if that's really a long term "the best way" to add tabs, I also tried to find a way using the $this->tabs used by ProcessPageEdit but that is protected and after all maybe not suitable to add tabs at certain position since you never know what there will be. A float right hack with css would position the tab at the right, but I don't know if that's maybe used by some other theme already and so on. So no real dedicated fool proof way in PW I guess. I'll see if I can test this with 2.4 and or 2.3 and release a fix.

Yes correct, it's limited to 350 currently by Ryan. Yep that was added by Ryan some time ago and looks like processwire.com got an upgrade with that also, but it's currently working for me. Not sure if he changed it.

PW template and fields system isn't meant to be used in such a way. It won't scale as for each field it will create a new table in db. I'm not sure the exact reason for this but looks like you try to bend pw too much in a way it's not meant to be used. If youre for a site builder system you might consider cms system that is designed for it. My recommendations are the one in the thread you linked too so no need to repeat here.

So you're saying the user will create new pw fields for every new input he want to enter on a page? I don't think that's a valid approach.

What does that output for you when directly grabed? echo $pages->get("/about/")->children; echo $pages->get("/about/")->children->count; what is this rooparent "navigation" you get the

What if there's no such image? I think it's not about making it shorter but more fool proof. <?php if($page->images->count) { $image = $page->images->get("name=logo.jpg"); if($image) echo "<img src='{$image->width(200)->url}'/>"; } ?>

It just can't be. Make sure you're on the right install/page etc or something.

What about this in core?

Something like $album = $pages->get("template=album, yourpagetable=$page"); $track = $album->yourpagetable->find("track_group=2194");

Have refreshed the modules cache? It may has to do with folder/file dates, as there was something added by Ryan which caused problems fro others, but can't remember and never had an issue.

It's right there, have you installed it? https://github.com/ryancramerdesign/ProcessWire/tree/dev/wire/modules/LanguageSupport

Ah ok. On a sidenote: It's recommended better to use add and remove status not just status = status cause it's a bitmask and it can have more than one status. $page->addStatus(Page::statusUnpublished); https://processwire.com/talk/topic/1293-how-to-set-unpublished-for-a-page-in-the-api/?p=11538