adrian

Is this related: https://github.com/processwire/processwire-issues/issues/38 Take a look at this rough fiddle: http://jsfiddle.net/hw5t2xcu/

https://github.com/ryancramerdesign/ProcessWire/issues/2017 Even though I mention that I know why it was set to 11, now I can't remember, but if you go to Modules > Core > SystemUpdater and change it to 15 (assuming you are on a recent version of PW 3), I think that should get you back to normal.

Just to clarify, these are backups are created by the ProcessWire Upgrades module that Ryan created. If you want to make cleaning up of these (and PW core backups) a little easier, check out Module Toolkit's Cleanup option.

1. In the "modules" db table 2. I assume you mean the settings for the modules? They are stored in the data field in the modules table 3. There are lots of strategies around this - really depends on how you like to update your modules and PW core.

Of course that would be a good idea! I am going to be away for the next two weeks, but I'll add it to my list to do when I get back. Thanks for the suggestion!

I wouldn't ignore it completely just yet. Any chance the error comes back if Tracy is disabled? I am going to be away for the next two weeks, but let me know what you find and I'll take a further look then.

Just clarifying - you actually need 3.0.37: https://github.com/processwire/processwire/commits/dev

Might be good to also check @teppo's swift module as well to see if it also handles things properly. Of course the core wireMail should also work properly, would be good to know the current state of what does and doesn't work.

What about this new fieldtype:

@Soma Using this for the first and it's awesomely flexible - thank you! One problem is that some of the $option parameters aren't correctly overriding the defaults. So far I know that these two don't, but there might be others: outer_wrapper_tag item_wrapper_tag The other suggestion I have is an option (or maybe it should just be the default) is to use the full http url to the icon images. I know this can be adjusted in the theme.php file, but it means you need a custom theme to make this work. The reason I want this is for inserting the icons into an outgoing email. Thanks.

Sorry for the delay on this - just thinking about it again now. Now that I am using the LIVE option with bd(), I think that we can override depth and length limits completely. I have been playing with a new setting that makes these calls effectively have no limits by setting the depth to 99 and the length to 999999. I have been playing with it a bit here and seems to be great. One thing to keep in mind is that because Tracy's LIVE dump method renders object/array levels as you open them, setting the maxDepth so high won't actually do anything to what you see in an object/array that has been stored by the Dumps Recorder (with Preserve Dumps checked) after a page reload, but other than that, I think it works just fine, but I would really like you guys to keep an eye on things and let me know if you notice any issues. Finally, this change does not affect items sent to the error bluescreen or the variables in the Template Resources panel, or the PW Info panel etc - these currently still rely on the maxDepth and maxLength settings in the module config. I am not completely convinced this is a good idea yet, but I am going to leave this checked here and see how it goes. If you try it out, please let me know if you have any problems.

Have you checked that $part is returning what you expect? Any chance it should be $part->id

@horst - you can also simply use: $event->object->field There is no need for $event->object->pagefiles->field You might even want to get rid of that _getInputFieldInstance function completely - doesn't really seem necessary anymore?

Exactly! No judgement intended for you not using having used it Yes, that is where it was failing and returning null.

Ryan added this back in Oct 2013 after the old thumbnails module was released - see his note here:

Haven't read through this in detail, but my quick guess would be the image single vs array issue. $product->img->first()->url Or if you want, you can set the "Max Files Allowed" to 1 on the Details tab of the "img" field settings.

@horst - I might be oversimplifying here, or maybe not I think I have a solution - if you replace: public function _getInputFieldInstance(HookEvent $event) { $field = null; // where we'll keep the field we're looking for $image = $event->object; $page = $image->page; $action = $event->arguments[0]; // find all fields of type FieldtypeImage that are part of the page we're using // or regular image fields with InputfieldImage inputfield assigned $imageFields = array(); foreach($page->fields as $f) { if ($f->type instanceof FieldtypeImage || ($f->inputfieldClass && $f->inputfieldClass == 'InputfieldImage')) { $imageFields[] = $f; } } // loop through to find the one we're looking for foreach($imageFields as $imageField) { // good to get unformatted in case it's a single image field, // because it'll still be an array rather than 1 image $pagefiles = $page->getUnformatted($imageField->name); // TODO: name to lowercase ??? // if the image's pagefiles property matches the one with the // field we're looking at, we have a match. save in $field if ($image->pagefiles === $pagefiles) { $field = $imageField->getInputfield($page); break; } } if ($field) { //$event->return = $out; return $field; } return null; } with this: public function _getInputFieldInstance(HookEvent $event) { if ($event->object->pagefiles->field) { //$event->return = $out; return $event->object->pagefiles->field; } return null; } then it always returns the correct field for the pagefile and it works with Custom Upload Names. Is there a situation you know of where my version won't work?

Thanks for all the details @horst - I will investigate shortly, but just wanted to point out that I am actually hooking before fiileAdded: https://github.com/adrianbj/CustomUploadNames/blob/29985a70e5caeac6e2da3774b8be4a1be725a192/ProcessCustomUploadNames.module#L97 The saveReady hook is only there if the module settings specify to "rename on save" which is designed to keep the filename up to date with any future changes to the name of the page (or any other fields on the page that might be used to set the name of the file).

Sorry - forgot to mention that - I stole that code from the Reno theme. Ryan didn't like that approach, but I still think it is much nicer. Maybe you could add a new Inputfield/InputfieldClass column to the table, so it not only shows CkEditor, but also things like "CroppableImage3" or the input field type used by a Page field, e.g. AsmSelect The Fields List & Values section in the PW Info panel of Tracy has this column - might save you some time to look there first?

Another idea - what about adding the type of the field in parentheses after the field name in the Setup > Fields fly-out menu, e.g.: body (textarea) images (image) headline (text) amount (integer)

Thanks @Robin S - that change was incorporated into the core already, so glad it works everywhere. Thanks again for figuring out the change that was needed and for your thorough testing!

Small request I always preferred the hover effect for showing page list action buttons to be triggered on the entire row, rather than just the title of the page - this makes it much easier as there is much less mouse horizontal movement - left to trigger the actions and then back right to click the required button. I actually find it quite a significant timesaver. .content .PageList .PageListItem:hover .PageListActions{display:inline;-webkit-transition-delay:.25s;transition-delay:.25s} .content .PageList .PageListItemOpen .PageListActions{display:none !important;} .content .PageList .PageListItemOpen:hover .PageListActions{display:inline !important;-webkit-transition-delay:.25s;transition-delay:.25s}

Another possibility for CSV importing by editors is the Batch Child Editor module: http://modules.processwire.com/modules/batch-child-editor/

Wow, that is very weird, but it turns out I can reproduce your problem when I have Tracy disabled on the backend (or completely uninstalled). I don't really know what is going on though - almost seems like Tracy is suppressing the error, which is the opposite of what usually happens Looking at that code in CroppableImage: $attr['data-image'] = $pagefile->getCrop($suffix)->url; This fixes it for me - can you try at your end? if($pagefile->getCrop($suffix)) $attr['data-image'] = $pagefile->getCrop($suffix)->url; The Pagefile exists, but during upload, the crop itself doesn't exist yet, so I think that makes sense, but I am sure it's just that I don't fully understand how Croppable Image works @horst - any thoughts?

Sorry @ukyo - I can't reproduce here. Could you please try dumping $pagefile, $suffix, and $pagefile->getCrop($suffix) just before line 139 to see what we are dealing with. Thanks!