Leaderboard

The PW image API allows you to create different sized, cached versions of images for use in different situations. For instance an original image might be 1000 x 700 px, but we can can crop and resize using: $newsize = $page->myimage->size(300,300); And produce a square, cropped and resized image 300 x 300 px. But how can we make this work in a responsive environment so that we choose an image varient created using the API based on viewport size? There are several ways to do this, but in this case, a bit of script called Response.js can be rather useful. Reponse.js allows you to set up a set of parameters for exchanging data on the fly. (Please note that this is NOT an ajax based system, for that, please look up enquire.js) So, you can tell it to look for a certain sized view port by setting breakpoints and then use that to choose what data you want to call in. So, for instance, on their website they give this example: <img src="lo-fi.png" data-src481="medium.png" data-src1025="hi-fi.png" alt="example" /> The default image is the smallest (thinking mobile first) and then there are two further images called depending on the viewport size. The "data-src481" bit relates to the set up code made for this page or site. You can see that it would be fairly easy to add the PW image api to that bit of html. So, onto a real world example I am using in a client's blog. I had two imediate problems - firstly the site uses EMs and by default, response.js uses px. Secondly, I wanted nice memorable names for my various breakpoints. The developer of response.js is a helpful fellow and he wrote me a nice bit of script to do exactly what I want: !function(Response) { var names = ['basic', 'phoneportrait', 'phonelandscape','smalltablet','largetablet','laptop','desktop']; var values = { phoneportrait: '(min-width:20em)', phonelandscape: '(min-width:30.063em)', smalltablet: '(min-width:33.125em)', largetablet: '(min-width:48.000em)', laptop: '(min-width:64.063em)', desktop: '(min-width:80.063em)' }; Response.addTest('view', function(breakpoint) { var query = values.hasOwnProperty(breakpoint) && values[breakpoint]; return !query || Response.media(values[breakpoint]).matches; }).create({prefix: 'view-', prop: 'view', breakpoints: names, dynamic: true}); }(Response); This script is in my sitewide javascript file so that it is available for anything I am doing. All this script is doing is setting my em min-width values against names and then using those to create the calls. So, I would call a breakpoint with: data-view-phoneportrait Just for interest, this reproduces a set of breakpoints I have using sass-mq for my sass development set up. Now all I have to do is mix that up with my images, In the example below, which is for a list of articles in responsive blocks (using the easy to use pocketgrid system) I just swap the image depending on the view port: $smallimage = $article->image_single->size(256,256); $mediumimage = $article->image_single->size(300,300); $largeimage = $article->image_single->size(371,371); echo "<a href='{$article->url}'><img src='{$smallimage->url}' data-view-smalltablet='{$largeimage->url}' data-view-largetablet='{$mediumimage->url}' data-view-laptop='{$mediumimage->url}' data-view-desktop='{$largeimage->url}'></a>"; Response JS can also swap data within a div, though as I said earlier, this does not use ajax, so is best for small bits and pieces. I am finding that with the huge versatility of Processwire, this plays very nicely not just with more complete systems like Foundation, but perfectly with far more versatile system made up of small utilities rather than one big do-everything solution. My tool box now consists of responsejs, enquire, boubon mixins (but I don't use NEAT), various cross browser helpers like respond.js and html5shiv, a very good media query mixin call sass-mq and then my own bits and pieces. So, the lesson here is that the PW api does not just output data, but is part of your toolset for creating powerful and capable dynamic, responsive, mobile first websites.

Some sites need widgets, as they have been called in some systems; a widget can be almost anything, like: tag cloud mini calendar menu quote rotator free text social sharing search contact info map This is a simple way to create widgets that can be shown in multiple "areas" of a page, as well as on specific pages. In this particular method you would need to setup each widget type you want and then determine how best to accept any necessary user input like content, pages select (like for a menu) or settings. This example uses include files for each widget type, and the name of the include file would match the name of the widget type, which is also a page field. In this example, I'm also using ListerPro to provide a widget management page. Fields The main fields used on this widget example are : title widget_location (page select - options in this case are footer and sidebar) widget_type (page select, you would configure your widget types as selectable options) pages_select (would be used for multiple pages and might apply to a menu widget) body - used for plain widgets selector (selector inputfield, used for telling the system where to show the widget) text_structured - for this i'm using a YAML field, but it could just as easily be a table; would depend on what you want to store; YAML would allow this single field to be used for varying requirements based on the widget type, but would be harder to validate and prone to user error; icon - a page select for an optional icon which is being used in the template, and would be shown as part of the widget. Files for each widget type you want to allow users to select from, you would need to create an include file with the markup for that widget, and then add that widget to the list of available widgets. here is an example for a site with several widget types: Selector & Output wherever you want to include the widgets (footer, sidebar etc.) you would run a $pages->find and then foreach through the widgets (in this case finding all footer widgets). In this case the (incredibly amazing new) selector field would be specifying what pages to show the widget on. We assume that most widgets won't have a selector specified, and will default to show the widget. if a selector is specified, we can check to see if this page fits the selector by using the $page->is($selector) syntax. <?php $widgets = $pages->find("template=widget, widget_location=footer, sort=sort"); foreach($widgets as $widget) { // check if the selector field is in use and if so, see if this page is supposed to display it: if( $widget->selector) { if( !$page->is("$widget->selector") ) continue; } $widgetType = $widget->widget_type->name; $include = file_exists("./inc/widget-{$widgetType}-foot.inc") ? "./inc/widget-{$widgetType}-foot.inc" : './inc/widget-footer.inc'; include($include); } ?> this example also has a fallback file in case the widget type is not specified, sort of a default. the widget's .inc file will be unique to your design and how you have it setup.

@kathep. Welcome to the forums. As Nico pointed out in his post, he didn't know whether you are using a Single page field or a Multiple pages field, hence the use of 'instanceof Page/PageArray. That is not code you would normally use in a template file. Nico also pointed out how you would handle either page field type which I want to further clarify by asking, is your 'course_name_from_list' a Multiple or a Single page field? The fact that: does not answer my question either . This is because, your 'course_name_from_list' could be a Multiple page field but you are using it to select only one course. In that case, because it would be a Multiple page field, whether you select one or 10 courses from it, it would return an array that you would have to loop through. On the other hand, if it is a Single page field, you would only ever be able to select one page in the field; PW will not let you choose more. You would not have to loop through it if it was a Single page field. Which of this is your case? If not the latter, I would suggest you change it to be the latter since you will only ever want to force the selection of a maximum of 1 page. Then you would be able to do as Nico suggested in his second example...(and it would work if your 'course_name_from_list' was a Single page field type), e.g. if($page->course_name_from_list) echo $page->course_name_from_list->title; Sorry for long-windedness! Btw: If on development/local server, you want to turn debug on....

Hi BernhardB - awesome and thanks so much for joining in on this.. i really like your approach to the widgets also; the InputfieldSelector field isn't that new, i can't remember when it was announced - i think this past summer; but in terms of the CMS, it is pretty new and it was conceived by Antti Peisa, coded by Ryan Cramer and sponsored by Avoine; it is in the core, so you just need to install it. The field is used in the listers; as a standalone field i haven't seen many posts about day-to-day use of it and i kept thinking of when and where it might come in handy.. then while i was setting up this one site I came across this situation where i wanted a certain widget only to show up on the child pages of another page; so first i did a plain field and typed in the selector and sort of moved on... but something kept nagging at me and then it suddenly dawned on me that there is already this field that could make setting up the selector more user friendly and reliable, and it works great; It provides feedback to tell you how many pages match your selector; for some clients who have a little technical knowledge and skill, this is a really simple and easy way to specify a selector for pages, and then be able to test against that selector in conditionals.. i think in some instances it is probably too technical to be of use; i wonder if you could use the new selector field in your setup, as you can add additional lines to the selector, which would be like your repeaters... i haven't done extensive testing or experimenting yet with this, but i have 3 more sites to launch and i'm sure this selector field will get more use in situations like this..

As posted at https://processwire.com/talk/topic/8501-problem-with-ajax-jeditable-process-module/ I'm playing around with frontend edit plugins... While FCM (FrontendContentManager) was a simple frontend form based on PW form api and inputfields now I'm play with inline edit plugins / modules. Instead of jEditable my last test was based on jQuery inplace edit plugin ("Jinplace"). Jinplace makes a element editable on click and sends object (pageID), attribute (fieldname) and value (the new value) via ajax to a process module. Features editable textfield and textarea page reference field as select (drop down) checkbox and labeled checkbox (Yes / No, translateable) a (buggy / testing) jquery tokeninput tagging widget with autocomplete as jinplace plugin/ extension: add, remove and create new tags (buggy click to close event, but jinplace plugin is just a first self written testing version) The process module also take care about missing required values (page id, field name) to identify the field to work with unchanged values (at the moment returns a json error message inside the editable field) not save empty values to required fields input sanitizing save/ create new tags (pages) via tokeninput fields ToDo bug fixes (dirty javascript code) tokeninput themes (mac, facebook, default) via parameter and also useable as not editable style in the frontend error handling (show a message, ignore and reset, ...?) sync initial value with "default" return value (initial could be "Like" / "Don't linke" but process module returns true / false or "Yes" / "No"...) file / image fields (maybe should be done with another module and PW inputfields - form with inline ckeditor and hidden image / file upload field) Bitbucket Repo: https://bitbucket.org/pwFoo/frontendjinplaceedit Really basic demo! Login: http://samarium-pit.lightningpw.com/processwire/ as demo / demo123 Testing page: http://samarium-pit.lightningpw.com/frontendjinplaceedit/ Don't know if I'll do some more work to create a full usable module. But let me know what you think about it

I think you'll never get a negative amount of visitors (so you don't need "-50") How to solve: Change line 42 in the js file (0 instead of null): yaxis:{min:0, ---------- And another little thing:

A proof-of-concept session handler module for PW that uses Redis as the session database. You'll need access to a Redis server (IP address and Port) and you can configure the session prefix, the Redis DB that the sessions will be stored in and a time-to-live for the sessions. Please let me know if you run into any issues with this module. Here it is on Github. Here it is in the modules repository.

Ah cool. Thank you for suggesting a more correct alternative. I am still learning about echo. I also like the 'else' option - this is a very front end user friendly option! I will make use of it. In case you are interested, I am using these things here.

Thanks for the writeup....Here's another way of doing it (no need to use instance of Page ). Also, only output stuff you have confirmed exist.. //prepare a variable to use later on. Setting one like this ensures we don't get 'unknown $sidebar' errors in case things go wrong $sidebar = ''; //if we found a course selected in the page field if($page->course_name_from_list) { $course = $page->course_name_from_list; $sidebar = "<h4>Course: " . $course->course_number . "<br>" . $course->title . "</h4>"; } else { //Oops, course not selected! Quick, hide everything! $sidebar = '<h4>Sorry, we do not have yet have the details for this course. Please check back soon, thanks. Alternatively, if your case is urgent, you can contact us on 12345-4567-0000.</h4>'; } echo $sidebar; Btw, If I understood you correctly, the page selected in the Page field 'course_name_from_list' has a field called 'course_number' and of course a title. In that case, you don't need to first save those fields in an array as you implied above: The fields will be available to you automatically in the 'page/object' 'course' . You will be able to reference them as $course->name_of_field. If any of the fields is an array, you would have to loop through it, of course..

Glad you sorted it out... The error with first() is because, in a Single page field, there is no 'first' per se; there is only one value there. first() will only work with a Multiple page field (or similar fields that return multiple items). To be a bit verbose, it is like telling a student 'go get me the first Head Teacher' - it doesn't make sense since there is only one Head Teacher (only one possible - Single page field). But you could tell the student, 'go get me the first teacher you find in the staff room, or the next five teachers you meet in the corridors ' (multiple possible) OK, you get the point

Hi @kongondo, and thank you for your long-windedness. It really helps me to learn. The field course_name_from_list is currently a Multiple page field. I would prefer it to be a single page field, but when I choose either option 'Single page (Page) or boolean false when none selected' or 'Single page (Page) or empty page (NullPage) when none selected', my page returns a lot of errors, like this: I don't have enough knowledge to understand these errors, so I got scared and returned the field setting to Multiple page. UPDATE: Resolved I just started working through the errors to try to fix them myself. I removed a '->first()->title' from an instance of $page->course_name_from_list and that removed all errors. Now my page works, and the code provided by @nico works! It was a simple fix. I'll write up my steps for an absolute beginner and post them below. Thanks @kongondo! Thanks @nico!

Just for your own sanity break the code into functions where each one is responsible for opening and closing a tag it creates. Pass info to outermost one, it starts a DIV (whatever) and passes info to another function (drilling down in a nested way) then closes the DIV it started. All the opening/closing of the tags works out by itself as the functions return. It's easier to test. Each function handles one level of the nesting and has the tests (logic) and tags (markup) that happen at that level.

You can do a check to see if the product_type is the same as it was during the last loop. Something like this: $last_product_type = ''; $sid=$pages->find("template=product, sort=product_type"); foreach($sid as $product){ if($product->product_type != $last_product_type) echo $product->product_type ."<br>"; echo $product->product_name ."<br>"; echo $product->product_image->url ."<br>"; echo $product->desc ."<br>"; $last_product_type = $product->product_type; }

I have just committed another update that has a separate field for attachments that are not images. An email can now contain both and they will be treated separately with images being embedded in the body text when appropriate, but keeping other file types only a "attachments" and stored in the selected files field.

Oops - sorry about that - fixed that and added a couple of checks around the user detection. I am thinking the next important addition is treating attached images differently to attached files.

FYI, I had a problem with the body text not showing up. I looked at your code and ended up doing a diff to see what was going on. Somehow the following code was dropped from the update: $page->{$category->bodyField} = $body; I added this code to the recent update and then the body text showed up again.

That makes sense - thanks for clarifying the reason for the email address actually being populated. I have just pushed another update that now has three separate options: name, email, user The first two are obvious. The third one (user) needs to be pointed to a page field that has "user" as the template of selectable pages. Also, you might want to set Label Field to "name" rather than the default "title". When the page is created, this field will grab the user from the list of PW users based on the email address, which means you then have full access to all other fields in the user template. It also sets the created and modified users on the Settings tab to this user. This should make it pretty powerful for emailing in blog posts and the like. I probably need to add some checks to deal with the email address not matching a PW user, but I'll wait for the next update for that. Let me know how it works for you. This is what the result looks like on the new page:

these are the postings where i am happy using pocketgrid. the resulting code for your template is quite simple, even though you have to define some css rules first, but you don't have to take care of inserting </div><div class="row"> every 3rd item and doing modulo %3 == 0 and $i++ things and all that and keep your template really clear! <div class="block-group"> <?php foreach ($page->locations as $loc) { ?> <div class="col3 block"> <h3><?= $loc->title ?></h3> <p><?= nl2br($loc->adresse) ?></p> <p><small><a href="<?= $loc->website ?>" target="_blank"><?= $loc->website ?></a></small></p> </div> <?php } ?> </div> you can define custom breakpoints for your class "col3" (eg. 3 cols from 1000px+, 2 cols from 500px+ and 1 col below 500px screen resolution) and it already takes care of correct floating: http://arnaudleray.github.io/pocketgrid/docs/#automatic-rows-in-real-life it seems that your mentioned block grid approach is quite similar - so i'm kind of happy reading about that

great writeup macrura! what do you mean by the incredibly amazing new selector field? edit: oh - just saw what you meant on your screenshot and didn't see it before!!! i thought you were talking about the page select field... where can i find more info on this? -------------------------------------- here is my old posting - just for the record. it seems it is quite useless having the new selector field edit: polished version here: https://processwire.com/talk/topic/8635-simple-example-for-widget-management/?p=95532 i also have a widget setup on one of my sites with a little different approach of how to manage visibility of the widgets (3rd column: if this box is checked, the rule applies also to its sub-pages) for every widget you can setup "display rules" including #page #include/exclude and #include_children. it's kind of a bottom-up approach: the example above would show the widget on all subpages of /games AND on page /games (rule #3), but would NOT show an page /games (rule #2 removes access given from #3) and would not show an any other page (home + subpages, rule #1). a simpler example would be: rule | page | | sub-pages? ------------------------------------------ #1 | home | exclude | yes #2 | /section1 | include | yes so this widget would show on all pages in section1 (eg /section1, /section1/post-1, /section1/post-2 ...) you could easily exclude the widget on page /section1/post-2 by adding #3 | /section1/post-2 | exclude | no ...and it would still display an all other pages (posts) in section1, including newly added ones (post-3, post-4...). if anyone is interested in the code i can share it with you - altough it's quite messy because it's only a prototype for now. i also have to say that i don't like the repeaters because they are wasting lot of space for displaying only 3 small pieces of information. maybe a pagetable field would be better for the next version... i'm also managing this site on my own, so i have no experience with clients handling this display rules for now!

This will do what you are looking for. You need to get the page array for the page you are adding: $pageitem and also use "add" to add it to the array of pages held by the page field. $p = $pages->get(1234); $pageitem = $pages->get(4321); $p->of(false); $p->foo->add($pageitem); $p->save(); Hope that makes sense.

Hey, I will be at the 31c3 this week (starting at the 27th) in Hamburg. Is anybody else of you ProcessWire guys going to be there (and maybe would like to meet )? Let me know! Greets, Nico

Hope I understood it correctly. The code above will show all courses which are selected with course_name_from_list if included in the assignment.php. $course = $page->course_name_from_list; // the page inputfield returns a page object if max=1, or a PageArray, if max. is above $content = ''; // because I don't know your settings I do it as flexible as possible, but of course you could make it shorter // Case 1: You have not set a max or max is above 1 and you chosre more than one page if($course instanceof PageArray) { foreach($course as $course_item) { $content .= $course_item->course_number . " " . $course_item->title; } // Case 2: One page selected } elseif($course instanceof Page) { $content .= $course->course_number . " " . $course->title; } echo $content;

What about if you use this link: http://gdata.youtube.com/feeds/api/users/disney/uploads?orderby=updated&v=2&client=ytapi-youtube-rss-redirect&alt=rss That actually contains the thumbnail url. Note the "api", rather than "base"

The node that contains an image is not there. The images are in a blob of HTML so it's hard to get those out. If you really want to get those out you could build the url to the image your self. The easiest way I see now is: Filter the video id out of the: // 76UvX8EKNZ8 is the ID <guid ispermalink='false'> tag:youtube.com,2008:video:76UvX8EKNZ8 </guid> Then use that id to build the url with: // Default image (small) http://img.youtube.com/vi/<insert-youtube-video-id-here>/default.jpg // high quality http://img.youtube.com/vi/<insert-youtube-video-id-here>/hqdefault.jpg // medium quality http://img.youtube.com/vi/<insert-youtube-video-id-here>/mqdefault.jpg // standard definition http://img.youtube.com/vi/<insert-youtube-video-id-here>/sddefault.jpg // max resolution http://img.youtube.com/vi/<insert-youtube-video-id-here>/maxresdefault.jpg Keep in mind that not all images are available so propably you'll need a loop till you have an image and use a fallback if nothing is found. Second way: A second way I see is to search the <description> with PHP DOMDocument.

Hu guys I'm delighted to say that my new site is powered by Process Wire. Or rather, "Priceless Wine" and "Princess Wine" as my iPhone mistakenly predictive texts the name. There is also a page on ProcessWire in the CMS section which I'd love your feedback on. Currently I don't think it truly communicates PWs best features for Editors but it's a good start. Only almost finished? The site isn't 100% complete so consider this a "soft launch". Once complete, it'll replace my existing edenweb.ie site which wasn't being updated or developed as much as it should. - - - - - - - - - - - - - - - - - - - - - - - - - - - Background - Why ProcessWire pt 1. A few months back a key client who uses up approx 3 days of my week (for over 3 years) announced a pause on their web and marketing activities for various internal corporate reasons. This happened quite suddenly and obviously that left me with half my week "open" and needing to be filled. It also meant that I would be looking for new work and approaching prospects with a site which was approx 3 years out of date, under developed and didn't really communicate my latest skills or work. Not ideal! - I rapidly needed something live. But more importantly, I needed something better. I needed something built on a CMS which would allow me to rapidly publish content and accelerate future ideas and development. In short, my current CMS is/was great but I was tired of working around default field sets and presumptions it made about my content (amongst other reasons). With ProcessWire, the ability to have a page with just two fields (if I want) is remarkably underestimated. It means I can customise field layouts appropriate to my content. Even better - it means I can customise field layouts appropriate to my clients content and I choose my CMS on their requirements. Anyway, I made the decision to take a deep breath, take a few weeks to enjoy the extra unexpected free time and to rebuild the site in PW. My business will be 15 years old this January and I thought I'd mark the new year with a new domain, new business name and a new CMS. Here's to new beginnings! - - - - - - - - - - - - - - - - - - - - - - - - - - - Under the hood At the time of writing, the site is running 2.5.10 dev. There's not a huge amount of Modules running in the background. Where I've used a Module, it's been to accentuate back-end functionality rather than the front end. Config allows me to make setting changes directly within the admin. Its a great Module and saves me editing any config files and manually FTP'ing. Lister Pro gives me an easy way to manage the "studio updates". Hanna Code allows me to work with some of the tricker layouts such as the page on PW Forms is used for the Contact Form and I'm using direct embed with some jQuery and CSS to strip out some unwanted formatting. ProCache is running in the background to speed things up. Thats more out of professional curiosity right now Vs any focuseed attention on site speed. AIOM was running recentlyto minify all my style sheets and JS but I pulled it recently. might revisit. Blog module is running the er, blog! I've some work to do there in terms of content layout etc but it's a wonderful piece of work. RenoTheme is keeping everything lovely in the admin Upgrades is a real life saver and allows me to update the whole CMS in a few clicks MarkupSimpleNavigation is powering the menus. Regarding the actual PHP used in templates, I doubt there's anything there of interest to you seasoned PHP guys. I've achieved 99% of the site using simple foreach loops and PW selectors. - - - - - - - - - - - - - - - - - - - - - - - - - - - Background - Why ProcessWire pt 2. When I first heard of PW, I was very content with my current CMS so I had a brief look around the site, read some blog posts but ultimately moved on. It looked interesting but I didn't really have a need to investigate further. Fast forward a few years and realising I need to expand my CMS toolset a bit, I had a better look at PW and downloaded it. I really liked *some* elements and appreciated how I could determine the field layout. You see where this is going? Interest increasing! But honestly? I couldn't imagine putting my clients on front of PW with the theme it had (at the time) and TinyMCE as the default editor. It looked real clunky and I wasn't sure I wanted another CMS with the tree representing pages. Somewhat trivial and shallow reasons not to use something but there we go. I'm a designer and I also have to think about my clients experiences too. But I kept an eye on PW and in the background, a few things were happening which were interesting. Communication from Ryan was frequent, open and transparent Planned updates were being released on or before schedule Unplanned updates were often released on or before I realised I even needed them I discovered TinyMCE could be swappable for CK editor and I could use alternative admin themes I discovered a few Modules for listing pages via DataTables as opposed to tree mode Not really sure of the timeline here but this is from mid 2013 onwards btw. The crazy things is from that point onwards, it seemed increasingly impossible to ignore PW. Every few months there was an amazing leap in either the core features or some brilliant module I hoped for was published. EG: I was looking for a way to decrease the time it takes to publish a page in the right place with the right template and the Add New button appeared I was looking for a way to represent pages in a List rather than a tree and ListerPro was announed Hoping for a better way to upgrade PW and the Update module was released Needing a proper blog with categories and the Blog module was there Looking for a better admin UI and RenoTheme came along Needed more flexible field layouts in a matrix and ProFields released Looking for a way to store chunks of html/php etc and Hanna Code was released Ok, that sounds like an Arethra Franklin song about PW but you get the idea! Seriously, it got to the point where I was either silently (or via the Forums) hoping for a particular feature and Ryan would already be working on it or would just release it having finished it. And it was always done in a much more elegant, scalable and powerful way than I imagined or hoped. Just last month I wrote a forum post highlighting a wish for an admin-based settings module. Thinking "nah, there I go complicating things again. Make do with the config.php file" I deleted it. Literally the next day, the Config module was released. It's spooky! Anyway, I've rambled on a bit. But to sum up - I try to redo my site every few years in a different framework and platform. I can see the front-end framework changing in future but I think EdenStudios has found a good, permanent home in PW. PW and Ryan are doing everything right. It's not the only great CMS but it's a damn fine CMS in great hands supported by a great community.

The site looks nice. You still could do some great optimization. check your .htaccess check the settings about minimization of CSS / JS etc. - I guess your AIOM Settings are not sufficient or not read! check if all your images get minimized enable gzip compression etc. simply read the report and try to eliminate point by point. They have also very good explanations. Afterwards you should be able to reach values which are 90% on Pagespeed and YSlow. With the right .htaccess settings even 95% and higher. When done your site should have a loading time which would be about 1.5sec and lower I hope.

Nice site, lovely write-up!

Why do you feel that it's not the way you should be doing it? The only case where I think there could be a cleaner way is if you only wanted to print a comma separated list of the titles of the items inside the Page-fields. Then you could do <h4>Course Details</h4> <strong>Level:</strong> <?= $page->course_detail_level->implode(", ", "title"); ?><br /> <strong>Category:</strong> <?= $page->course_detail_category->implode(", ", "title"); ?><br /> <strong>Grouping:</strong> <?= $page->course_detail_grouping->implode(", ", "title"); ?><br /> Otherwise, just stick with the loops

I solved it like this: <?php $namepage = $pages->get("template=bfd_people, id=$page->bfd_events_people_id"); $occupation = ucfirst($namepage->bfd_people_occupation->title); if($namepage->bfd_people_original) { $originally = ", originally " . $namepage->bfd_people_original; }; if($namepage->bfd_people_alias) { $alias = " aka " . $namepage->bfd_people_alias; }; echo "<b><a href='{$namepage->url}'>{$occupation} {$namepage->bfd_people_name_first} {$namepage->bfd_people_name_middle} {$namepage->bfd_people_name_last}{$originally}{$alias} </a></b>"; ?>