kongondo

I have tested with 2.2.4 and the "no parent" behaviour is similar to the present; not visible at create ("add") but visible and permissible at "edit" within the "settings" tab...[i.e., ignores "no parent" setting] I still don't get the logic...We'll have to wait for Ryan to chime in

I agree. Like I said, for the "no children" allowed setting, it works just fine; no children can be created using "new" in tree and the children tab is hidden when editing pages using that template. Likewise, logically, I would have thought that the template setting ..."no new pages" aka "parents" would be respected throughout...Unless there is some other thinking Ryan had? But, look at his is comment in the code in the Class Template: I'm going to test with older versions of PW to see what the behaviour was then...or have you tested?

1. Create a page: sitemap will not be available in the templates drop down - which is expected due to Template Family restriction (no new pages) 2. Edit the new page: sitemap is available under "settings". OK, so I thought I'd get an error if I tried to change the template to sitemap but nada! I am able to do it I have also tested with search template... The only Family restriction working fine is "no children"

OK, edit...this is now strange.. When editing the pages (like Dazzyweb said), I can now see all the other restricted templates as well (under settings) and I can even assign them to this page! For instance, the template "sitemap" has family restrictions: "no children" and "no new pages", yet, I am able to assign new pages to this template! What gives?! Uh? Just to clarify...the "no children" bit is working fine; I cannot add children...either via the tree or in children when editing the page since "children" is not visible...So working fine

I have tested on a fresh install.. When creating a new page, all templates where there are no restrictions show up...(basic-page, blue, test)...the latter two being my test ones..

Dazzyweb..., You set up clearly has a problem. Like I said, I have tested this on a site where there are no template restrictions and all the templates load fine. I don't think there are template restrictions in the default profile (except for "home"), so, you should see all templates loading. Edit: It's been forever since I installed the default PW site; let me test with that now, a fresh install and will report back...

Yes, I checked the demo..

I'm stumped. I have downloaded the stable version of PW and tried and it works fine (earlier I was testing with a dev version)...it must be an environment issue, but don't know what atm. I'm using PHP 5.4.22. I think we also confirmed it is not a template access issue...no?

No worries... EDIT: Ignore this; I am overcomplicating things, duh!.....better answer below by Diogo...

..before that...I am wondering whether you have corrupt files...Have you tried with a fresh install (as in getting a new copy of at "wire" or of the whole 2.4)...It seems your issue has nothing to do with PHP version if you have tested with different versions...I am on xampp as well, btw...Any errors? Have you tried with debug=true?

Yes it should..typo on my part....I've edited my code above..

Uh? Oh, I wasn't clear...by architects have no children, I meant the individual architect pages, e.g. Albert Khan, etc...have no child pages..Anyway, I sorted out your issue in the other thread...

Here is a working version...give me two minutes... EDIT: OK, here we go... Edit your search_form.php - add the following code: <p> <label for='search_architect'>Architect</label> <select id='search_architect' name='architect'> <option value=''>Any</option><?php // generate the Architect options, checking the whitelist to see if any are already selected foreach($pages->get("/architects/")->children() as $architect) { $selected = $architect->name == $input->whitelist->architect ? " selected='selected' " : ''; echo "<option$selected value='{$architect->name}'>{$architect->title}</option>"; } ?> </select> </p> Edit your search.php as you did above...but with the modification in the selector....and in the comments // added architect // if a architect is specified, then we limit the results to having that architect (architects field in those pages) if($input->get->architect) { $architect = $pages->get("/architects/" . $sanitizer->pageName($input->get->architect)); if($architect->id) { $selector .= "architects=$architect, ";//CHANGE YOUR SELECTOR AS SHOWN HERE $summary["architect"] = $architect->title; $input->whitelist('architect', $architect->name); } } Edit your CSS to style the new longer search form... Smile...am not such a bad guy

Technically, the code is not the same; one if filtering by a field called "architects" the other by the parent. (i.e., the City).. Hope the below explains this: This is the function findSkyscrapers function findSkyscrapers($selector) { $validSorts = getValidSkyscraperSorts(); // check if there is a valid 'sort' var in the GET variables $sort = wire('sanitizer')->name(wire('input')->get->sort); // if no valid sort, then use 'title' as a default if(!$sort || !isset($validSorts[ltrim($sort, '-')])) $sort = 'title'; // whitelist the sort value so that it is retained in pagination if($sort != 'title') wire('input')->whitelist('sort', $sort); // expand on the provided selector to limit it to 10 sorted skyscrapers $selector = "template=skyscraper, limit=10, " . trim($selector, ", "); // check if there are any keyword searches in the selector by looking for the presence of // ~= operator. if present, then omit the 'sort' param, since ProcessWire sorts by // relevance when no sort specified. if(strpos($selector, "~=") === false) $selector .= ", sort=$sort"; // now call upon ProcessWire to find the skyscrapers for us $skyscrapers = wire('pages')->find($selector); // save skyscrapers for possible display in a map mapSkyscrapers($skyscrapers); // set this runtime variable to the page so we can show the user what selector was used // to find the skyscrapers. the renderSkyscraperList function looks for it. wire('page')->set('skyscraper_selector', $selector); return $skyscrapers; } Expanding that... For architect.php: We look in the field "architects" //the code findSkyscrapers("architects=$page") //is actually saying... $skyscrapers = wire('pages')->find($selector); //which can be expanded as... $skyscrapers = wire('pages')->find("template=skyscraper, architects=$page, limit=10");//find pages whose field "architects" == this architect (e.g. John) For city.php, we look for children pages of the page we are viewing, e.g. New York...i.e. the parent. It also says this in city.php The code... //the original code findSkyscrapers("parent=$page")); //can be expanded as such... $skyscrapers = wire('pages')->find("template=skyscraper, parent=$page, limit=10");//find pages whose parent is this page (e.g. New York) Hope it now makes sense...

Nope...I have tested and works as usual...multiple templates to choose from on load...I don't have to first save, etc...Maybe an issue with your environment? PHP version, etc?

WillyC is right...that selector will not work. Architects (see architects pages, e.g.Albert Khan) are not parent pages; they have no children...so, your selector will not return anything...

OK, so Joss was faster...but yes, that's it.The first will find, for instance, all Skyscrapers that were built by "Joss"...the second will find all Skyscrapers in a particular City, e.g. Chicago...

Peter, just had some more thought about this...are you saying you want the value of toerist to be the selectable entity within the PageField with the custom PHP? i.e., you want to use toerist in the Admin and not the frontend...is that it? That wouldn't work as far as I can tell...this is a Page Field...I don't know of any method to display another pages field in any PW field...

Peter....what do you mean you want to return it as a PW Array? It is already a PW array! What you do with it is up to you. You can echo it or store it in a variable. Maybe if you explained your use case better....(or I am just thick and don't get..which is often the case )

@Bwakad, I agree with Soma here. The work of developing websites and installing modules is not for the client. It is the work of the developer. In that sense, It is assumed (nay, required even) that a developer working on PW (or any product for that matter) has some basic knowledge about how to develop in that system. In my opinion, before you install a module, you need to know what it is, what it does and what you need to get it up and running (how to install and uninstall it, what it requires - including PHP and PW versions). You also need to know and understand the notices and description text in the PW Admin and the modules you install. Logically, it follows then that when you see something labelled as "required", it means you have to check and confirm whether you have it or not..." I don't mean to be rude (or presumptuous) but the indication (as you state in another thread) that you by going through a certain tutorial in the Wiki you understood the difference between $pages and $pages tells me you probably haven't read the PW docs, especially the must-read PW API about $page and $pages. Or maybe I am wrong and that's where your PW journey started. Further, going by the conversation above, I can only assume that you haven't read about Modules either (http://processwire.com/api/modules/) in the docs. If you did, you would have noticed that the issue of "require" is addressed... I normally don't wade in like this, especially when it comes to new forum members. I am not attempting to put you off but gently suggesting that it is in your best interest to read the necessary docs. Then, we can sort of be on the same page (no pun intended) when discussing the ins and outs of ProcessWire... Cheers/k

That's what a Page Field is for. It returns pages Visually, you see the list of pages, but it actually returns the page objects. With those, in the front end, you have access to all fields and everything else about those pages. I don't get what you mean by "isn't doing it for me" - don't you get the list of pages in your MultiPage field? If not, are you using a compatible Page List? But, it also sounds to me as if you want to display a page field (toerist) within this other page field where you have your custom PHP. Is that the case? That is not possible according to what I know ....but, assuming I am not getting you...and all you want is access to the page field (toerist) that you then want to display in the front end..., that is easy... Let's call this PageField with your custom PHP "klassfield".....In it, you select the pages returned by your custom PHP...then, in your template file it is just a matter of looping through first, the $page->klassfield since it is an array. But, within the pages in that array (the ones that have the field toerist), the field toerist is also an array (assuming it is a MultiplePageField too)...so you will want to loop through those too. Does this make sense? If not, we could provide some example code

Peter, Why do you need to implode anything? $pages->find already returns a PW PageArray. That's what that field requires. I am assuming you are talking about the Input tab in your MultiplePage Field....You also need to use return and not echo...There's an example right there below that field return $pages->find("template=klassement, jaar=2013"); Refresher: http://processwire.com/api/arrays/

Certainly Apeisa, Wanze and Ryan come to mind as people you may want to talk to...perhaps...

well this is interesting...most of us tell newbies to forget about the skyscrapers profile (because it is advanced; not for newbies!) for a while until they get a grip of the default profile;

@celfred.. I'm not sure I follow. As far as I can see, Fredi does not reveal the link to Admin...I'm probably misunderstanding... Another possibility is to present the user with a form with fields that match their page's fields. On submit, their changes would be captured (AND SANITIZED!) in the POST variable using $input->post and $sanitizer. This will probably be easier than using Fredi...but, this depends on the fields. I don't think all PW fields can and/or a suitable to be used/mirrored in the frontend. You'll get better answers by Googling