Leaderboard

Is this already in, "crop sizes from presets"? If we could have that with the core images field, it would make the croppable images obsolete, what I think would make things much easier. We only would need one images fieldtype and optionally can define "presets" or not. Wouldn't it? +1

Version 3.0.18 continues from last week, making major upgrades to our images field. This week we got into some of the finer details, and we've got plenty for you to look at here, as well as a screencast (at the end) to demonstrate it all. https://processwire.com/blog/posts/more-images-upgrades/

Awesome update! But one feature request: Optional disable crops with flexible widths & heights' and enable crop sizes from 'presets'.

I also support these, with the additional idea of turning the labelled buttons into icon only "tools" (supported with tooltips). We need room for the filenames, so the shorter the buttons are the better. Also, we should not forget the case of a single image, confined into a narrow Column Width (mine is 30%). If we take a look at these screenshots, we can see a two glitches in my usecase: Namely #1 proportional grid mode: image extends beyond its column. We can adjust the preview size, however I can imagine a narrow image that cannot be made small enough to fit. #2 list mode: transparency is not handled

What I basically would need is that the ratio is fixed (and there is a minimum of height/width it can't go below). So users can select parts from the image to crop but that crop would always fit 100% and no further cropping would apply when using the image.

With PW 3.0.18 there were again major changes in the code of the core images field that renders the intermediate version invalid, (again). So, atm it doesn't make much sense and also I don't have the time to find a way how to implement the croppable images functionality into the new images field. At least, because there is no easy interface or hooking point supported to archive that. One possible solution could be to make the old core images field a third party module, so that the crop tools can extend this as it was before. Ryan mentioned this somewhere already. Another solution, what I would prefer is, what @Martijn suggested: https://processwire.com/talk/topic/13279-pw-3018-yet-more-images-field-upgrades/#entry120097

Your logic looks strange to me. I'd expect such a check to take a form more like one of the following; if ($page->id == 1021 || $page->id == 1105) { echo "I get run if the page id is 1021 or 1105"; } if ($page->id != 1021 && $page->id != 1105) { echo "I get run if page id is not 1021 and it is not 1105"; echo "ie (In English) I get run if page id is not 1021 or 1105"; } Does that help?

Just to note that the thread linked above is from quite some time ago and talks only about the $db (mysqli) object. Since PW 2.4 the $database (pdo) object has also been available. See https://processwire.com/talk/topic/3515-processwire-24-compatibility-for-modules/#entry34647

Great improvements, indeed! Some minor observations, though: (1) After opening an image field in the editor, it happens that some of the thumbnails are not cropped correctly: https://snag.gy/zP3cVG.jpg Switching the grid to proportional mode and back, they are displayed well. (2) After the upload of an image the "Choose File" button is displayed wrongly (but works as intended): https://snag.gy/SiBY91.jpg (3) The "Choose File" button's caption is in English, even if the editor user's language is German: https://snag.gy/8OSQyP.jpg (4) In the list mode one image takes too much space (so you have to scroll a lot in case of many images). Why not place the green buttons inline with the filename? Like this: https://snag.gy/ioxGDI.jpg And it would be fine if you could even toggle on and off the display of the description fields... But anyway, no ranting here. Kudos for the fantastic work!

This is what you have to love about ProcessWire. Fantastic release last week, some feedback from users, then an even better release 7 days later. 2 small requests from me. Tooltips/titles for the icons for the different views. Reset to default for the slider. Keep up the great work team.

Is not 100% to your request, but maybe of interest too. https://processwire.com/talk/topic/5796-session-handler-database-do-not-delete-old-sessions/

Netcarver beat me An alternative: <?php if ($page->matches('id!=1021|1105')) { echo 'do stuff'; }

Keep in mind that post is very old. We now use $database: https://processwire.com/api/ref/database/ Beaten by @DaveP

Is it a single entry file field? If so, what does $download->of() return? Just in case try this one: $file = $download->download_files->first();

Thanks, what is strange is as i mentioned these appear to be completely random in terms of why they exhibit this error; it may be nothing directly due to TD; some of these that exhibit the error have much less data/info on the page than other siblings which don't crash; i've been trying to figure out if there is some deep error somewhere in the code that could be causing it, will keep tracking it down..

I have just pushed a fix for this - sorry about that! Glad that it's now working without the PW Info panel. I definitely need to make some optimizations there - I will try to take a look at this on Monday. It would be great to be able to replicate exactly what you have going on there, so I will probably come back with some more detailed questions for you. I am actually wondering about the PW Info panel in general and trying to figure out what elements of it you guys are finding most useful and whether some parts should be split into another panel so that those bits that are slow (due to loading large table fields for example) can be in a panel that you only load as needed using the "Once" option in the Selector Panel.

There is also if (! Quick research via Google: For example, take a look at the current last answer here : http://stackoverflow.com/questions/6311040/php-if-not-equal-and-or-issue-why-doesnt-this-work (one example with || and one example with &&).

OK- sorry about this, i did as you recommended and was able to get rid of the error by disabling the ProcessWire Info panel; So yes, something about that panel and not sure if it related to the lines which are referenced in the error which all pertain to track changes.

ProcessWire does not return a response until the admin thumb is generated, therefore it could also be, that the image is successfully uploaded, but something prevented a successful addition to the page or the resizing.

Hey Macrura, What version of TracyDebugger are you running? Also, does it make any difference if you switch from the master to stable version of the Tracy core (in the module config settings). Also, what happens if you disable all the panels in the module settings. If it works with all panels disabled, please try enabling one at a time. I have a feeling it might be the PW Info panel - any chance you have a large Profields Table on these pages - I just came across an issue with this myself today - the PWInfo panel gets a LOT of data loaded in this situation. I need to figure out a way around this. Thanks for helping to figure this out.

This evening I had some time to investigate the UI glitches I mentioned earlier this week and found some solutions. 1. Popover gets cut off The popover gets cut off because of the Ajax loading of the Repeater Matrix items. The items have the overflow set to hidden as an inline style, even when opened. I can avoid this by not loading the items through Ajax, although it would be nice if this could be fixed, because I think setting the overflow of the item to hidden is not necessary, once it is opened. 2. Mix-up in detail view The mix-up in the detail view happened, because in my template I have one image field for a thumbnail and the Repeater Matrix with the slides item mentioned above. Right now I have many pages where the thumbnail field and slides item contain an image with an identical file name. If I try to toggle the detail view of one of those two images with the identical file name, the detail view gets confused and shows details to only of those two images instead separate. I can avoid this mix-up by using different file names, something I should have done in the first place, but just wanted to let you now. I hope I have explained this well enough. Regards, Andreas

Thank you sooooo much! And +1 for Martijn's request

Hi, Mischa, and welcome. Good reading on the subject (which you may have already seen) - https://processwire.com/docs/security/ https://processwire.com/talk/forum/40-security/ Very detailed info on change logs etc - https://github.com/ryancramerdesign/ProcessWire/ Has PW ever been hacked? Not that anyone AFAIK knows about. Could it be? Front end security is your responsibility see https://processwire.com/api/variables/sanitizer/ What about back end? Well, ImageMagick has been found to have vulnerabilities recently, so there is always the possibility of zero-day vulns affecting PW, but that applies to every use of 3rd party libs. (Not a complete answer, but I'm sure others will chime in!)

These should also work (on dev): // save directly from page object $page->save(array('quiet' => true)); // save just 1 field from page object $page->save('myfield', array('quiet' => true)); When quiet mode is set, the modified date is set to whatever is specified in the page. Meaning, the modified date is not updated unless you change it yourself. Quiet mode also lets you modify the modifedUser and createdUser for the page, if you want to. These are two properties you can't usually modify, but quiet mode lets you do it.