Leaderboard

Thanks to Renobird and LostKobrakai, ProcessWire’s images field has been re-designed and redeveloped with a lot of great new features we think you’ll love! This new images field is available for use now in ProcessWire 3.0.17. The linked blog post covers it in detail. There’s also a screencast at the end that shows you the new images field in action. https://processwire.com/blog/posts/major-images-field-upgrade/

In addition to @teppo and @szabesz, there are more usecases what are currently seems not to be covered well. I must admit that I first also have thought that we need the list view too. But now, after playing around a few times in the last two or three weeks (with an unofficial beta, thanks to @Lostkobrakai) I'm not even torn. I have learned to live without the listview. Usecases that are not well covered atm, for example are image rows with 20 motives that all look the same, where you need the filename, and I mean the filename of all files at once. What I come up and tested (in context of the croppableimages extension) for this are two things: one can toggle visibility of filenames over the thumbs using a little textbox for filtering by filename This is even faster than looking through an endless list of filenames. Another usecase sometimes may be to directly see the aspect ratios of all images at once, not a nice looking centered cropped square. But you will not get that WOW-effect with a visually cluttered grid, also covered with filenames all over. So IMO it depends on the usecases and the user preferences: As you also can see in the second screen, media queries are respected. This isn't what I have done, this is already in the new core imagesfield! (@szabesz: there must be a glitch somehow with your device / version) I simply have extended the new core image field and was able to use comfortable supported hooks from the core field. Here seems to be all usecases already covered on the developers side! Conclusion: with every newly introduced thing, first part is a confrontation with no more able to behave the same as before (we, the users / developers) (sorry for maybe long and bad describing words, but I think you get it) Phase two should be to find some time, play around and try out that new thing, and if you find a usecase that isn't covered well now, don't simply say we need to implement the old way here for that. I personally think I'm oldschooled in many things and also not a friend of often changing things, but I'm so happy that I have had the chance to get my hands that early to the new imagesfield and in addition also found the time to play around with it! As one result, now I have improved my own behave / workflow in some usecases and are also able to give my clients a very well looking edit page, so that they can see and say: WOW! EDIT: and sorry if it looks that I shamelessly promote the croppable extension here. The new core imagesfield from @Renobird and @Lostkobrakai allone is responsible for all the ongoing new things. I wouldn't have done anything without it and also simply wouldn't be able to do things like I now could do. This all depends on the core imagefield. Most things what I have done to adapt the croppablefield with it, was to strip out great parts from the PW2 version so that all the design and magical stuff is delegated / handled from the core imagefield.

I don't really see what we're missing feature-wise here either, but that being said, I do have to admit that originally I was under the impression that this was going to be a replacement for the old grid view (which never made much sense to me, especially considering how it lacked so many features), not both the grid and the list view. The thing is that I too would prefer list view in some cases: especially when the images are intended to be displayed on the front-end as a list, it would make sense that they're displayed as a list in the back-end too The screenshot above displays two obvious use cases that could be handled better: backgrounds for transparent images (use a grid, not solid colour, just like we did for the old image field) and narrow fields (instead of trying to cram everything side-by-side, in some cases it would make sense to have the image on the top and other elements below it). Additionally this UI doesn't make as much sense for the single-image use cases as it does for galleries and such. In my opinion it would be good to have the option of disabling the buttons on a field-by-field basis. Additionally it feels a bit awkward that even though there's only one image, one still has to click to see the edit fields; though this might be a question of preference, it's also one of the cases where the old list view made more sense to me. That being said, this is a great update, so big thanks to everyone involved. I'm sure we can iron out the glitches and improve the usability of the field in some situations now that the new field is in the core. It's typical that some additional requirements only arise after a feature is in wider use

Thanks for everyone being involved! I have one issue though, see image: This is a transparent png, a completely white logo that used to be visible, thanks to ProcessWire properly dealing with the issue (before the upgrade). Now we cannot see it anymore, also the new layout and the new buttons are useless in this usecase. The logo is horizontal (a lot wider than its height) and now I might want to set its Column Width a lot wider so that the image is not rendered in such a tiny size. However, I cannot see the image anyway, so for the time being this width might do... BTW: I will never want to crop the image (being a site logo, it is already resized to my liking), it will always have only one variation, so these buttons can clearly be useless, just take up precious space. Also, what if I do not want clients to fiddle with crop? It would be nice to have options to turn these button on/off. Say, on the Input tab where Column Width can be set among other options. I'm also missing a list view. Actually, for basic needs, the old way of doing things worked better. Now we have a lot of bells and whistles, but some basics needs are not fulfilled anymore. I hope this will improve in the future. Thanks anyway! EDIT: please read teppo's comment below, too. He did a great job of further clarifying what I meant.

Can you describe in more detail what worked better in old UI? I agree that there should be some nice tiled background for transparent images, but is there some other basic needs that are missing? I personally think that this is one of the "wow, that looks easy" moments for customers. Even more than before. Image fields used to take a lot of space in list view and old grid was lacking in features. Great work Tom, Benjamin and Ryan! It is also great to see more and more community effort in ProcessWire core dev!

My first module release. GitHub: https://github.com/Toutouwai/HotkeySearch ProcessWire module that adds configurable hot keys for easier use of the admin search via the keyboard. Uses Mousetrap for key bindings. Module provides two hot key bindings: Jump to and focus admin search input. Also handy for quickly getting to the admin menu tabs when they have scrolled outside the viewport. If you change your mind, tab out of the search input and press the hot key again and the viewport will jump back to your previous scroll position. Uses 's' key by default. Trigger link for focused search result. If you use the arrow keys to highlight a search result this hot key allows you to trigger the link from the keyboard. Uses 'enter' key by default. The hot keys are configurable in the module settings. Hot keys only fire when you are not inside an input, textarea or select. This module is only intended for use with the default admin theme. Admin Theme Reno already binds the up arrow key for closing the search input and doesn't show a visual highlight for search results focused via the keyboard so the module would be less useful there. Much credit goes to Soma's AdminHotKeys module. As an aside, I'm don't know if the admin search was meant to allow result links to be triggered with the enter key by default. I noticed a Javascript error when focusing search results but not sure if that's to blame.

I made a little module to address this issue.

A small, but hopefully useful timesaver - I have added a new method: TD::debugAll() debugAll() da() This will output the content via all dumping/logging methods: barDump(), dump(), fireLog(), log() This can come in handy when you want the expandable tree that you get with barDump, dump and fireLog, but also want to store in a log file for later comparisons. It can also be useful in AJAX calls or some other instance when you're not sure if barDump / dump will work or not, or if there is a page redirect which causes them to disappear from fireLog / dump Obviously this will be a little slower (depending on the complexity of what is being dumped), so maybe don't use it by default, but it's as another useful timesaving tool in your arsenal. Note - you'll need to enable the debugAll() and da() shortcuts in the config settings.

I really love the enhancements you show horst - showing the names and filtering will be very helpful. This can be done automatically via CustomUploadNames (http://modules.processwire.com/modules/process-custom-upload-names/), but I would also like to the option for manual renaming in the core.

Thanks teppo! You saved me a lot of typing by clarifying what I meant

v0.0.2 - follows better module naming conventions. https://github.com/Toutouwai/ProcessHotKeySearch/ I've become aware of an issue when using the hot keys in Page Edit where the page has unsaved changes. On hitting enter on a selected search result the unsaved changes popup is bypassed - not by the selected result URL but by the fallback behaviour of the search box itself, which navigates to "/page/search/?q=..." Am trying to find a solution to this. Any suggestions welcome. Fixed now in v0.0.3

The admin search is great because I find it the fastest way to move around admin. But is it possible to select a result from the list via keyboard only? When results are showing I can move the highlight up and down with the arrow keys but Enter does not navigate to the selected item. Is there some other key that does this? I use the default admin theme and I'm a Windows + Firefox user if that matters. Edit: there is a Javascript error associated with the search module which may be the cause of the Enter key not working as expected.

Is Adrian actually a French Canadian called Tracey DeBugger ? :-/

The old list view is not that useful anymore, but seeing the list view of the Variations, now that is what (or something similar to it) would be useful. That way we could see the complete filename, for example. Some Ajax driven editing features would be quit useful too. This is not a media query issue, the "box" is narrow on a wide viewport, because I adjusted its Column Width setting (30%). Do not get me wrong, I realize that these new features are big improvements, it just feels a bit 1.0

Here is the related old blogpost: https://processwire.com/blog/posts/quality-assurance-for-images-in-rich-text-fields/

Looks very well plus great functionally additions – thanks to all involved people for your work! PS: What are you think about renaming an file in the backend (i.e. for SEO adaptions)? This is the only thing I've sometimes missed.

The truth is that the Tracy module is only a cover. It's adrian who analyses your code in the background