Robin S

Aha, great that you have found the source of the issue. In terms of a bug report, I don't expect anything can be done to guarantee to always successfully remove the temp status in all circumstances - I guess there can always be upload glitches of one sort or another. But what would be helpful is to make sure that files with temp status are removed when a page is (re)loaded in Page Edit, so you are not scratching your head wondering why you can see an image in the field that isn't accessible from the API. The thing is, I thought this already happened, which is why if you upload an image then refresh without saving the image is removed from the field. So I suppose it could be a matter of working out why an image with temp status is remaining in the field and is not removed.

I know how this feels. I'm sure there is some core issue with the admin login that semi-regularly gives me CSRF errors when I attempt to log in but I haven't been able to isolate the conditions to reproduce it - my gut feeling is that it's something to do with an expired cookie. I'm always in a hurry when it happens so I just back button and resubmit the form. To get to the bottom of your issue I expect it could be traced by dumping within the chain of methods that get the data from the database and ultimately deliver the formatted value. But who has time for that when you're on a deadline?

As discussed above, I'm thinking that it is somehow related to multi-language features. I don't work on multi-language sites which might explain why I've never seen it across dozens of sites. I use this option on every site, but never with the "Automatic" option - I prefer to always set the formatted value manually to align with the max files.

Very strange, I've never experienced such a thing before. A couple of ideas... 1. Any chance there is a name clash for "document_pdf" on $page - something setting a custom property named "document_pdf" on the $page object? 2. Does changing the field name to something different fix it? Then maybe change it back to the original name and check again.

I don't believe any such solution is possible. PW relies on SQL for sorting in $pages->find() selectors and SQL doesn't support natural sorting. So I think you'll have to do one of the following: 1. Load all the pages you want to sort into memory so you can sort them with PHP. Not a good solution if you have a large number of pages. 2. Request that content editors insert leading zeros to the numbers you want to sort on, so that standard SQL sorting will be sufficient. This would be subject to human error/oversight and would probably need to be done in a separate field to allow the title field to remain in the desired format without leading zeroes. 3. Use a saveReady hook to automatically parse titles into components and save these to dedicated sort fields. This seems like the most promising option to me. An outline of how you could do option 3... Add 3 new fields to the painting template: prefix (text), number (integer), suffix (text). Add the following hook to /site/ready.php: $pages->addHookAfter('saveReady', function(HookEvent $event) { $page = $event->arguments(0); if($page->template == 'painting') { // Find the last number in the title and get the prefix/suffix before/after the number preg_match('/^(.*\D)(\d+)(.*)$/', $page->title, $matches); if(count($matches)) { // There is a number so populate each sort field $page->prefix = $matches[1]; $page->number = $matches[2]; $page->suffix = $matches[3]; } else { // There is no number so put the whole title into the prefix field $page->prefix = $page->title; $page->number = ''; $page->suffix = ''; } } }); When a painting page is saved this results in a division of the title like below. You would set the visibility of the sort fields to "hidden" for production but I have shown them below for clarity. Now when you want to find painting pages sorted naturally you sort on the three sort fields in order: $paintings = $pages->find("template=painting, limit=10, sort=prefix, sort=number, sort=suffix"); You can sort the painting pages (children of a page with the "paintings" template) in the back-end with this hook: $wire->addHookBefore('ProcessPageList::find', function(HookEvent $event) { $selector = $event->arguments(0); $page = $event->arguments(1); // If page is the parent 'paintings' page if($page->template == 'paintings') { // Set the children selector to sort on the three sort fields $selector .= ', sort=prefix, sort=number, sort=suffix'; $event->arguments(0, $selector); } });

Thanks for the info @adrian. I think for this specific case I'll write a custom import script. I'm already using a custom script for exporting the data so will be pretty straightforward to whip up an equivalent import script. Will definitely spend some time playing with BCE later though - looks really nice.

Hi Adrian, I need to import data to existing pages from CSV and am wondering if BCE might be a solution. I've read the GitHub readme and the module looks like a powerful beast but I'm not quite clear on a few things. 1. My data includes a Profields Textareas field, with the data for the individual subfields in separate columns. My guess is that this will require a custom import script (e.g. using AdminActions) but thought I'd check first to find out if BCE supports importing to fieldtypes that contain subfields. 2. I'm sure this is a silly question, but when BCE is enabled for a page or template in the config options this is for the parent of the pages that you want to batch edit, right? So when it comes to mapping columns to fields BCE is looking at the template of child pages under that parent? Does this mean the module can only work where there is a single allowed child template under the parent? 3. I have BCE set to Update mode but on my first attempt at importing a CSV I get an error message saying that the number of columns in the CSV doesn't match the number of fields in the template. Does this mean any CSV that is submitted for import must contain a column for every field and only columns for fields that exist in the template? There isn't a second step where you connect column headings to field names and can selectively import some columns while ignoring others? 4. The readme mentions CSV field pairings but I'm not sure where this is configured. I couldn't see anything about this in the module config. 5. Does BCE support a Page ID column in the CSV data, so there can be a rock-solid connection when importing data to existing pages? And if I use an ID column can I leave out page name and page title data from the CSV so I don't risk accidentally changing those? Sorry for all the questions, and thanks for the module!

I created this module a while ago and never got around to publicising it, but it has been outed in the latest PW Weekly so here goes the support thread... Unique Image Variations Ensures that all ImageSizer options and focus settings affect image variation filenames. Background When using methods that produce image variations such as Pageimage::size(), ProcessWire includes some of the ImageSizer settings (height, width, cropping location, etc) in the variation filename. This is useful so that if you change these settings in your size() call a new variation is generated and you see this variation on the front-end. However, ProcessWire does not include several of the other ImageSizer settings in the variation filename: upscaling cropping, when set to false or a blank string interlace sharpening quality hidpi quality focus (whether any saved focus area for an image should affect cropping) focus data (the top/left/zoom data for the focus area) This means that if you change any of these settings, either in $config->imageSizerOptions or in an $options array passed to a method like size(), and you already have variations at the requested size/crop, then ProcessWire will not create new variations and will continue to serve the old variations. In other words you won't see the effect of your changed ImageSizer options on the front-end until you delete the old variations. Features The Unique Image Variations module ensures that any changes to ImageSizer options and any changes to the focus area made in Page Edit are reflected in the variation filename, so new variations will always be generated and displayed on the front-end. Installation Install the Unique Image Variations module. In the module config, set the ImageSizer options that you want to include in image variation filenames. Warnings Installing the module (and keeping one or more of the options selected in the module config) will cause all existing image variations to be regenerated the next time they are requested. If you have an existing website with a large number of images you may not want the performance impact of that. The module is perhaps best suited to new sites where image variations have not yet been generated. Similarly, if you change the module config settings on an existing site then all image variations will be regenerated the next time they are requested. If you think you might want to change an ImageSizer option in the future (I'm thinking here primarily of options such as interlace that are typically set in $config->imageSizerOptions) and would not want that change to cause existing image variations to be regenerated then best to not include that option in the module config after you first install the module. https://github.com/Toutouwai/UniqueImageVariations https://modules.processwire.com/modules/unique-image-variations/

@PWaddict, if I understand right you want to set a limit of zero items. I added support for this in v0.1.6.

@dragan, I just pushed an update to the repo (no version number change) that adds the "Source" button to the CKEditor field to make it easier to check/report any issues with source code.

@dragan, everything seems to be working normally for me. If you can paste some CKE source code from a list that is causing you problems I'll investigate.

@dragan, my previous commit to v0.1.4 contained a silly mistake that didn't account for nested lists. Should be fixed now in v0.1.5.

@Ivan Gretsky, this issue should be fixed in v0.1.4.

Cool, will update. Something unrelated I'll just throw out there for the wishlist... it would be cool if the code window in the Console didn't resize proportionally when the panel is resized. So the code window would have a pixel height rather than a percentage height and the result window would have a height along the lines calc(100% - [console window pixel height]). I know you added a lot of neat stuff relating to the code window height (line snapping and keyboard shortcuts) and for all I know this request would complicate all of that, in which case don't worry because it's not that important. ?

Thanks, working well for me as guest/non-superuser on localhost, and when using User Switcher on remote host.

Okay with me as I do almost all development on localhost.

Thanks for adding this feature! There seems to be a problem with the console output though. No matter what I dump the output consists of the entire rendered page. This occurs when using the console as guest or logged-in non-superuser.

@bernhard, thanks for the pull request. I've merged parts of that along with a few more of my own changes. But probably not necessary to do much more with this particular repo though because it really only exists to serve as a quick demo for people like yourself who might like to take the idea further. I'm not feeling possessive of this idea/code at all so anyone is very welcome to take it and use it for their own purposes in any way they like - further developments don't need to happen via my repo. To go further into something that would be more widely useful to the community, shared in the modules directory, etc, would require a new module that doesn't bundle any particular Process module like my demo does. I'm imagining something that would work with any custom Process module. And maybe focuses on the iframe approach because that seems the most promising (I was also playing around last night with the same JS library you mentioned). I might tinker around with something later but anyone is welcome to have at it and beat me to it. ? To respond to some of your points... Great, we don't want that exposed. I wish there was a better way than string replacement on the whole HTML output but there isn't any way I can see to set that part of the JS config object directly and I fear setting $config->urls->admin before the page render could have other unwanted consequences. The redirect isn't really about the ?modal=1 (although that is unwanted) - it's the Post/Redirect/Get pattern. If you look at the core Process modules you'll see that they all redirect after form POST submissions. In any case the specific code within the demo Process module is not something that anyone needs to use, it's just so the demo module renders something visible. What a person puts in their execute methods will depend on what they want their module to do. Incidentally, setting $this->wire('input')->get->modal = 0 unfortunately doesn't solve the problem for redirects as these still have the modal parameter forced onto them. I think the simplest solution for that is just to make sure any redirect URLs include "//" (e.g. use http URLs). I think it is too late within any Process module to throw a 404 exception. The best I could come up with is to check that any URL segment is valid and if not redirect to the 404 page. Maybe someone will discover a better way. Thanks to this post I think I have a solution for this, added in the recent commit. ProCache can run on any page where the user isn't logged in, which for guests will be all pages besides the ones executing a front-end Process module.

The HTML for these elements is not rendered at all - in AdminThemeUikit at least. See $layout == 'modal' and $adminTheme->isModal here. It's a way of calling protected class methods from hooks. See here.

Hi @bernhard, I did some experimentation with an alternative idea for viewing Process modules on the frontend. I put together a proof-of-concept module you might like to check out: https://github.com/Toutouwai/ProcessFrontendAdminPage Process Frontend Admin Page A demonstration of how a Process module could execute on the frontend. This is just a proof-of-concept. Usage Install the ProcessFrontendAdminPage module. Create a new role named "frontend-only". Give this role the "process-frontend-admin-page" permission and no other permissions. Create a new user named "frontend-only" and give them the "frontend-only" role. View the "Demo frontend admin page" on the frontend while not logged into the PW admin. How the module works On install the module creates a "Demo frontend admin page" under Home. This page uses the admin template with the ProcessFrontendAdminPage process assigned. When this page is viewed by a guest they are silently logged as the "frontend-only" user. This allows them to see the rendered output of the Process module. The header and footer of the admin theme are not rendered when the page is viewed. When a user logged into the "frontend-only" account accesses any other page they are logged out. This is for the sake of logged-out users of other roles, so that when they go to log into the PW admin they don't find themselves already logged in as the "frontend-only" user. Taking the concept further You could embed the ProcessFrontendAdminPage output in an iframe on another page, to preserve a global header/footer and avoid conflicts with the admin CSS. You could add extra markup, Javascript and CSS to the ProcessFrontendAdminPage output to make it look more like the rest of your site. You could create additional executeSomething() methods to render different output depending on URL segment. You could create additional pages within your site that use the admin template and assign the ProcessFrontendAdminPage process. I think you would have to use API code to do this. Then in the execute() method you could check the name of the page being viewed and render different output accordingly.

It's strange that the location of the 404 page would affect the trash. An alternative way to hide the 404 page instead of moving it is to hook Page::listable() $wire->addHookAfter('Page::listable', function(HookEvent $event) { if($this->wire('user')->isSuperuser()) return; $page = $event->object; if($page->id === 27) $event->return = false; }); I actually like to go a bit further than this, and say that if a page is in the top level and is hidden and the user doesn't have edit access for the page then it is of no concern to them and they don't need to see it in Page List: $wire->addHookAfter('Page::listable', function(HookEvent $event) { if($this->wire('user')->isSuperuser()) return; $page = $event->object; if($page->parent->id === 1 && $page->isHidden && !$page->editable) $event->return = false; }); In my case I give the 404 page a dedicated template that non-superusers do not have edit access for, and so it is hidden in Page List.

That sounds like a reasonable way to return early if the form is not the one you are wanting to modify. Any problems if you do that?

Not sure sorry, but it's working for me:

If you include a TwilioChannelsConfig.php file with your TwilioChannels module (see the blog post that introduced this approach), this file is only for defining the config fields for the module. It isn't a module in its own right that you can get with $module = $modules->get('TwilioChannelsConfig'). Put all your methods - including your hi() method - into the main TwilioChannels module file. $module = $modules->get('TwilioChannels'); echo "<p>" . $module->hi() . "</p>";

It looks like there are many settings that can be defined for InputfieldSelector, but only initValue can be set via the FieldtypeSelector field config. For the others you have to use a hook. The previewColumns setting controls the columns shown: $wire->addHookBefore('InputfieldSelector::render', function(HookEvent $event) { /* @var InputfieldSelector $inputfield */ $inputfield = $event->object; // Only for the FieldtypeSelector field of the given name if($inputfield->hasField != 'test_selector') return; // Define the columns you want $inputfield->previewColumns = ['name', 'template', 'modified']; });