Soma

Quick and dirty? There you go with a simple module, but maybe not the real and best way as if it could be implemented with a dedicated page custon fieldtype. I thought about having a module that hooks after Page::save and reads two page fields, each is setup to select the template the other lives in. Template: user -> Page field: teams_select Template: team -> Page field: users_select teams_select can select user template page and vise versa. So now you'll need to check on every save those two templates and fields and remap them. This requires to go through all pages and make changes. This is like many to many but with not mapping table. Maybe I don't see anything obvious. But I think if you not go crazy with amount of pages, it should work well. Example code in the Page::save after hook: Removed previous code. Added gist snippet: https://gist.github.com/4335296 Not tested, but it should works. Maybe not the best but you know it.

For sure I can, mighty Pete!

My way was or is always to look at ryan traces of it in the core source. After all it also uses same api and structure. The wire tabs also took me a moment to see javascript is used to init them.

I think what he means is that the error isnt user friendly and may should output a page like the 4o4. Nut that makes sense or if i understand it wrong. After all it an db error that isnt same as a page not found and shouldnt be threated as the page is actually there. My error message is the one i get per email. And its a db connect error that has nothing to do with pw directly and a problem of the host. Though havent looked or asked the hoster yet. It happens occasionally and we already discussed thsi error in a thread where you said you will provide a better error message. Could be wrong though.

I just wanted to mention you can reuse fields and change label and descr in the template context. I would recommend also to reuse aa much as possible and let title summary and body. This also makes it easy to search selectors to use body in all pages instead of multiple. Theres no advantage in creating new field in evry new context than rather disadvantage. Performancewise I cant see any dis-/advantage. Regarding comments you can of course use/build your own system very easily with pages. Many done, Ive done it and yes use body everywhere where you need a body. Also if pages are comments. Sorry am on mobile...

Probably ur child pages are only found if you add include=all to the children() . to list pages a user dont need access or edit rights to list pages.

Dont forget fields also have template context.

$pages->find('wh_mitarbeiter_kategorien=/portrait/mitarbeiter/kategorien/{$segment}') 'strings' won't get parsed in php try "strings"

Welcome DV-JF Don't worry, you're not alone What are you using to make the menu hovers/dropdown? Bootstrap? 1. No, there no option to have placeholders. 2. You could do that with JScript (prevent click etc) I'm playing with implementing some placeholder template option. Still have to figure out the details. But since I don't really need it and am cautious to not add too many options, this could take a while.

... the video?

Some useful threads:

Why not? If not that what do you have in mind. PW is done to do these things easily. If not that I don't know what else Actually you can just create your own ProcessMyList.module (copy ProcessList.module) and then install it. Open admin page "Setup"... change the selected Process "ProcessList" to your "ProcessMyList".

Yeah I think so. Hook ProcessList::execute and replace it with your own. And add fields to admin template for description or images

Just recorded a video of a larger Site I've done some already know of (in this forum). Since a long time I wanted to share something, that maybe of use to others, so here it goes. It shows some technique I use often to give shortcuts to editors when editing content on the page. It's ideal to use for summary entries to give them a direct edit link, or for data pages that have no real view and are located somewhere else in the page tree. Basicly it's simple and just requires to add Fancybox js to the front-end, and you may already have it, or if now use another lightbox that has iframe capabilities. Also if there's not lightbox plugin you need in the site, just load them conditionally using $user->isLoggedin() check. Then generate simple edit buttons/link where you like, and add a "?id=1001" to the url PW admin edit url (/processwire/page/edit/). You can do this without fancybox modal as the default basic-install shows, but using fancybox can make the experience a lot better. To have the navigation of the admin not shown you just add a &modal=1 to the url. Code to generate the year link seen in the video is: if($user->isLoggedin()){ foreach($chart_years as $year){ if($year->editable()) { // if editable by user. echo "<a class='editpage-inline' href='http://" . $config->urls->httpHost . $config->urls->admin . "page/edit/?id=". $year->id ."&modal=1'>edit ".$year->title."</a> "; } } } Then in your JScript you would add fancybox functionality to the links like this. $('a.fancybox-iframe, a.editpage-inline').fancybox({ type: 'iframe', centeronscroll: true, autoScale: true, width: 900, height: '80%' }); Minimal effort, maximal effect.

Your first solution is the only I see and it isn't possible to have display translated here but not there obviously. A process module is put where module put's in on install, it's not in setup always. If you put in in main navigation you can set a title via the admin page itself. The Setup page has the ProcessList module that lists them by module info title. So you would have to change that module. But I'm sure you know it already.

Fancy Admin Mode Just had a little funwith fancybox iframes, and created a little module that opens all admin links (topnav links, edit, view, new, copy actions) except "Pages" screen and "Site", "Search" in a FancyBox, so you'll never leave the page tree. It even works with inherit editing child pages. Download: https://github.com/s.../FancyAdminMode Little screencast to se it in action:

Joss, you forgot the excellent Cheatsheet! Invaluable tool and reference on one sheet, it was the first thing I did when starting working with PW. The API docs where too much spread out and inaccessible. It was great as there was no need to write long Texts, only copy paste it from the API documentation. Also we shouldn't forget what newcomers and not so coders struggle with: Fieldtypes Images and Pages, and how they're handled. I.e. The single <-> multiple difference. This basic understanding has come up a gazillion times and everytime you find yourself explaining the same thing over and over. . The second most thing that comes up IS NOT PW related but, raw HTML JS and PHP things, that has nothing to do with PW at first. I can't see much else where newbies struggle with except maybe with plain PHP and coding as general, which I think goes maybe to far to cover all this in a PW documentation. One thing is how to SETUP a field which is already covered inline in PW itself a good part! And the other using it in code and understand technical backgrounds and best practices in making front-end code. For me this is where it get's interesting, but has not much to do with PW at the end.

Glad you found a good way to do it. Noticed this $this->_('Too many '.$type) Won't work since you can't add variables to the translatable _() strings

Permissions are inherited. If you dont define it on children it will take from the next parent. So usually you give it once and disable edit rights explicit.

There's no option for that. Sure API sounds good. A quick glance at ProcessTemplate.module shows how it's done. With this code in a template and call it once. $tmpl = $templates->get("basic-page"); $editor_role = $roles->get("editor"); $editRoles = $tmpl->get("editRoles"); // currently set roles $value = array(); // assign already set roles foreach($editRoles as $v) $value[(int)$v] = (int)$v; // add new role to it $value[(int)$editor_role->id] = (int)$editor_role->id; // set editRoles property and save $tmpl->set("editRoles",$value); $tmpl->save();

Sneaky Niki you. I didnt even notice this thead before. Nice! Havent tried but at least a dozen optones are missing. ;-)

Just pushed an update. update to version 0.0.3, some improvements and refactoring - Improved a lot on some page/user fields parsing to give better and deeper results with page fields and file fields. Also shows now fields that are empty and writes "null" in the log. - Fixed issue with some in admin request getting logged still. I can image something with getrusage() on your hosting having a problem? Not sure though what else.

Since when? Works fine here and have no clue what causes the error on your side.

Validation in a CMS can get really tricky, if you scan enough deep you'll maybe find or read what Ryan says about it and that something is in the pipeline, it's not that you're the first with comming up for this. If you want to do something custom it's easy as pie (found by posts linked): public function init() { $this->addHookAfter("Inputfield::processInput",$this,"validateField"); } public function validateField(HookEvent $event){ $inputfield = $event->object; $name = $inputfield->name; if($name == "sidebar"){ if(strlen($inputfield->attr("value")) > 10){ $inputfield->error($this->_("Too long")); } } } Custom validation for fields, ready with custom error message localized, and if an error is found after processInput the page won't get published. To not save it, well that's where it can get tricky for a system and user. But let's see what Ryan will come up with.

Some reading about the subject. There were some discussion about this in the forums. ... Ryan has some explanation I'm not sure where this was discussed why and what and how, basicly it's not something he needed really (me neither). And only because where in the beginning still, there's for sure some more things happening on this subject. For me it's not a required or important feature for our projects anyway, but it's possible. Also use google to search and not the forum