owzim

Just wanted to say Thank You for this great module. I am working on a quite large project at the moment for which this module already has helped a lot.

first() or eq(0) for an array of (multiple) images, and leave it off if it's a single image. Single image: echo $page->main_image->getThumb('thumbnail'); Edit: adrian beat me to it =)

This is because it's set to be a single image field, so just don't use first() or eq(0). Or to make it a multi images field go to the the field settings / Details and set Maximum files allowed to 0 (infinite) or any number greater that 0.

thumbnail in this case is the name you reference in the template. The first() method selects the first image in the list of images attached to the page. $page->main_image->first()->getThumb('thumbnail'); if it is "portait-small,300,500" it woud be $page->main_image->first()->getThumb('portrait-small');

Good jog. Nice clean and elegant design. our-work might be presented in a more appealing and more legible way. Maybe a simple clean table, or a description list with indention? cheers

Looks great. What's the status?

Well, there is the obvious way: if($page->title == "some unwanted title") { echo $page->headline; } else { echo $page->title; } What I'd prefer is: echo $page->get('title!="some unwanted title"|headline'); but that does not work, is there something wrong with it or is it just not supported?

No, just as a value to be incremented.

Alrite, selectors ftw, thanks Soma.

Is there a neat an straightforward PW way of incrementing a value of a field other than getting all pages with that template an figuring out the highest value through a loop or something? In this case it should not be a regular auto increment but a number one higher than the highest of the already inserted pages.

I should appreciate your subtle rhetoric more =) Checking for the template might be the most convenient, because then I do not have to check for each field separately. That the fields have to be checked before I can access their children lies of course in the nature of PHP or most other languages as well. What I thought was that there might be a PW way around this problem. But there isn't, and that's OK =) teppo: still ... =) horst: ... uhm ;D

So the last line is not a question? =) Again: Is there a way to use the short and sexy api syntax $page->some_radio_button_group->value; without having to check if the field actually exists on the template?

The title might sound weird, but here's what I am talking about: Let's say I have a field of the Page FieldType to be used as a checkbox selector with the name of "categories". In the template file I want to do something depending on the categories the page is assigned to: if($page->categories->has('name=catname1, name!=catname2')) { // do something } I actually want to check for that in the header, so this code is executed on templates that might not have the filed "categories", so in that case it would result in (obviously): Fatal error: Call to a member function has() on a non-object Of course, I can check that before, like that: if($page->categories && $page->categories->has('name=catname1, name!=catname2')) { // do something } But then there might be something I would like to just echo out, for example: echo $page->some_radio_button_group->value; I would then have to cumbersomely turn the likeylikey one liner into this: if($page->some_radio_button_group) { echo $page->some_radio_button_group->value; } or, one line but still non-fancy echo $page->some_radio_button_group ? $page->some_radio_button_group->value : ''; Perhaps there is a more convenient way of getting the values without checking beforehand?

Since I pretty much got the hang of PW: Christian Raunitschka, Berlin http://ch.rauni.me Though, you might want to use this photo instead of my wierdo blueish one =) http://photos3.meetupstatic.com/photos/member/d/b/b/c/highres_80216252.jpeg

It's an outdated version of processwire.com, what's up with that?

Weird, I don't see unpublished pages, although I am logged in.

Great work Soma, thanks for the effort. Wouldn't it be more consistent to use the widely known Wordpress short code syntax (http://codex.wordpress.org/Shortcode_API)? [image='/path/imagename/' width='100' class='align_left'] And since there's also already a short code module for PW ... or is there a reason why choosing your syntax over the other? Keep it up!

Ryan, yes, I kind of missed the point. Since with TemplateFile class the actual template files is not automatically connected to the template itself which makes it necessary to pass certain variables if you want to use it like in this $page->render() context. So now I got how powerful it actually is to use context sensitive templates, and you can totally automate this too. Prefix your template files with contexts like: team-member.php home-team-member.php sidebar-team-member.php and use it like: $child->render($page->template . '-team-member.php'); If the template is called when being the actual page, render() is called automatically, so it's loaded the unprefixed team-member.php then. Awesome stuff.

Ah sorry, template tags, yeah. Get it now. Great stuff!

I don't understand this =) Can you present a use case more specifically? When talking about "template tags" do you mean regular html tags?

Is anyone using this in production? What about PW caching? Is it untouched by this?

This is obsolete, we figured it out =)

Finally grunt-contrib-watch implemented livereload natively so that it can be used without any hassle. Tried previous solutions with the grunt-contrib-livereload in conjunction with regard and connect but could not make it work. Now it works like a charm. http://stackoverflow.com/questions/16371022/how-to-use-grunt-contrib-livereload So yet again, workflow replaced, Guard is yesterday =D

Why is the variable handling not the same as with the TemplateFile class? $tplf->setArray(array('foo' => 'bar')); and in the template I am able to access foo with: echo $foo;

I actually do that all the time, modifying jQuery plugins. But it always feels awkward and wrong to hack plugins/modules or even the core. But yeah, in this your this is a one time thing, since you would not modify the module for the actual live site but for the import process. But in your case you might even be better off using the api or the csv import module, no?