Soma

I'm just trying to do something in my bootstraped php file and it doesn't work anymore in latest dev. When I switch to an older version it works. Anyone got experience the same?

Then why have a trash at all? You might swell just delete pages and not trash them in the first place. I'd vote for no because I want to get the page when using get(id). It's not searching.

Thanks for mention, but this is not in latest stable (2.3).

When I use a showIf on with counter>0, counter<10 it doesn't work, it shows the field when the integer field is 1 and hides it again with a value of 2. I also tested my dimension fieldtype and it got the same behaviour when I only write "dimension_width>0" it gets hidden when the value is 2.

I was about to ask if its possible to add more info to the fields. Great addition thx !

THen there's this $a->setTotal() $a->setLimit() $a->setStart() on page arrays we can use to configure built in MarkupPagerNav to work with merged page array in memory. Kind same as my above example but much simpler. /** * here is a example with using the built in pager * we can use $a->setTotal($n) to configure page array to work with pager */ // create new page array for storing pages $pa = new PageArray(); $res1 = $pages->find("template=mytemplate"); $res2 = $pages->find("template=house"); // import the found pages $pa->import($res1); $pa->import($res2); // configuration for pagination needed $limit = 10; $total = $pa->count(); $start = ($input->pageNum-1)*$limit; // example output with limited list we filter from the complete page array foreach($pa->filter("sort=-created, limit=$limit, start=$start") as $p){ echo "<p>$p->title</p>"; } // page array let's you set the parameters for pagination manually $pa->setLimit($limit); $pa->setTotal($total); $pa->setStart($start); // now the renderPager() on the page array works as usual echo $pa->renderPager(); Added this to the previous gist snippet here https://gist.github.com/somatonic/5420536#file-paginator_manual-php

There's maybe. Because I'm lazy and do number_format($page->dimension->width/100, 2). I'm not really sure, but I never want(ed) to support a setting for float, as my experience with it is mixed and it would mean to make it a lot more complex than I really wanted for a first basic first version. Make it configurable may be possible but I currently have no plans. Also there's endless possibilities and I could also ask why not also support only w&h and volume and area etc Keeping it integer makes it more straight forward. I could also imagine instead consider making a module that does formatting for the field for you, I think it would be more ideal to do the calculation 130/100 on runtime, instead of making a modified version of the field.

Too kind of you diogo!

Yeah it is, and it's with what I feed my family ( I actually don't get the involved part, as I find ST to be the opposite of most other tools and IDE where I constantly failed to get involved)

SFTP for Sublime is just awesome! There's nothing missing (touches wood) and you can even monitor local files like less or scss that gets preprocessed when saving and let sftp watch the css if they have changed through other tools and upload it (apart from the upload on save option this is really handy). super+ctrl+u+m to monitor and done.

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 !