Leaderboard

Thanks Soma, I was able to reproduce it here too. Can you try out the fix I posted to the dev branch? You'll have to undo the page move you did before, and move it back again in order to get it to rebuild its index.

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 !

I wonder what this company could sponsor!

https://stripe.com/global

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.

But I thought about http://www.kickstarter.com/ for processwire modules. Maybe Ryan can choose some privileged developers that are capable of building quality modules. If There's enough interest (money wise) a module can be build. I will start a new Topic !

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");

Field dependencies are coming in ProcessWire 2.4, and I just wanted to give you guys a little preview of it. The development of this new feature is being sponsored by Avoine, the company where Antti works (he also specified how it should work). Field dependencies are basically just a way of saying that one field depends on another. It dictates which fields should be shown in a given context. In our case, it also gets into whether a field is required or not. This short video demonstrates how it works: (switch to the 720p and full screen version, as YouTube's default settings for this video make it impossible to see): // Edit @Adamkiss: Here's link for those on mobile: youtu.be/hqLs9YNYKMM The implementation here is done both client-side and server side. Javascript handles the showing/hiding of fields and the required vs. not required state changes. On the server side, it doesn't process any fields that aren't shown, and honors the required rules. A separate processing occurs both client side and server side, ensuring that the user can't make their own rules by manipulating the markup or post data. These field dependencies can be used with any Inputfield forms. That means you'll be able to use it not just in ProcessWire, but in FormBuilder, and via the API too. It's very simple to use from the API. All you have to do is specify a ProcessWire selector to either "showIf" or "requiredIf" to the Inputfield, and ProcessWire takes care of the rest: // show this field only if field 'subscribe' is checked $inputfield->showIf = "subscribe=1"; // show this field only if 'price > 0' and at least one category selected $inputfield->showIf = "price>0, categories.count>0"; // make this field required only if 'email' is populated $inputfield->required = true; $inputfield->requiredIf = "email!=''"; This feature will be in the 2.4 core (rather than as a separate module), so it will also be ready and available for things like module and field configuration screens.

kickstarter There are several developers here that contribute a lot, working for fun and sharing knowledge giving us wonderful modules. But next to the respect they get, it would be nice we pay for the Cola & Pizza's they need while programming. ( Can hungry programmers code to ? ) For me as individual I won't/can't pay a decent price for good software, but with 10 members things change. Say: If an developer needs $750,- before starting the write. (I'ts only €56,-- per person, not reached, money back ) Then: Every person who paid, can download the finished module. After 3 months: The module becomes normal opensource, available for everyone. Maybe Ryan can choose some privileged developers that are capable of building quality modules. What do you think ?

Hello, i missed some good futures in processwire so i decided to write my own module to do it. In Github: https://github.com/GomatoX/Language-Constants/ Installation is the same as other modules installation. Language constant module creates language_constants table in database. Purpose: This module helps to keep texts editable in cms, not hardcoded. For example, I want to have editable back button text: "back to main", so I just need to add it into language constants modulue as a constant and it would be reachable everywhere in page. How to use: Simply use $lang class and it's method display, example: $lang->display( 'constant_name' ); display( string $constant_name ) returns language constant variable. Known issues ( todo in future ): There is no available support if multilanguage is installed. No cache for constants. Needs optimization. *Still in beta conditions, posted for tests.

Built this Dutch site for friends of mine ( www.talk-about.nl ). It's a lightweight, straightforward website but sufficient for their needs and they are very happy with it. When it comes to computers they are a bit heavy-handed so I ended up doing the content editing myself. That experience made me change TinyMCE for CKEditor which in my opinion feels better. Installed Pro Cache and that makes the site lighting fast. First only could get it to work locally and not on the live server. Appears that Pro Cache is not working when PHP is in safe-mode. Used this as a study project and it made me very exited about ProcessWire.

@horst, I do understand what Ryan said, wise words, and I agree. ( aside, more likely to expect an interview with Ryan Trash over there ) The kickstarter thing is in essence not about earning money. It's about sharing ideas, make plans and work it out, together. Let the kickstarter feel like they're part of the community an let them help to create useful modules/apps. In the end the community will benefit from it.

Why not the people who are sponsoring just do so out of interest to see the project flourish? I agree with Owzim, a big part of Open Source is getting it thoroughly tested and transparent. If the module was right, I'd be happy to contribute and would be OK with others benefitting.

Martijn, This is a good topic. I would be open to contributing (without extra consideration) to module development — especially if the idea was well documented. We would need something like Kickstarter, so contributers would get refunded if the goal wasn't reached.

Makes sense to me. In that case you can create those child pages with the formats, and on that page template create the xml file as you would create an html file just making sure that you tell the browser that this is an xml file. You can do it like this: <?php header ("Content-Type:text/xml"); ?> <?xml version="1.0" encoding="UTF-8" ?> <xml_content> </xml_content> And inside the xml content, just use processwire tags normaly: <audio> <ogg_file><?php echo $page->ogg->url ?></ogg_file> <mp3_file><?php echo $page->mp3->url ?></mp3_file> </audio>

Well now you and all the pw-members have my address - whenever in Stockholm, please abuse it - lunch, beer or whatever shall be on me for any supporters of pw! All the best, //dice

I promised I would share my summer-project when I got a bit further along and now most of basic design is up on the test server (still just test content though, only some of it will be there in production). Two pages remain to be styled and some minor touch-ups are left for sure, but the gist of the simple design should be visible. Clean Scandinavian has been the motto. Will update to publishable version over the coming week/weeks. I will also clean up the code and do some validation fixing etc during that time. Any suggestions, pointers and tips from you pros would be much appreciated (tough love is the ticket). Keep in mind that I am not a pro and that apart from a sole static site I helped a buddy with 10 years ago, this is my first attempt at any of this (html, design, php, cms etc), so spare me the sharpest ax. A testament to the Processwire excellence - and to all of you helpful souls on this page - is that I have been able to get at least this far with no prior experience, so I would like to extend a heartfelt thanks to Ryan, Soma, Teppo and all the rest of you that have helped form this product in general, and taken the time to help me out on specific questions. You truly rock! re le vo DOT se/en

As I can see both sides and maybe some more facettes, I like this: taken from here, the answer to question number 5)

http://processwire.com/about/roadmap/ Summer 2013. Not sure which is the updated schedule?

Yes, there is a hardcoded max of 999 for page numbering (defined here). Built-in pager does give you pagination links further than that, but they only work for numbers less than a thousand. You just have to take care of the rare occasions when for example a search would give more than (999 * pages_per_result_page) results. As the guys are saying in that other thread (I'm sloow today). But that's just how far the page numbering will go and has nothing to do with how many pages ProcessWire is capable of handling without any problem. We've got a site with 30000 pages and another one with 15000 pages. The bigger one is running nicely even without any kind of caching at the moment - and there is a bit more complex than just trivial search involved there. And no performance problems with the smaller one either, just to be clear =). There are even bigger PW sites around I'm sure. I think at least Antti has one in his hands and most probably others do as well. Sure one has to think a bit how to approach things to keep everything nice and fast. But it doesn't require any magic to stay on that road. Common sense and some testing along the way to see little things aren't piling up and you should be fine. In my opinion anyway. And I'm talking about the amount of pages here, not making any statement on whether to have several small sites in one install or not.

Would you want pagination to stretch that far? Doesn't sound great for usability to have a user click <Next> hundreds of times... Or am I missing something?

What I can see as problematic here is, that modules grow an flourish just because very early versions are shared from the beginning making them open to suggestions and bug reports, which is a very important aspect of open source. If you limit the audience just to the people who pay, modules may not become as awesome and user friendly, at least not in early stages. That's just a thought. In general I like the idea very much.

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

right, why not do a kickstarter or indiegogo campaign for some modules.....

GomatoX, thanks for your module. Can you describe what language constants are and how users would utilize them? What would be the benefits over using the existing translation system or multilanguage page fields? I'm on mobile, but when I get to my computer I'll try it out and probably find the answer myself, but wanted to pose the question for the benefit of other users that may be interested.

Finally pushed it to github: https://github.com/apeisa/Finnish-ProcessWire I removed all 3rd party plugins (should they be on same repo?), but left Form Builder there.

Probably not a lot at this point! But very soon Any ideas on what would be next in line? I guess it has to be something Ryan wants to do too!

I seem to have started again (perhaps the best thing to do in these scenarios) and written it afresh. Now seems to work. I think perhaps this is still the way to go. I know reverse references can be made in selectors but I keep thinking I will need an actual field value at some point later in the project. It just feels more solid having an automatic reference between the two. The following code seems to be working OK now: <?php // If form is submitted if ($input->post->submit_update_testimonial) { // Assign empty variables $out = ""; $error = 0; // Check if required fields empty if (empty($input->post->title) || empty($input->post->testimonial)) { $error = 1; $out = "<h3>Please include a title and testimonial</h3>"; } if ($error == 0) { // Set sanitized variables $title = $sanitizer->text($input->post->title); $testimonial = $sanitizer->textarea($input->post->testimonial); $date = $sanitizer->text($input->post->date); $student = $sanitizer->text($input->post->student); // $student_page = $pages->get((int) $student); $student_page = $pages->get("template=student, id=$student"); // $student_page->setOutputFormatting(false); // Find current feedback owner (if any) and remove it $current = $pages->get("template=student, student_feedback=$page"); if ($current->id) { $current->of(false); $current->student_feedback = ""; $current->save(); } // Update any page edits $page->of(false); $page->title = $title; $page->body = strip_tags($testimonial); $page->testimonial_date = $date; // Show/hide page if ($input->post->publish == "") { $page->addStatus(Page::statusHidden); } else { $page->removeStatus(Page::statusHidden); } // If assigned student exists assign it, else set it to empty if ($student_page->id) { $page->feedback_which_student = $student_page; } else { $page->feedback_which_student = ""; } $page->save(); if ($student_page->id) { $student_page->of(false); $student_page->student_feedback = $page; $student_page->save(); } } // end if no errors } // end if form submitted ?> <?php if(!$user->isGuest() && $user->name === $page->name OR $user->isSuperuser() OR $user->hasRole("editor")) { include("./header.inc"); ?> <div id="feedback_item_admin" class="content"> <div class="row"> <div class="large-12 columns"> <div class="content_area"> <div class="row"> <div class="large-9 columns"> <h3>Edit Testimonial</h3> </div> <!-- /.large-9 columns --> <div class="large-3 columns"> <a href="<?php echo $page->parent->url; ?>" class="tar flr">← Return to Testimonials</a> </div> <!-- /.large-3 columns --> </div> <!-- /.row --> <hr> <form action="./" method="post"> <div class="row"> <div class="large-8 columns"> <input type="text" name="title" value="<?php echo $page->title; ?>"> </div> <!-- /.large-8 columns --> <div class="large-4 columns"> <input type="date" name="date" placeholder="YYYY-MM-DD" value="<?php echo date('Y-m-d', strtotime($page->testimonial_date)); ?>"> </div> <!-- /.large-4 columns --> </div> <!-- /.row --> <textarea name="testimonial" cols="30" rows="10"><?php echo strip_tags($page->body); ?></textarea> <div class="row"> <div class="large-6 columns"> <label for="publish">Publish?</label> <input type="checkbox" name="publish"<?php if (!$page->is(Page::statusHidden)) { echo " checked"; } ?>> </div> <!-- /.large-6 columns --> <div class="large-6 columns"> <label for="student">Relates to student?</label> <select name="student"> <?php if ($page->feedback_which_student->id != "") { ?> <option value="<?php echo $page->feedback_which_student->id; ?>"><?php echo $page->feedback_which_student->title; ?></option> <?php } ?> <?php foreach ($pages->find("template=student")->remove($page->feedback_which_student) as $student) { ?> <option value="<?php echo $student->id; ?>"><?php echo $student->title; ?></option> <?php } ?> <option value="unassigned"<?php if ($page->feedback_which_student->id == "") { echo " selected"; } ?>>Unassigned</option> </select> </div> <!-- /.large-6 columns --> </div> <!-- /.row --> <input class="button secondary small drop_down" type="submit" name="submit_update_testimonial" value="Update"> </form> </div> </div> </div> <?php include("./footer.inc"); ?> <?php } else { throw new Wire404Exception(); } Thanks to Martijn for his help.

Stephie, since you are here give processwire a ride, you won't be disappointed

This looks fantastic Ryan, a real great addition to the backend and a huge thank you to Antti also for sponsoring this project. I think we need more sponsors if this is the end result!

I think it's more that so many of us hadn't thought about this before but can instantly see the benefits ryan, not that we've necessarily all been waiting for it before now. I think that's testament to how well it's been implemented.

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

Hi wjkaluza. It's certainly possible to build the XML files in PW, but I'm wondering why you want them. You can build your pages normaly in PW and get all the raw data that you want from them, including raw files. Unless there is some hidden reason, I really don't see why you would build these XML files for one site that you will build yourself (not as an API to serve other sites). As an example: each group of files (mp3/ogg) (mp4/webm/ogv) could be a page (or repeater field) with two or three file fields under a common parent: - audio files -- audio 1 (mp3 and ogg files) -- audio 2 (mp3 and ogg files) -- audio 3 (mp3 and ogg files) - video files -- video 1 (mp4, webm and ogv files) -- video 1 (mp4, webm and ogv files) -- video 1 (mp4, webm and ogv files) You can then, reach them directly with the API or by using page fields on other pages. $myAudio = $pages->get(123) // reach the audio directly with the ID of the page $myAudio = $page->audio // or via a pageField on any other page To put a song on your page, you could do this, for example: <audio> <source src="<?php echo $myAudio->mp3->url; ?>" type='audio/mpeg; codecs="mp3"'> <source src="<?php echo $myAudio->ogg->url; ?>" type='audio/ogg; codecs="vorbis"'> Get a new browser, will you? </audio> This is just an example, there are many other ways to do this in PW. Edit: Another way would be to create a new fieldType that would allow the editor to upload one file in one of the formats, and convert it automatically to the other using something like FFmpeg https://github.com/alchemy-fr/PHP-FFmpeg

This is intentional behavior. Personally I'd prefer to have this as a config setting somewhere, though, just to cover those (admittedly very rare) cases where huge pager makes sense.

That might be a bug/unwanted behavior in core, don't know. But honestly: 999 pages in a pagination? Sounds highly user-unfriendly. I hope your'e just filing a bug here and don't really use so many pages in a pagination =)

Thanks for the fix!

Congrats with getting that project. PW has inbuild pagination for its cms pages (usable as folders, containers, settings, etc) and is made from the core up to be both fast and scalable. No worries with pw when your site is growing to a couple of thousand pages. One of the main reasons why many modx'ers switched to pw. (remember the months of discussions on the forum). So you can safely go for option 1. And I am sure the pro's here are going to come up with some extra tips and ways.

http://processwire.com/api/variables/page/

HI Rafael, PageFields . Beyond that, it depends. Are those categories related to each other or to other things? What's the relationship between "disciplines", "locations" and "themes"? As for the numbers, those look to me like counts of items found in each category? Can items belong to more than one category? Scalability? Those are the questions that need answering before any concrete response can be elicited. Please see the following related posts: http://processwire.com/talk/topic/3579-tutorial-approaches-to-categorising-site-content/ http://processwire.com/talk/topic/4116-best-way-to-structure-a-classifieds-site/

After both Ryan and Teppo pointed me in the right direction, I tried using ftp to create a symlink with no luck. However, FireFTP claims you can but I have not tried it. On a side note, I figured out that my host by default disables shell access and mentions very little about it. After contacting them, they enabled it for me with no problems. Also, this is not related to PW, but helped make the picture clearer. Just my 2 cent.

Interesting solution for creating and managing Gists on Chrome https://chrome.google.com/webstore/detail/gistbox-desktop/pdjgfbgklbmmigkmmdbbhfchdldngkml

Thanks guys, glad that you like how this is looking. Though you are giving me more credit here than I deserve. I didn't realize there would be so much interest in it, otherwise I'd have worked on it sooner! It's been on the to-do list for awhile (with a million other things), but didn't become urgent till I remembered/found out it was needed by the end of August. So figured I better get busy! I like the way they define them there too. Longer term, I'd like to make a new Selectors inputfield that lets you build selectors this way, because it's a little more friendly in some ways, even if less flexible in others. But it's a good option to provide in addition to text input of selectors. However, I'll build that Inputfield later as something separate from field dependencies, so that it can be used elsewhere and by other modules, etc. I agree, especially in the context of the video. Though I also think subtlety is important so that required labels don't become a distraction (especially for common required fields like 'title'). If a field is required, and the user missed the visual que, they will still find out about it when they save. The field dependencies just add (or remove) the "required" class to the .Inputfield container, so the actual look of required fields is dependent upon the admin theme. But I think the field dependencies could do a quick fade-out/fade-in to indicate that something has changed about the field's state. I appreciate the compliment. But this is just not true. There are always bugs to fix, and I'm sure there will be several to find and fix with field dependencies, just like anything else (perhaps more so, given some of the complexity in it). So when those of you on the dev branch start using this, don't expect everything to work perfectly. Instead, experiment, test and tell me when you find something that doesn't work quite right. There are so many scenarios that could happen with field dependencies that it may take a few iterations till we've covered them all. There are also some fieldtypes that may not be compatible with field dependencies. For instance, we don't currently have a way of polling the value from the rich text editors, since they don't update the related <textarea> elements on the fly. We could do it by accessing the TinyMCE and/or CKEditor API functions, but I'm not sure that I want to bundle TinyMCE or CKEditor-specific code into the field dependencies–that's the type of dependency you usually want to avoid in code. So you'll be able to show/hide rich text fields based on the values from other fields, but not based on the values in a rich text field. To be honest, I'm not sure that's a problem though, as I don't see rich text fields as being likely sources of dependencies anyway. Those 3 fields are configured in the template for 33%, 34%, 33% width. Without field dependencies they would all fit on one row. When a field is removed from the mix as a result of a dependency, it simply expands the width of the last remaining field to fill out the row. The concept is really simple. It came about because I didn't like the look of the uneven rows when I started dynamically removing fields as a result of dependencies. While the concept is simple, the implementation proved to be a challenge... it's one of those things I thought would take 30 mins, and it ended taking much longer. Though a good part of that is just that I don't use Javascript every day (I'm definitely not an expert at it), so it can take me awhile to get things right.

About 2 months for me.

I asked the same question from Ryan. It is pretty clever stuff actually: There is also a hint why Ryan deliveres rock solid from the beginning

This is my first attempt with Processwire. I must say that I am impressed with this CMS. I know Drupal, Wordpress, Liferay, Concrete5, and so far, PW would be certainly on top of the list now (perhaps at the same level as Concrete5). My mother had made her own website with FrontPage. So all photos are from her, and I did only structure it with Processwire. The site use basically four templates. 1) Front 2) Front-mosaic 3) Mosaic, and 4) Basic (used in the timeline). The site is not finished. It was done in 20 hours (5 hours for the design process, 5 hours structuring the site, 10 hours creating pages and dumping the photos (there are a lot!). http://irenegiguere.com

TK3, It is very hard to debug without more information. Please post: Using the forum code utility, the code in your template file around the problem area Details of the modules you have installed (though I don't think this is the problem) If you have a test site (front-end) that we can look at, you can post a link here too In your TEST site (local not remote), turn on debug in your /site/config.php. Are there errors reported when you load the page with the empty body? Check your /site/assets/logs/errors.txt file. Any errors reported? Do you get errors/weirdness with other fields? E.g. rich text area field? What if the field is not empty, do you still see the <span> in the output/source? Are you using the default ProcessWire install or are you using some other profile? (Foundation, Bootstrap, etc.) It could be coming from some Javascript. Are you using some JS in that template file? Edit: Searching your output above Google has led me to the module ProcessHeatmap (Heatmap by Userclicks). Are you using that? See below code from here public function setOffset(){ //we assume that the $page->body is inside main layout and add a span //hidden span indicates offset left to make fluid layout handling possible $this->page->body .= '<span class="offset" style="margin:0;padding:0;position:absolute;width:0px;height:0px;"> </span>'; }

This is defined here: /wire/config.php $config->http404PageID = 27; But this is PW. We do not hack the core. So what do we do? Uh, this is PW, we can override this . So, we put our own 404 page id configuration in our /site/config.php $config->http404PageID = 1035;// my custom 404 page A word of caution though in /wire/config.php * Hard-coded configuration options for ProcessWire * These may be overridden in the /site/config.php, but it is not recommended. More info here: http://processwire.com/api/variables/config/

This is a really excellent example of a job posting, thanks Jason! You included all the info that I think people would be looking for. I also think it's very good that you included a timeframe, budget info, and screenshot/mockup. I'm going to point people to this the next time someone asks how they should post a job.

Here are the fields you can set with a Page field: <?php $f = $fields->get("some_page_field"); // InputfieldPage settings $f->parent_id = 123; // ID of allowed parent page $f->template_id = 4; // ID of allowed template $f->findPagesCode = 'return $page->parent->children();'; // alternate code to use for included pages $f->labelFieldName = 'title'; // name of field to use as label (default is title) $f->inputfield = 'InputfieldSelect'; // class name of inputfield you want to delegate selection to // FieldtypePage settings $f->derefAsPage = FieldtypePage::derefAsPageArray; // Multiple pages (PageArray) $f->derefAsPage = FieldtypePage::derefAsPageOrFalse; // Single page (Page) or boolean false when none selected $f->derefAsPage = FieldtypePage::derefAsPageOrNullPage; // Single page (Page) or empty page (NullPage) when non selected The Inputfield settings only affect what is displayed in the admin (i.e. for locating what pages it should display as selectable).