robert

I’m not quite sure if this is of interest for anyone and if this is the right forum for my post, but I got the client request to build a module extension for Fluency which translates all the text fields in a page with only one click. The module is not really ready for public (or the modules section), as it has no config page yet and was only tested in one ProcessWire installation, but maybe it is useful as a starting point for anyone who is in the same situation as me: https://github.com/robertweiss/ProcessTranslatePage The module checks for fluency-translate permissions and adds a ›Translate and save‹-button to the edit-page. It supports all core language fields, Repeater, FieldsetPage the pro modules Repeater Matrix, Combo and Functional Fields. Caution: for now, the (language-)settings have to be manually edited in the hookPageSave-Method (Lines 64–69).

Hi @adrian, I changed the autoload to true according to your suggestion, so the properties will be added to the $page in the admin as well. Now I get the following error message from Tracy Debugger every time I open an admin page (no error shows up in the frontend): The weirdest thing is: when I duplicate my module and change the classname to something else (TestModule or similar), uninstall the original module and install the copy instead, the error is gone. And when if I remove all the code from the original class except the getModuleInfo method, the error is still there. I checked the behaviour in two other installations, they show the same error. Maybe this is some sort of race condition with autoload modules? I tried to understand the OutputDebugger class mentioned in the error, but did not yet figure out what it does or how it can help ? This issue has no priority at all, but maybe you have an idea where I could look further. Debugging the debugger … ?

Hi @adrian, first of all thanks a lot for your fast and nice reply, this community is always so helpful and motivating! 1) Good idea, I never really used it that way, but I definitely will check it out and change the autoload setting. 2 & 3) Thanks for the hints, I changed the code as you suggested. 4) You are right – in combination with Tracy and usual field configurations, the difference is mostly a formatting preference. As I like using Ray in an external window for debugging, the module helped me to always get identical informations in different environments. Another thing which was important to me is the support for ›subfields‹, so that I can immediately see the content of repeater matrix items inside repeaters inside fieldset page fields etc. etc. (you see the point … ?). The third thing is – as you already mentioned – the support for all kinds of fieldtypes in a more or less consistent and simplified way.

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.