Robin S

I can't reproduce this. When I hook after Pages:added and dump the name of the added page this only fires once. In Pete's code a page is added inside the hook. If you hook after a page is added, then add another page in the hook, you will have two pages. I'm surprised this doesn't cause an endless loop actually. BTW, you can skip the first step of adding a new page by setting the "Name format for children" option on the template of the parent page.

I don't think this issue is PW-specific, it's just how AJAX works. You cannot download a file with AJAX. These may be useful: http://stackoverflow.com/a/14774375/1036672 http://stackoverflow.com/a/13322848/1036672

If you are loading the page that contains the form but the form has not been submitted then none of the form inputs will be in the post data. So that has no impact on anything you are doing with $input->post. If the form has been submitted then the form inputs will be in the post data - a form input might be empty but there will still be a post variable for it. So you can check for the presence of any post variable, empty or not, like this... if($input->post->my_input !== null) { // ... } Doing it this way you don't have to add anything extra to your form, but if you have several different forms with different inputs you need to adjust the test so you are always checking for a post variable that matches the name of an input if that form. Alternatively you could add a hidden input to all your forms - for instance, you could call it 'form_page_id' and put the ID of the page containing the form in it. Then you can use the same test on every form... if($input->post->form_page_id) { // ... }

Not sure I understand. If you removed the form element named 'submit' then it follows that there will be no post variable named 'submit'. I take it you were checking $input->post->submit to see if the form was submitted. Can't you just check for another post variable for which the corresponding input is still included in your form? It could be a hidden input that always contains a value.

$my_users = $pages->findMany("template=user"); // add whatever extra conditions to the selector Does this not work?

I'm not aware of anything that is known as a repeater "item ID". When you use the get() method this is not something that is specific to repeater fields - it is simply the WireArray::get() method (because a repeater field returns a kind of WireArray). If you give it an integer argument then this is assumed to be the index of the item. But you could supply a selector instead, or an array of keys, or anything covered in the method documentation. Nothing weird here either - a repeater item is a Page object so of course you can get its ID property, same as any other page. That looks fine to me. The remove() method expects an object or an index argument - in your case the page object is probably most suitable. How you get the page object you want to remove is up to you - if you already know its ID then what you are doing is fine.

You cannot directly change a text field to an integer field, but you can... 1. Create a new integer field 2. Add the integer field to the template that has your text field 3. Copy the value of the text field to the integer field using the API: $items = $pages->find("template=my_template"); foreach($items as $item) { $item->of(false); $item->my_integer_field = $item->my_text_field; $item->save(); } 4. Check that the values have been copied successfully, and if so remove the text field from your template and then delete the text field.

Hmm, I just tested this and it works for me. That is, $page->isChanged() returns true after uploading an image to a repeater item and saving the containing page. And I checked on an existing repeater item as isChanged() is always true for new pages. So weird that it isn't working for you.

@MaryMatlow, see the sort() method. function bsRenderPortfolio($portfolio) { $portfolio->sort('my_field_name'); // insert the name of the category field you want to sort by // ... }

I think you need to save the new page before adding the repeater item to it. $p = new Page(); $p->parent = wire("pages")->get("template=something"); $p->template = 'some-template-name'; $p->name = 'some-name'; $p->save(); // save the page here $r = $p->repeater->getNew(); $r->field1 = 'somthing'; $r->field2 = 'somthing'; $r->field3 = 'somthing'; $r->save(); $p->repeater->add($r); $p->save(); // save again after adding the repeater item

Is there a reason why your year field is a text field and not an integer field? If you use an integer field it will sort as you want it to.

You could try hooking after saveReady for the repeater pages themselves: $this->addHookAfter('Pages::saveReady', function(HookEvent $event) { $page = $event->arguments[0]; if($page->template != 'repeater_history') return; if($page->isChanged()) bardump('CHANGED'); });

The first two arguments to the size() method are expected to be integers, so your $options array is being cast to an integer. Maybe you intended: src='{$port_item->images->first()->width(414,$options)->url}'

I tested this and can confirm. It's quite a weird bug - I suggest you open a GitHub issue for it. A few more details based on my tests: It isn't related to adding another searched field in the ProcessPageSearch module settings - the bug also occurs when only the title field is searched. It occurs only when searching for a string that is part of a word and does not start at the beginning of a word. For example, if I have a page titled "My amazing page" then... "maz" will match the page (2 or 3 character searches work) "mazi" will not match the page (4 or more characters not at the start of a word do not work) "amazin" will match the page (any number of characters will work so long as they start from the beginning of a word) Only pages are affected - the bug does not affect field, template or module results within the admin search.

I also think a Page Reference field in conjunction with Connect Page Fields would be a good way to go. But not sure that you need a tree structure for the 'date' pages that is broken down into year, month, etc as per @Sérgio's suggestion. You could just have a single 'dates' parent and each 'date' page has a date field (you could create a pseudo-year/month/day structure for your event listings via URL segments if needed). In your 'event' page you select an existing date page if one exists or create a new date page as needed. The date pages are not children of the event pages but are connected to them via the two-way connection provided by Connect Page Fields. Edit: one issue with this approach might be that as time goes on you could get a large number of date pages cluttering up the inputfield, and you couldn't do something like limit these to only future dates in the Page Reference field settings or else if you edited an old event the selected pages would be invalid. Maybe the autocomplete inputfield would be a good solution. Alternatively, if you went with the Repeater approach you would do something like this: Find all repeater 'date' pages by template, sorted by date (you may need check_access=0). Foreach those date pages, getting the event pages associated with the date with getForPage(). If you wanted only a single date heading when their are multiple events on that date, in the foreach you would only output the date heading if it is different from the previous date heading.

That sounds interesting - could you say a bit more about that? Does your module have support for recurring events? Variations to recurring events? And does it have a calendar interface in admin? PW really needs a good calendar/events module.

All fields in PW are custom fields. And you can't save content to a page without an actual field added to the page's template to hold that content (in your module you are only dealing with inputfields which themselves do not save their content to the DB). If you like you can add tags to your fields to create groups of fields within the fields list and keep things tidy. As @Macrura said, currently the only way to add a group of fields to a template in the form of a single unit is to create a repeater with those fields and limit it to a single repeater item. Or if you prefer, a PageTable or Profields Table in conjunction with Limit PageTable or Limit Table. Another approach that I sometimes take (if the project is well planned out in advance) is first create a template with the fields/fieldsets that will be used on all templates, and then I duplicate that template as the starting point for each additional template.

Thanks, interesting discussion in that first GitHub issue. It's the second GitHub issue that got me thinking about this in the first place. I understand that the current implementation only checks against the inputs in Page Edit, but that neglects the cases where a page may be created/populated/published via the API, which is an equally valid way to publish content. The way I think of the 'required fields' feature is that the fields are 'strongly recommended' rather than strictly required since it is possible to leave required fields empty in many different ways. But the feature should provide the information that a field has been marked as 'required' for this circumstance (template overrides, 'required if' settings, etc), and that information should be available from the API as well as Page Edit. Will look into this some more and consider placing a GitHub request.

Does PW have any API method for checking if a given field is in fact required on a given page? I'm thinking here of fields with a 'Required only if' condition. Or do I have to write my own code for parsing the field, operator and value from the $field->requiredIf string and checking against the page's fields? I know about the functions in inputfields.js but I want to check the required status in PHP.

As I said, that error message should include file name and line number. Maybe easiest to just post a screenshot of the error message.

Excellent tutorial. Not too verbose at all - I appreciated the detail and thoroughness. Good idea using the footnotes. The tutorial was really well structured, the way you worked through the essential steps in order and ended with optional enhancements. Thanks for a great read!

PHP has a useful array_chunk function: it is used to split an array into a number of smaller arrays ('chunks') of a size you specify, which are returned to you in a new array (i.e. an array of arrays). ProcessWire doesn't provide a method for WireArrays that is the equivalent of array_chunk, but we can add a new method for this in hook. In /site/init.php... // Add a new 'chunk' method to WireArray, the equivalent of PHP's array_chunk $wire->addHookMethod('WireArray::chunk', function($event) { $wire_array = $event->object; $size = $event->arguments[0]; if( !((int) $size > 0) ) throw new WireException('WireArray::chunk requires an integer $size argument greater than zero'); $array = array(); $count = count($wire_array); for($n = 0; $n < $count; $n += $size) { $array[] = $wire_array->slice($n, $size); } $event->return = $array; }); Now we can use this new chunk() method on any WireArray to return an array of smaller WireArrays. Remember that many array-like objects in PW are WireArrays, including PageArrays, Pageimages and Pagefiles. An example using a PageArray of 'workshop' pages. We are running a series of workshops and there is only time for four workshops per day, so we want to divide the workshops into groups of no more than four and put each group under a heading... // Get all workshop pages $workshops = $pages->find("template=workshop"); // say this returns 12 pages // Split the workshops into PageArrays of no more than 4 pages each $chunked_workshops = $workshops->chunk(4); // an array of 3 PageArrays of 4 pages each foreach($chunked_workshops as $key => $chunk) { // $key is the zero-based index of the array $num = $key + 1; // Output a heading followed by the workshop links echo "<h3>Day $num</h3>"; echo $chunk->each("<p><a href='{url}'>{title}</a></p>"); // $chunk is a PageArray } Another example, this time using images. Say we want to divide the images into groups of three or less - maybe they are to be arranged into rows or we are giving the groups some special styling. // Say this page's 'images' field holds 8 images // Split the images into Pageimages objects of no more than 3 images each // 8 does not divide evenly by 3 so the last Pagesimages object will contain only 2 images $chunked_images = $page->images->chunk(3); foreach($chunked_images as $chunk) { echo "<div class='image-group'>"; // $chunk is a Pageimages object foreach($chunk as $image) { echo "<img src='{$image->size(300, 300)->url}'>"; } echo "</div>"; }

In your code $wireTempDir will only give the path to the temp directory, but file_put_contents() requires a filename too. So something like: file_put_contents($wireTempDir . '/temp.pdf', $output);

Your first post is missing the information needed in order for people to help: what file name and what line number is triggering the error? The error message should include that.

More likely than this, you just have one or more of... wrong database name wrong database username wrong password for that username ...in /site/config.php Your host should have some control panel (cPanel, Plesk, etc) where you can... check the database name check the database username reset the password for that username ...and then update /site/config.php accordingly. Edit: sorry, I spoke too soon. The error message for wrong db user/pass is slightly different. So it must be either wrong database name (hopefully) or no database at all (oh dear ). P.S. I know it's not much help now but as @cstevensjr mentioned these two modules are essentials for every PW installation IMO: http://modules.processwire.com/modules/process-database-backups/ http://modules.processwire.com/modules/cronjob-database-backup/