Robin S

@Slav, you might find this module useful for understanding user permissions across your templates: https://modules.processwire.com/modules/process-access-overview/

This finds all 'articleFeatured' articles, but you only need one. So better to do this: $latestArticle = $pages->findOne("template=article, articleFeatured=1, sort=-created"); I wrote that imagickal() function and it doesn't recreate the image on every page load if the processed image already exists. But it was really intended for applying ImageMagick effects - you don't need it for simple image resizing. Rather than add padding in the resized image you should use CSS to keep the image within its container while maintaining aspect ratio. A couple of ways you can do this below - CSS is inline in the examples but you would move it to an external stylesheet. If you don't mind using background images the technique is dead simple. Just adjust the padding-top for the desired aspect ratio (in the example I used your 730:350 ratio). <div style="padding-top:47.945%; background:#000 url('my-image.jpg') no-repeat center center / contain;"></div> If you want to use an <img> tag there's a bit more to it: <div style="padding-top:47.945%; position:relative;"> <div style="position:absolute; width:100%; height:100%; top:0; left:0; font-size:0; line-height:0; text-align:center; background-color:#000"> <img src="my-image.jpg" style="max-width:100%; max-height:100%;"> </div> </div> If you are using a CSS pre-processor you can use a helper mixin, e.g. https://css-tricks.com/snippets/sass/maintain-aspect-ratio-mixin/ But none of this should make that much of a difference when you are using ProCache - your server load should be very low when ProCache is used considering you have no front-end users logging in. You could check to make sure you are not clearing the entire cache unnecessarily - for best performance you shouldn't use the "Reset cache for entire site" option for when a page is saved but instead use the settings on the "Cache" tab of Edit Template to only clear the cache of related pages. But the other thing to consider is if the problem might be due to the host. You could copy the files and DB to a different host and trial that for a bit to see if the problem resolves. A hassle for sure but if you are getting desperate...

I'm not sure what you mean here. There is no prefix to field names that are used in a repeater. For example, if you have the "title" field in your containing page template, and also the title field in your repeater template then the field name "title" applies to both without any prefix. echo $page->title; // the containing page title echo $page->my_repeater->first->title; // the first repeater item's title Or do you mean that in Page Edit the inputfields inside a repeater have a suffix to their name, e.g. "title_repeater1147"? Because you don't need to use that when you get the field in your template.

Yes, there is such an action: PageActionSetStatus

@Zeka's suggestion is the right direction, but a couple of extra things are needed: $your_pages = $pages->find("template=some_template"); foreach($your_pages as $p) { // Output formatting must be off before manipulating and saving the page $p->of(false); // You need to get the formatted value of the markdown field // i.e. with the textformatter applied $p->ckeditor_field = $p->getFormatted('markdown_field'); $p->save(); } Or a shorter way that takes care of the output formatting using setAndSave(): $your_pages = $pages->find("template=some_template"); foreach($your_pages as $p) { // Normally you wouldn't want to save a formatted value with setAndSave() // but in this case we do $p->setAndSave('ckeditor_field', $p->markdown_field); }

I think OR-groups with selector arrays is buggy: I opened a GitHub issue here.

You can avoid some repetition and shorten the way you get field content in your templates like this: // Get the repeater item (the item is a page) $r_item = $page->repeater_field->first(); // Get field content from the item echo $r_item->foo; echo $r_item->bar; echo $r_item->baz;

You probably already know this, but the buttons on the download page just link to the current state of the files in the master and dev branches. You can download at any time and get the latest commits regardless of what version number is shown on the button.

Only if you have already installed it, and this module is not installed by default.

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.