Robin S

Sounds like FieldtypeSelector: Modules > Install > FieldtypeSelector

I can confirm. Seems like a bug to me - I tried sorting on a range of different fieldtypes in the parent page and they all worked apart from a Page Reference field, which gives the error shown in the first post. @Alxndre', I suggest you create a GitHub issue for this so Ryan can take a look.

It looks to me like there is a typo in the core code that means the Wire::changed method is never called. See here... if(($hooks && $hooks->isHooked('changed')) || !$hooks) { But the phpDoc comments for WireHooks::isHooked say... * If checking for a hooked method, it should be in the form `Class::method()` or `method()` (with parenthesis). So it should have been... if(($hooks && $hooks->isHooked('changed()')) || !$hooks) { ...and if you change to that then the hook starts firing. @gebeer, will you open a GitHub issue for this?

You are right - interesting that this has not come up in the forums before (to my knowledge). Thinking of ways of working around this, I think you'll need to find all your city pages without applying any limit so the random sort is only done once. Then you can "fake" the pagination, getting a slice() of the city pages on each results page. This technique for using array_chunk might also be handy: See this post for how you can use MarkupPagerNav outside of its typical use: If you have a large number of city pages you might not want to load them all into memory. So a couple of approaches you could look into: 1. $pages->findMany() 2. $pages->findIDs() to return an array of IDs, then use PHP's array_slice together with $pages->getById() to load each page of results.

The dot syntax for sub-selectors like what you are using should be fine too. The support for this dot syntax was expanded in 3.0.25 to include nested sub-selectors: https://processwire.com/blog/posts/pw-3.0.25/ I think including .id on the end may be redundant though - you could try simply sort=parent.customer

On the "Details" tab of your PageTable field settings:

I tested this with your scripts and body ID and the correct order was maintained, so not sure why that's not the case for you. If you prepend a series of elements then the order will be reversed (because they will each be added as the first child element of the parent, one by one in order from top to bottom). But appending elements should maintain the order. My preference is to use <region> (or <pw-region>) tags for scripts and stylesheets. The idea being you place empty <region></region> elements in your _main.php at the place where you may want to add extra scripts or stylesheets from your templates. Then you can add multiple scripts in a single replacement without an unneeded container div appearing in your final markup.

@theo, the solution proposed in this thread involves creating a dedicated parent for all PageTable pages under the Admin branch of the page tree. Would this not solve your issue? You cannot modify the methods in ProcessPageListRenderJSON.php in a module or in any other way that means the changes will not be overwritten in a future update because the methods in this class are not hookable. Well, not apart from the construct() method anyway, which can't help what you are trying to do.

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.