robert

I often had the need for an overview of all used fields and their contents for a specific page/template while developing new websites without switching to the backend, so I made a small module which lists all the needed information in a readable manner (at least for me): Debug Page Fields https://github.com/robertweiss/ProcessDebugPageFields It adds two new properties to all pages: $page->debugFieldValues – returns an object with all (sub-)fields, their labels, fieldtypes and values $page->debugFieldTypes – returns an object with all fieldtypes and their corresponding fields // List all values of a pages $page->debugFieldValues // List a specific field $page->debugFieldValues->fieldname // List all used fieldtypes of a page $page->debugFieldTypes I recommend using it in combination with Tracy Debugger, Ray, Xdebug etc. as it returns an object and is only meant for developing/debugging uses. For now, the fieldtype support includes mostly fieldtypes I use in my projects, but can easily be extended by adding a new FieldtypeFIELDNAME method to the module. I use it with five different client installations (all PW 3.0.*), but of course there might be some (or more) field configurations which are not covered correctly yet. Supported fieldtypes Button Checkbox Color Combo Datetime Email FieldsetPage * File FontIconPicker Functional Image ImageReference MapMarker Multiplier Mystique Options Page PageIDs PageTitle Radio Repeater * RepeaterMatrix * RockAwesome SeoMaestro Table Text Textarea Textareas Toggle URL * The fields with complete subfield-support also list their corresponding subfields. Installation Download the zip file at Github or clone the repo into your site/modules directory. If you downloaded the zip file, extract it in your sites/modules directory. In your admin, go to Modules > Refresh, then Modules > New, then click on the Install button for this module. As this is my first ›public‹ module, I hope I did not miss any important things to mention here.

Hi Adrian, you are absolutely right! As soon as I switch output formatting off, the results are identically. Thanks for the fast clarification ?

What a coincidence! Just one second after my post, I found this topic and horsts answer helped me as well. Thanks a lot, horst! ? I still don’t understand why there were differences between command line and browser, but when I add $img->first()->filename, I get identical results (although the maximum file amount in the imagefield was set to 1, btw).

I’m trying to get the filename of a file in an imagefield via command line, but there seems to be a difference between the API access via browser and via command line. When I try the following (reduced case): $img = $pages->get('/')->name_of_imagefield; var_dump($img->filename); var_dump($img->basename); var_dump($img->url); var_dump($img->path); I get these results: Browser (as expected): filename: full path to file including name (e.g. /var/www/public/site/assets/files/1/filename.jpg) basename: only name without path (e.g. filename.jpg) url: webroot-based path to file including name (e.g. /site/assets/files/1/filename.jpg) path: NULL Command Line: filename: NULL basename: NULL url: webroot-based path to file WITHOUT filename (e.g. /site/assets/files/1/) path: full path to file WITHOUT filename (e.g. /var/www/public/site/assets/files/1/) What am I missing? Or is this normal behaviour and I just never noticed before? The website is running Processwire 3.0.94 with PHP 7.0. Thanks a lot for any help!

Hi Henning, I had similar problems with 1&1 and fixed them by installing PW locally, then moving everything to the server (db via phpmyadmin), changing the config.php with the 1&1 db-credentials and finally adding the following line in the config: $config->dbSocket = '/tmp/mysql5.sock'; Not sure where I found it, but worked for me

@horst: I’m sorry if my comment sounded like an advice or a complete solution, which is definitely wrong. I just wanted to say that it worked for me and it removed the posterization in my images. I got your link on the other thread with the explanation, I obviously missed it before – thanks for the info!

Hi everyone, I had a similar problem with posterization/banding in darker image areas and found out the same workaround as chrizz (commenting out the gamma correction lines). I’m just guessing, but is it possible that the first gamma correction creates tonal gaps in those areas which can’t be fully reproduced afterwards? Btw: here is a new post which seems to describe the same problem: http://processwire.com/talk/topic/5889-image-quality-problem-on-resize/

Hi humanafterall, I had a similar problem with the resizing function and posterization in dark image areas, my workaround was to comment out the gamma correction in the Imagesizer.php (lines 247 & 387). I’m not sure what that function is good for, but now everything looks good. There is a similar discussion going on over here.