teppo

@dragan: any chance you could post a link to one or more of these (original) images, if they're already online? That could make finding the problem a bit easier.

@roelof: you might also want to check out this thread: http://processwire.com/talk/topic/3714-how-to-do-this/. Unless I'm misinterpreting something here it's essentially the same question. By the way: when starting new discussions, you really should try to include something about your question in the thread name itself. It's difficult to find related discussions when they're named like "How to do this", "How can I do this" etc. Just another friendly forum tip..

@benbyf: regarding the nav issue @totoff mentioned you're giving "#topnav a" margin-right of 2% (0 2% 0 0.) This seems to screw with box model on at least Chrome. Could probably be fixed by giving it width of 100% (instead of "auto") -- though I'm not sure how that would affect all the other views.. Also: some things could use a bit of tuning on smaller screens (.latest-box elements could be full width, social media icons overlap top nav at one point etc.) Nothing dramatic though. The site itself looks great -- I'm really digging it's design!

Try $page->boardbasis->name or $page->boardbasis->title if only one selection can be made at time. If multiple pages can be selected, you'll have to foreach through $page->boardbasis (which'll be PageArray in that case) or do something like $page->boardbasis->eq(0)->title. When echoing out $page->boardbasis, selected page is returned and rendered as numeric ID.

@apeisa: I'm trying to use this on a PW 2.3 site and everything seems to work from administration point of view, but so far all I'm getting is this error message when I try to echo $page->my_poll (my_poll being the name of the field) on frontend: Any idea what could be causing this? I'll probably try to debug it properly later, but not being exactly familiar with fieldtypes / inputfields doesn't really help here.. Edit: reinstalling FieldtypePoll and InputfieldPoll fixed the problem. There was something strange with the install process originally (autoinstall didn't work for InputfieldPoll, installing FieldtypePoll before AngularJS caused errors etc.) so this should've been pretty obvious solution. Anyway, problem solved and everything seems to work now, sorry for the confusion PS. Have you considered adding this to the modules directory? Seems like a nice addition there.

There are valid use cases for template engines, but generally speaking templating with PHP is at least as simple and fast and at the same time imposes absolutely no limits on your creativity (especially with PW's fantastic API in your toolbox.) You'll love it once you get used to it That said, we also have modules for both Twig and Smarty template engines available, if you really want to use one of those: http://modules.processwire.com/modules/template-twig/ http://modules.processwire.com/modules/smarty-templating/ I haven't personally tried these (and most likely won't, if not purely out of curiosity) so I can't really vouch for either one, but as far as I can tell they both seem to be relatively stable.

Status flag 1024 means that a page is hidden. That (<1024) asks for pages not hidden (ie. status smaller than 1024.) See https://github.com/ryancramerdesign/ProcessWire/blob/master/wire/core/Page.php#L58 for details.

Another file could be a resized version, possibly for admin use (if you've turned on thumbnails in admin for that field.) Naming is a bit off, though -- that "-1" shouldn't imho be there. Someone correct me if I'm wrong, please. Anyway, you're not using IE10, are you? If you are, this could be somehow related to issue #195.

Sounds like your site_header_banner field allows more than one image. That's probably why it's returning directory path instead of image URL -- it doesn't know which image you want to output. Try altering that field to only allow one image (via field settings) or try doing this instead to get URL for first image in that field: <img src="<?php echo $pages->get("/site-settings/")->site_header_banner->eq(0)->url ?>">

Another minor addition to happy family of ProcessWire modules: Markup Load Atom. Markup Load Atom was forked from Ryan's Markup Load RSS to provide similar functionality for Atom feeds: given Atom feed URL it loads it and allows you to foreach through it and/or render it with built-in render() method. Get it from GitHub: https://github.com/teppokoivula/MarkupLoadAtom Note: I've been using this on a production site for a while now, but haven't really worked much with Atom feeds specifically. If you're a guru in that matter and feel that something is odd or plain wrong here, please let me know and I'll see what I can do. How to use With your own markup: $atom = $modules->get("MarkupLoadAtom"); $atom->load("https://github.com/ryancramerdesign/ProcessWire/commits/master.atom"); foreach($atom as $item) { echo "<p>"; echo "<a href='{$item->url}'>{$item->title}</a> "; echo $item->date . "<br /> "; echo $item->body; echo "</p>"; } Or with built-in rendering: $atom = $modules->get("MarkupLoadAtom"); echo $atom->render("https://github.com/ryancramerdesign/ProcessWire/commits/master.atom"); Installation Installing is identical to most other modules; just copy MarkupLoadAtom.module or whole MarkupLoadAtom directory to your /site/modules/, hit "Check for new modules" at Admin modules area and install "Markup Load Atom". More examples, detailed instructions etc. can be found from README.

Minor glitch (if you can even call it that): your 404 page is a bit unhelpful. Had an old link to /de/, which ended up serving a blank page and confusing the heck out of poor little me. Site itself is just fabulous

@Wanze: are you sure about that? Taking a look at get method in Page.php (which, in turn, is called by magic method __get): public function get($key) { $value = null; switch($key) { ... case 'next': ... $value = $this->{$key}(); break; ... Sorry for all the dots there, but anyway: as far as I can see, actually next equals next() unless PW has already "cached" it's return value as a property, which shouldn't be the case here. And I don't see why above warnings wouldn't apply here either

There is a warning about next() and prev() in Page.php regarding larger amount of siblings: How big a problem this will cause depends on how many sibling pages you've going to have in each branch there (and the number of branches, of course, if there'll be a lot of those.) I tried to implement next and prev on a site that, at that time, had around 1500 siblings in each branch and was growing fast. That resulted in significant speed problems for each page load. I didn't have caching on at the time, though -- that definitely helps a lot. With caching enabled PW only has to build each page as a static HTML file once. Even if it's a bit slow, it should only affect first page view of each page in that branch. On the other hand, if content is updated very regularly (which I kind of doubt would be a problem here) this would of course diminish the benefit of caching a bit. All in all, I'd suggest that you implement this, do some tests regarding speed and see for yourself if it's going to be a problem. If possible, add some extra dummy pages to see how things will change once your site grows.

Minor addition to above: $page->parent->first()->url should be $page->parents->first()->url.. or just $page->parent->url, which already returns first parent. Also: you could use $page->child instead of $page->children->first() to get first child Other than that, this seems to work properly. Now, I'm sorry for taking this thread a bit off track, but there's something strange going on here I'd like to point out: I was actually going to suggest a very similar approach, but after testing it ran into a problem that kept crashing whole Apache. Seems to be somehow tied to recursive function in sitemap template of default site profile and also happens with solution provided above. Once I comment out sitemapListPage() call in template file everything works properly, with it in place Apache keeps dying on me. Just for reference, code I was going with for the original problem was this: $next = ($page->numChildren) ? $page->child : $page->next; if ($next instanceof NullPage) $next = $page->parent->next; echo ($next instanceof NullPage) ? "This is the end" : "<a href='{$next->url}'>{$next->url}</a>"; After using either my approach or the one @horst suggested above, this seems to cause massive headache to Apache: function sitemapListPage($page) { echo "<li><a href='{$page->url}'>{$page->title}</a> "; if($page->numChildren) { echo "<ul>"; foreach($page->children as $child) sitemapListPage($child); echo "</ul>"; } echo "</li>"; } sitemapListPage($pages->get("/")); What am I missing here?

Edit: oh, wait, sorry -- completely misread your question

Microdata is always good to have, thanks for sharing this! Personally I wouldn't depend too much on data-vocabulary.org though. Their home page makes it pretty obvious that schema.org is the new toast of the town. With schema.org vocabulary breadcrumbs could be implemented like this: <body itemscope itemtype="http://schema.org/WebPage"> ... <div itemprop="breadcrumb"> <?php foreach($page->parents as $parent) { $end = ($parent === $page->parent) ? "" : " > "; echo "<a href='{$parent->url}'>{$parent->title}</a>{$end}"; } ?> </div> <!-- this follows strictly schema.org example --> Or with markup matching above example: <body itemscope itemtype="http://schema.org/WebPage"> ... <div class='breadcrumb' itemprop='breadcrumb'> <?php foreach($page->parents as $parent): ?> <li> <a href='<?php echo $parent->url; ?>'> <span><?php echo $parent->title; ?></span> </a> <span class='divider'>›</span> </li> <?php endforeach ?> <li> <?php echo $page->title; ?> </li> </ul> <!-- this isn't exactly what schema.org describes but should still be valid.. --> There's quite a bit of discussion floating around whether schema.org version of breadcrumbs is actually useful, but it is what their example currently suggests. Note also that breadcrumb is a property of WebPage, ie. you'll have to be in that context in order to use this properly.

So when you submit your search form, you end up at domain.tld/search/ without q GET param? Are you absolutely certain that the form works properly? What about creating another, dummy form with only necessary attributes and fields -- ie. target "/search/", method "GET" and an input with name "q"? If you're a Chrome user, you could also check Network panel in developer tools to see what's happening with your request. Turn "Preserve Log upon Navigation" on with round button at the bottom of dev tools to see if any odd redirects are happening. (Firebug probably has something similar.)

.. and now it should definitely be password-protected, hidden or removed to avoid unnecessary confusion / people browsing that instead of real site. Good point, @owzim

Don't think there's a way around checking if field exists, not at the moment at least. In your echo case you could always do this: if($page->some_radio_button_group) echo $page->some_radio_button_group->value; This doesn't look "cumbersome" or inconvenient to me (none of your examples do, really), but hey -- what do I know..

It's starting to make sense now Only reason this could break (that I can think of right now) is that you've got multiple database connections open, so it might be necessary to define which connection is used here, like this: mysql_query($sql1, $connection); If that doesn't help, there's probably something else we're missing. You're getting "internal server error" by running this -- any chance you could take a look at Apache (web server) error log somehow? There should be a more detailed description of this error there. PW has it's own error log at /site/assets/logs/errors.txt, which you should also take a look at and another thing you could try (unless this is a live site already!) would be turning ProcessWire debug mode on from /site/config.php. This might give you a bit more information about the nature of this error (though in this case I don't think PW will have a chance to actually put anything there..)

Any chance you could specify exactly what (or how) you're trying to do? I don't see a relation between sending email and MySQL, so I'm a bit confused here If it's SQL you're talking about, that shouldn't be a problem at template level, but you should probably run it through PW's own $db object: $sql = "SELECT * FROM my_table WHERE my_field RLIKE 'my value'"; $result = $db->query($sql); while ($row = mysqli_fetch_assoc($result)) { echo "this is a row from database: {$row['my_column']}"; }