Soma

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

You shouldn't exit (actually never) but use a flag ... if($page->skip) return; $page->skip = true; $page->save(); ...

Save hook save hook save hook ... Add a flag to the page on first save and check for it to terminate.

The pagetable stores the ids of the track. It's like a page field and you can use it to find the album the track is on.

You don't need a reference as you already got one, it's the pagetable. You can get the page the entry belongs to via API find.

The try catch is only a workaround for the Login Throttle... If the login isn't correct, you would do output a message somwhere in the if($u && $u->id){ $session->redirect("/somepage/"); } Like if($u && $u->id){ $session->redirect("/somepage/"); } else { $error = "Login failed"; }

I've filed already a couple related issues with AIOM on github but no reaction so far since months. I think it's possible that minify html option causes it? Does it work when in dev mode?

I'm using the page=image as with ImagesManager in some big project where there is or will be 100'000+ of images to manage. I have then built a fieltype I can select and insert them to a page from all those via filtering/search (ajax). We never insert image into a textarea via TinyMCE or CKeditor image dialog because it's cumbersome to use and manage, we rather use hanna code to have them inserted in a more controlled way (if at all), but often the better option is to use PageTable or repeaters to create block with text and image. This system is ultimatively flexible and PW provides all the foundation to use it how you want and need (unlike any other CMS media system). It's just a matter of creating some simple modules that may help you in that regard. PW is still in it's beginning and will certainly grow in that regard with modules that help with asset management. I just don't have the time to spend on that to share with the community. But time will tell.

I'm not sure I can follow you. *confused* I think it's a matter of terms. To be more correct in PW termns there's Fieldtype and Inputfield. Fieldtype is more like the model while the Inputfield is the interface to the user, meaning resposible for rendering the value and inputs of a Fieldtype. Forms are build out of Inputfields. Now a "field" (if using the more general naming) added to a form (InputfieldWrapper) always has to be of type "Inputfield" . The error you got: You try to add a NULL to the form as the second argument! Now looks like your form get() call doesn't return a Inputfield but NULL so it's not found maybe. But you can easily test that. But you might know all this already. I'm not sure I understand, What "both"? InputfieldFrom (InputfieldWrapper) only allows Inputfields to be added, and not Fields (Fields as you get per a call like $template->fields. If you try to add those you get an error.

In forms it's always inputfields there are no "fields". Works fine so it must be something you're overlooking.

As far as I know you can only use showIf dependencies with fields, not page id's etc.