Soma

The "fieldset1_END" is there but the OPEN is gone! Ah it's there's but loosing the indent...

I just went ahead and tried to hide fieldset, and enter a checkboxfield=1 and after saving the fieldset_OPEN is invisible and the hirarchy is messed up.

Not sure but try updating PW. Also you possibly use repeaters?

Sorry had to finish my post first... so that's why I'm posting this so you see it.

Maybe you want to inform the user that the page actually has been deleted and you would anyway use: $p = $pages->get(1001); if($p->isTrash()) { $wire->error("This page has been deleted by " . $users->get($p->modified_users_id)); } else { ... } YOu don't have to check the if the user is in the trash because users can't be trashed, but maybe he also got deleted... Building a webapp as it sounds you're doing there's actually quite a lot of scenarios you got to cover. THe issue is kinda made by you but I get what you're saying and it's a valid consideration. WIth the possibility that Ryan says different and think it's a good idea... I think I'm not sure if changing it will break backward compatibility, even maybe rare. But I think it really doesn't matter that much and don't see how it would change much. I think you're the first even questioning this (not that it says something bad about it) edit: damn wrong button, had to finish the post first sorry Another example maybe more real world $p = $pages->get(1001); if(!$p->id) { $wire->error("Sorry, this page has been deleted already!"); return false; } else if($p->isTrash()) { $wire->error("This page has been trashed by " . $users->get($p->modified_users_id)); return false; } else { ... }

oooooh weekend just started! I'm in!!!

You make it complicated where it isn't. I agree it can be confusing if you're not experienced working with PW, but it's as Ryan said we hardly ever need to think about it. But I have to agree with Peter that Ryan mentioned something above which add to the confusion of the confusion even more in that it isn't exactly true or not including all infos (which seems natural to him or us) This is not really the case: echo $pages->get(1733) . "<br>"; echo $pages->find("id=1733")->first(). "<br>"; Will both return pages from the trash! Event the find. No include=all needed. BUT, what what Ryan maybe wanted to say there is that when using get or find with a selector like a usual: $page->get("template=basic-page, isactive=1"); or a $pages->find("template=basic-page, selected_page=1002") ... will never return a page from the trash, unless you add a "include=all"! A $pages->get(1733) is much like saying "SELECT * from pages where pages_id = 1733", will return the page no matter what. So is a find("id=1733")->first(); It feels kinda natural and after using PW API for some time you'll never ask again. But have to agree it can be confusing for people... wait till you start coding modules where there's also no outputformatting and not access aware! If you have some case where you really want to make sure you don't want a page from the trash, just add a check like ryan showed above, or add a status selector.

In case you want it a little more simpler $pages->setOutputFormatting(false); $pag = $pages->find("template=basic-page"); foreach($pag as $p) { foreach($languages as $lang) { if($lang->isDefault()) continue; $p->set("status$lang", 1); $p->save(); } }

Without knowing or testing it must be status1015=1 (where id is the language)

Just wanted to mention some updates I was recently working on. 1. The Cheatsheet is now a ProcessWire Site (since couple months already). This allows for easy updating by team members. Also it allows for implementing stuff that wouldn't be easy with a static html. So all entries are now pages. This was very easy to setup and import the html data via a simple script. 2. Since we now got all the power of PW there, my idea was to create a API doc Site that would serve as a alternative extended sort of cheatsheet. Similar to php.net where you can see more details along with simple code examples and further information like what version introduced or if it's depreciated, related links to other API's. Also there's possibility to add comments. This opens great possibilities to give more information to you, add a "social" aspect, and at the same time also open it for indexing by search engines . You can see the current (not finished) version of the extended API doc here: http://cheatsheet.processwire.com/pages/built-in-methods-reference/pages-find-selector/ We are currently adding content and examples to the API's so this will take some time. Also there will be added some cross linking from the Cheatsheet to the extended docs when ready. Hope you like it. (edit: just realized that this was the 100th response in this thread! great coincidence)

I cannot access anything from that domain not matter what and where and with what. Looks like not a problem of PW. I would check the logs.

I have had changed my example to "selector" => "hide_fr=''", Works fine.

I'm not sure I understand fully what you saying. No you can not nest selectors, what ever that would mean exactly. To hide pages with "hide_fr" checked you would simply use "selector" => "hide_fr=''", Also I'm not sure why you can't simply use "active" option, If the default language should not be shown you would simply hide the page or unpublish it.

Template Cache and $page->render($options) If you ever use the $page->render() to render out partials (of another page using its template file) and use template cache for the pages you're going to render and the page where you render it, it will create a cachefile. So if you go to that previously rendered and cached page, it will render that partial. If the page is accessed before a cache is created, it will cache this one and render that in as the partial, so kinda turned around. Funny effect. And many mmms and oaaahhhs To get a better understanding what's happening read on. Simple example code from a list page to render partials of articles (likely) // from the list pages template $markup = ''; foreach($products as $key => $child) { $markup .= "<dl>"; $markup .= $child->render(array('isOverview' => true, 'class' => $class)); $markup .= "</dl>"; } echo $markup; And in the template of the article // in article template file if(isset($options['isOverview']) && $options['isOverview'] == true) { // render small partial $class = $options['class']; $markup = "<dd class='$class'> <h4>$page->title</h4> <p>$page->summary</p> <a href='$page->url'>details</a> </dd>"; } else { // render complete article $markup = "<div class='product-details'> <h1>$page->title</h1> $page->body </div>"; } // output echo $markup; So now the render call $markup .= $child->render( array('isOverview' => true, 'class' => $class) ); in the list template will cache the page it renders (the small view of it). Thus if you access the page directly it will serve the cached small view of it. Ups. Solutions This is without specifying a different template file in the first argument in the render(). The effect doesn't happen when you, let's say create a new template file (ie article-small.php) and use that to render the page. Since this new template file is not connected to the template in PW it also has no cache for that render. To show what I mean is the following with the first argument the file you want the view to render. $markup .= $child->render("product-small.php", array("isOverview" => true, "class" => $class)); Still following me? Ok there's also another method to not allow a cache file to be created. There's a default options set in the render() in PW. Bingo! allowCache is what we can also use. $markup .= $child->render("product-small.php", array( "allowCache" => false, "isOverview" => true, "class" => $class )); And everything's back to normal. Just wanted to write down a little thing, as I stumbled over this recently, to scatter some keywords about this here . I think this isn't really documented somewhere but I thought it was maybe mentioned by Ryan in a thread about when he added this feature: http://processwire.com/talk/topic/3145-multiple-views-for-templates/page-2?hl=%2Brender+%2Bcaller#entry32876. Edit: Zaaakkkk and it's in Google 9 minutes !

Your welcome, thanks for the quick fix it works now!

I understand and know this, but why do you need to get the translation when it is just already there. It will output in the language the user views the page ($user->language) This works just fine in the language the user view the page. echo $fields->get("body")->label; Edit: ah, hm it does not? Ok it doesn't get translated as with page fields. Since it's meant to be used for backend context there's no language value for fields settings. So you either use a $lang variable like this: $lang = $user->language->isDefault() ? "" : $user->language->id; // Default needs no id echo $fields->get("body")->get("label$lang"); Or a little hook to add method to the $fields template API var. // from template or a autoload module $fields->addHook("getLabel", null, "getLabelLang"); function getLabelLang($event){ $field = $event->arguments(0); $lang = wire("user")->language->isDefault() ? "" : wire("user")->language->id; $event->return = wire("fields")->get($field)->get("label$lang"); } // now we use it and it will recognize user lang echo $fields->getLabel("body");

I have a hard time to understand why one need the field labels (in different languages) in the front-end. After all if the it should render the language the user currently is viewing. We covered this already in another thread and there's the solution above and I don't think there's something like you mention on the plan but maybe I miss something. But it would be easy to build a function or module to help out but there's barely anything needed to get a translated label. $body = $fields->get("body"); $lang = $languages->get("de"); echo $body->get("label$lang"); // german label

If you turn off formatting a single image field is also an WireArray again. $page->of(false) $page->image->removeAll(); $page->save();

Since Pagefile is a single file field you would use delete(). You're not dealing with a WireArray then but with the page file itself. Or a $page->file = ""; $page->save(); would also do it maybe. Just wanted to add that if you (or need to) first $page->of(false) (setOutputFormatting), even a single file field will be an WireArray, so deleteAll() should then also work.

I found a nasty bug when moving pages in the page tree in the admin. I have a setup where I have created a new category page and moved all the product pages on the same level into the newly created category. But then the find() I used to get all products from a parent above the category page fails. The product pages have children, which seems to be the key to reproduce this. I also have multilanguage installed but I don't think that does anything. I tried and was abel to reproduce this in my local test install with complete unreleated templates or fields. This is the on second level ... /shop/ /category1/ /newparentpage/ /product1/ (product template) /product-var1/ /product2/ (product template) /product-var1/ When I move "product1" and "product2" inside the "newparentpage" /shop/ /category1/ /newparentpage/ /product1/ /product2/ I can't use following to get all products under "category1" $pages->find("has_parent=category1, template=product"); // returns nothing $pages->get("/shop/category1/")->find("template=product"); // returns nothing $pages->find("has_parent=category1_ID, template=product, include=all"); // returns nothing This got me, as I never experiences something like this. The page tree works and also finding the product with $pages->find("template=product"); // will find all still Also this doesn't happen if the moved product pages have no children. So there's something wrong with the page_parents table I guess, but haven't investigated futher as I'm in a hurry to finish the website. And always then such things happens.

$page->files->deleteAll(); $page->files->delete($pagefile); $page->images->removeAll(); // wirearray $page->save(); http://cheatsheet.processwire.com/?filter=filesdelete

Do you have secure page files enabled in config.php that would be the only thing I can imagine changing files when unpublished.

In a subfunction they aren't available? wire("languages") ? Is available everywhere. this should maybe work. $lang = $languages->get("dutch"); $dutch_field = $page->get("fieldname$lang"); or $lang = $user->language; $user->language = $languages->get("dutch"); if($page->fieldname) { ... } $user->language = $lang;

pages->get(id) will return the page with id. Doesn't matter where it is and what user. It's explicit. As soon as you add another selector, it will behave like a find thus check for if pages can be viewed or accessed. Everything correct here.