Robin S

Ooh, this is a great topic idea! Some of my favourites follow - probably several are already known to folks but I think some will be new to many. A number of these were cancelled well before their time but don't let that put you off watching them. Shows by Jed Mercurio - this guy's work is really original. Sadly often cancelled prematurely, I guess just too far outside of mainstream tastes. Bodies: dark and disturbing medical drama. This was the first Mercurio show I saw. So good. Critical: another medical drama, with extensive surgical scenes. Apparently a lot of work was put into making the language and procedures medically accurate. Requires a strong stomach - at first I thought I wasn't going to be able to take it but it's surprising how quickly you acclimatise, probably just like surgeons do at medical school. The special effects models in this are incredible - I have never seen gore effects this realistic before. Line of Duty: police procedural, a bit more conventional which probably explains why it's still being made. Lots of twists and turns and a cut above others in this genre. Judd Apatow's TV work: Freaks and Geeks is essential viewing, and Undeclared while not quite as good is definitely worth seeing. Both cancelled - what were they thinking? Deadwood: one of the best ever HBO shows, and that's a high bar. If only more people had watched it. Everyone knows that The Wire is a candidate for the greatest TV show ever made (IMO it gets that prize), but check out some of David Simon's other work too. Generation Kill is a first-rate miniseries about soldiers in Iraq, and lately I have been loving The Deuce. Can't wait for the next season. If you're in the mood for some very smart and unconventional stand-up then check out Stewart Lee's Comedy Vehicle. For more dark British comedy see Brass Eye - everything made by Chris Morris is gold. I could go on and on, but one last favourite: Everybody Loves Raymond. This is simply the best multi-camera sitcom ever made. It has many of the same qualities I love about Apatow's work - laugh-out-loud funny while maintaining a human heart and tackling some issues that are actually quite serious. It was obviously an influence on him because of all the ELR references in Apatow films. My all-time favourite episodes: S02E11 - The Letter S04E09 - No Thanks S04E18 - Debra Makes Something Good S05E19 - The Canister S06E17 - The Skit S09E07 - Debra's Parents S09E09 - A Date for Peter

https://modules.processwire.com/modules/limit-repeater/

Don't know about the selector arrays version but here is a selector string version: $selector = "template=facility"; foreach($arr_words as $str_word) { $selector .= ", title|facility_jobs.facility_job_title|facility_jobs.facility_job.job_title%=$str_word"; } BTW, when I have a load of fields I need to search across I often find it preferable to use a Pages::saveReady hook to populate a hidden "index" textarea field with the merged text of the other fields in that template and then just search that index field.

What is $view? The PW core does not have the concept of a view that variables are passed to - there are just template files where the API variables are available. I think this is not a core issue but perhaps you are using some third-party templating module in which case you should raise this in the module's support thread.

Try GitLab Snippets - you can make these private. https://docs.gitlab.com/ee/user/snippets.html

Although if you knew that you had a lot of fields to load for a particular page, or were rendering a lot of fields from other pages, then you could use the load options for $pages->getById() - which can be passed also via $pages->find(), $pages->get(), etc - to autojoin the fields you know you will be accessing. That will cut down the DB queries a lot.

Just the things that Ryan says in the blog post mentioned above: But I don't think it's anything to worry about for most websites. Besides this topic I haven't heard of anyone having any problems with large numbers of fields.

That does sound like a lot of fields. Why is it that the fields can't be reused? You do realise that you can set things like label and description (and loads more since this update) in template context? So you can have a field "text_1" and label it "First name" in one template and "City" in another template, etc.

I was just thinking the same thing and giving them names does fix it. But up until now it hasn't been a requirement for button inputfields to have name attributes.

Yes, I get an out of memory error with this simple test module: <?php namespace ProcessWire; class ProcessTest extends Process { public static function getModuleInfo() { return array( 'title' => 'Process Test', 'version' => 1, 'page' => array( 'name' => 'test', 'parent' => 'setup', 'title' => 'Test', ), ); } public function ___execute() { $form = $this->modules->get('InputfieldForm'); $f = $this->modules->get('InputfieldButton'); $f->value = 'foo'; $form->add($f); $f = $this->modules->get('InputfieldButton'); $f->value = 'bar'; $form->add($f); return $form->render(); } }

Yes, I get the same error. Seems to be caused by two button inputfields being rendered in the same form. I have created a simple test case and have opened a GitHub issue: https://github.com/processwire/processwire-issues/issues/653

You have to save a newly created page (including a repeater page) before you can add files or images to it. $added = $p->member_mx_images->getNew(); $added->save(); $added->member_images->add($responseAdded['imageURL']); $added->crm_products_sold = $products; $added->save(); $p->of(false); $p->member_mx_images->add($added); $p->save();

Hi Adrian, what do you think about adding a db() method/shortcut? So just like bdb() but for use (mainly) in the Tracy Console?

Thanks for the new updates @ryan! Do you think for the next week or two the focus could be on bringing the Selectors documentation up to date? This is a really important part of the documentation, especially for new users. New API methods get added to the API documentation automatically which is great, but that doesn't happen for new selector features because the documentation for Selectors isn't derived from code comments in the core. I went back through previous blog posts and compiled a list of things that it would be nice to have covered in the Selectors docs. has_parent now supports multiple values: https://processwire.com/blog/posts/processwire-core-and-profields-updates-2.5.22/#has_parent-selectors-now-support-multi-value The ~= operator now supports words with fewer than 4 characters: https://processwire.com/blog/posts/merry-christmas-heres-processwire-3.0.3-and-2.7.3-and-some-more/#improvements-to-the-operator-in-page-finding-operations Nested sub-selectors are now supported: http://processwire.com/blog/posts/processwire-3.0.6-brings-pages-upgrades-and-link-abstraction/#support-for-nested-sub-selectors It is now possible to sort by custom fields of a parent page: https://processwire.com/blog/posts/processwire-3.0.7-expands-field-rendering-page-path-history-and-more/#whats-new-in-3.0.7 New selector array syntax: https://processwire.com/blog/posts/processwire-3.0.13-selector-upgrades-and-new-form-builder-version/#selector-engine-array-support It would be good to explain about the verbose option for selector arrays too and what circumstances that is needed in. And perhaps some mention of using the Selectors class to merge different types of selector together: https://processwire.com/talk/topic/16651-merge-selectors/?do=findComment&amp;comment=146890 Multiple dot selectors: https://processwire.com/blog/posts/pw-3.0.25/#syntax-and-examples Negative start and limit, and matching by index: https://processwire.com/blog/posts/pw-3.0.46-stocking-stuffers/#support-for-negative-limit-and-start-values-in-selectors Use Fieldtype in selectors: https://processwire.com/blog/posts/processwire-3.0.91-core-updates/ Owner selectors: http://processwire.com/blog/posts/processwire-3.0.95-core-updates/ Use field tags in selectors: https://processwire.com/blog/posts/pw-3.0.106/#a-new-way-to-search-with-upgraded-tags-for-fields If anyone knows any other new selector features not included in the Selectors documentation maybe they could post a reminder about them here? Another thing it would be good to cover in the Selectors docs are the differences between what is supported in a PageFinder selector and what is supported in an in-memory selector. I mentioned a few differences that I know about in a comment here: https://processwire.com/talk/topic/18343-selector-filter-for-multiple-dates/?do=findComment&amp;comment=160451 And perhaps there is a way to bring support for some of those things to in-memory selectors to reduce the differences between the two types of selector?

If I understand right you want to get all the pages that are selected in a given Page Reference field, site-wide. To do this efficiently you do need to use a SQL query - Ryan has shared a code snippet:

That would be difficult to do as it goes against the way ProcessPageEdit works normally - when PPE loads, the values shown in the inputfields are the values stored in the database. So it also raises the question of even if you could do it (maybe save the $input->post data to $session and then hook the inputfield render to load custom content to the inputs) whether it would be a good idea given that it goes against what PW editors will be used to. You might be better to disable the save button with Javascript if the required fields are not filled out. Note also that for text fields there is a setting to use the HTML5 required attribute which has the effect of preventing a page save when the required field is not filled out. With either of these approaches though you should consider how you will handle an attempted save from a PPE tab other than Content (e.g. an attempted save from the Settings tab).

Potentially related issues: https://processwire.com/talk/topic/16685-images-are-not-saved-permanently-with-ajax-upload/ https://github.com/processwire/processwire-issues/issues/132 https://github.com/processwire/processwire-issues/issues/42 https://github.com/processwire/processwire-issues/issues/41 In one of the issues Ryan said that the 1970 timestamp is something that PW does to indicate that the image has not yet been saved, but this should be updated when the page is saved. The first of those GitHub issues suggests that the problem was related to a specific PHP version, and upgrading PHP fixed the issue. So that could be something to try.

Check out the created dates on the copies. There's obviously something not right there, but not sure what exactly. Hopefully someone who knows more about these things can shed some light. Would be worth seeing if you get the same issue with a new clean PW installation. Here is how my table looks for comparison:

Is the cropped copy still there after you save the page? If so then I don't understand how that's possible, because the inputfield gets the images it displays from the field value (in the database), so if you see two images in the inputfield then there should be two images in the field value. Have you had a look in phpMyAdmin to see if you can see the copy in the field table?

Works for me also. Screenshot below has crop saved from the first image: And if I try cropping an image in a field with max files = 1 then there is no "save copy" option in the cropping dialog (as expected).

@adrian, I think there might be an problem with the "Initial differences protected" option when changing the title of a page via the API (and assuming the "Enable for API" option is checked). My understanding is that the initial differences protected option means that the page will not be renamed if it already has a name that is different from the name that would be automatically derived from the title. So if I have a page titled "Foo" and named "bar", and I change the title to "Baz" then the page keeps the name "bar" rather than changing to "baz". But if my page is titled "Foo" and named "foo" and I change the title to "Baz" then the name changes to "baz" because there was no initial difference between title and name. Is that right? The issue is that in renameOnSave() here your test to see if the page should be renamed will fail when it shouldn't because if the title is being changed via the API then in saveReady it will (almost) always be different than the existing page name. I think instead you would need to compare if the existing page name is different than the previous value for the title before it was changed, as only that would constitute an initial difference.

Check that you have AdminThemeDefault set as the default admin theme in /site/config.php $config->defaultAdminTheme = 'AdminThemeDefault';

You are hooking Module::saveConfig instead of Modules::saveConfig.

Try hooking after Pages::added, but you'll need to add a line to save $page within your hook when hooking that method. There's an open issue about that problem: https://github.com/processwire/processwire-issues/issues/648

It's actually not as practical an idea as I first thought because PageRenameOptions mostly works via Javascript, as @adrian explained in the support thread. But for the purposes of your module you probably don't need all the config options that PageRenameOptions provides. The "initial differences protected" option would be the main one and I think it will be possible to achieve that in PHP with the API. I'll give it a try and post something later. I see this the other way around - I think it would actually be better if PW moved to a PHP/API implementation for setting the page name. It's a bit of a problem IMO that there is no API method that provides identical naming to the JS naming in ProcessPageAdd. And I don't think the approach of requiring users of languages other than English to enter potentially thousands of character transliterations into the InputfieldPageName config is ideal. Although I don't work on non-English sites myself I think it would be good to have something like EasySlugger in the PW core, with the InputfieldPageName config only used for custom overrides. So the user only enters a title in the first step of Page Add and the page name is derived from the title in PHP. The user can easily change to a custom page name after that if need be, so it's not much of a sacrifice in return for a more consistent naming system that requires less configuration.