adrian

@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!

Hi @tkaranka - sorry about that. However, I am not seeing the problem here, so I might need a little more info from you. That error comes from code dealing with field types that extend Multi - the most common one being images so I am wondering if there is something specific about the setup of that field. Could you please try to dump the value of: $fieldName just before line 159. And also, the value of: count($p->$fieldName) Tracy's bd() will be the easiest way to do this if you have it installed. Thanks!

FYI, I have posted a github request about this name of the Delete tab in the hopes that we can get a little better consistency: https://github.com/processwire/processwire-requests/issues/36

Hi everyone, I have just updated this module to support insertion of Hanna codes, and renamed it to DynamicDescriptionNotes. It passes the $page (for the current page being edited) and $field (for the $field where the Description or Notes text is referencing the Hanna code, so you can use $page and $hanna->field in your Hanna code to refer to these. This opens up lots of possibilities for dynamic content. Please let me know if you have any problems or suggestions. A big thank to @Robin S for the awesome idea! PS, It's now available from the modules directory: http://modules.processwire.com/modules/dynamic-description-notes/

This trash vs delete conversation makes me think that the Delete tab on the edit page interface should actually be called Trash. The page list action button is Trash, but the Delete tab does the same thing so they should be named for consistency.

I guess what you are saying here is if you set the "Estimated End of Maintenance" to a very short time from now, then the Retry-After timestamp will be changing constantly as soon as that initial timestamp point is reached. Is that what you mean but "without a fixed timestamp"? I see that the Retry-After actually allows specifying a timestamp or a delay in seconds, but a constantly changing timestamp would essentially be the same as the "seconds delayed" approach?

Ok, I have committed the new version. A huge thanks to @horst for contributing this functionality. Here are the key new sections to the module config: @Christophe - just pinging you to make sure you see this new functionality.

Yeah, that's essentially what I have done. Any thoughts/experience with this: http://www.nurkiewicz.com/2015/02/retry-after-http-header-in-practice.html What clients do you think they are referring to? I would have thought that search bots might be triggered by this, but doubt they would all hit it immediately at the Retry-After time. As for manual users - that is unlikely also. I guess I could randomize the Retry-After time somewhat - maybe at 1 minute intervals for up to 10 minutes after the entered time, but it sounds like overkill for almost all sites. I'll ignore unless you have any strong thoughts on it.

I'd like to hear more on your thoughts about this, because I was just finalizing incorporating your changes and I was about to add a protected vs maintenance option, because I know that many people use this module to protect a site that is always protected (it is only ever for logged in users), so I am not sure in this case that Retry-After is appropriate, because it will always be inaccessible. I don't really think 503 sounds appropriate either. If you have a site that is protected from public view then you don't care about SEO anyways Is there something obvious I am missing?

Hey @horst - I am happy to add that functionality to this module, but I guess I thought it belong more in Pete's module, but if you guys would rather see it here, that's fine with me. Do you feel like sending me a PR? Otherwise if you post the zip, I can grab the relevant bits and incorporate.