horst

@robert: I want to clarify here for following readers: This is definitely wrong! The artefacts has nothing to do with gamma correction. If you personally want to comment this out, please do so. But please do not give this advice to others, because you yourself have said: If you don't know what it is good for and on the other hand only guessing on something is not enough to give advice to other people that may also do not know for what it is good for. Gamma correction do exactly the opposite of what you say: it does not destroy colors - it saves the original colors. @all: Please read on in the other thread here: https://processwire.com/talk/topic/5889-image-quality-problem-on-resize/#entry57548 or just here: https://processwire.com/talk/topic/5889-image-quality-problem-on-resize/#entry57559

@renobird: Tom, to comment it out is nonsense. It just do the opposite: it save the original colors when resizing, whereas not using it it wash out (some) colors (makes them darker). A very helpful article with tests, examples and explanations is here: http://www.4p8.com/eric.brasseur/gamma.html This article also provides solutions for IMagick and Adobe Photoshop that have the same gamma error in resizing 8bit images! The advantage from Imagick and photoshop over GD-lib is their support for 16bit colordepth. Transfering images into 16bit colordepth do exactly a gamma linearization at first and after that a numbered colortransfer! One way to improve it is to use gamma correction!

Currently I'm not knowing IM, but I'm in!

@adrian: this is a very good starting point! An IM alternative may be good for all that can use it on their hosts. But for all users that cannot, we have to improve the usage of GD.

Hi @humanafterall. additionally to that what I have replied to @robert, it has nothing to do with linearization (gamma correction). The artefacts comes from sharpening the images. Attached is a test with sharpening set to 'none', the default 'soft' and the third image is a rezied version where I have added some noise to yout original image with photoshop. This is common usage: if you have technical gradients with pixel formats use the filter "add noise". How much and if monochrome or colored you may test, but that's the only way I know to avoid these artefacts. You can set / send options in your template like this: $img = $page->images->first(); $img->removeVariations(); $options = array( 'cropping' => true, 'sharpening' => 'none', ); $img = $img->size(768, 436, $options); EDIT: added more clearly that I have added noise to the original image and resized it in PW with GD-lib.

@robert: if you are interested in what it does, you may read the link that is posted in the thread you linked to: http://www.4p8.com/eric.brasseur/gamma.html#introduction In fact with first linearizing to 1 and after resizing linearizing back result in correct images. They are brigther in comparision to the ones resized with gamma errors. These ones results in to darkened images. If you want try it on your own images, you may incorporate a grayscale and / or other colortargets and check the results by the histograms or with the colorchecker in photoshop. But the explanation with examples from Eric Brasseur are really good and detailed I think. Could it be that the posterization is allready in the original images? At a very low scale, but allready there? And yes if you then darken the images together with resizing you end up not seeing it that strong. Sounds possible, right? But I'm not sure. If you have a look to the original image from chrizz in the other thread, you see that it has allready some artefacts, so visually tolerable, but they are allready there. Maybe there are better solutions available then disabling gamma correction. I really would have a closer look to that and test with other sharpening methods. Would you be so kind and send me one of your original images where you get better results without gamma correction? Also usefull a resized one with and one without linearizing and the information what sharpening mode you have used. (I can pm you my emailadress if you want) It is not good that exactly people who do a lot work on their images run in this problems whereas the overall common cases gets better results with it.

Ok, please check with wich charset your template file is stored! (It needs to be UTF-8, what is _not_ the default on Win!) And also you have two charset headers in your code example. The second one overrides the first! EDIT: please, if you want to show code examples, please can you post it as text, using the "<>" - code formatter button? You can simply test if your template file is UTF-8 encoded: try your example with $p->title = utf8_encode("smorebrod"); If this works, than your file isn't utf-8 encoded.

The only thing I can think of is the admin theme. This has changed, but you can still work with the old way, (needs to uninstall the default theme first, under modules)

In Short because on mobile: try to convert your csv file to UTF-8 and Set all other to UTF-8 too

@Ryan: what do you think of adding a method to the WireMail class that tells the user if the currently active Module can send attachments? if(wireMail()->canSendAttachments()) { wireMail()->attachment($file)->to($to)->send(); }

There was a thread about this here: http://processwire.com/talk/topic/5417-using-git-with-a-cms-for-version-control-and-deployment-on-multiple-machines/#entry53501

thanks diogo, you are right. If using it with only one UrlSegment it should work the basic way, but with several UrlSegments it could let into trouble.

Yes, looks like a perfect way!

Ok, I have read in the cheatSheet: So, this is all the same! And therefor I will use $page->fields in future. (It's more close for me. Ok, for Ryan it is more close to use $template->fieldgroup because in his thinking it is obvious that that is the part what gets invoked at the end)

@soma: I have found this here in a script from Ryan and therefor thought it is save to use.

uuh, 20:14 time for crime scene and soup. See you later!

@SwimToWin: to get all fields from a page (template) you can use a snippet like this: foreach ($page->template->fieldgroup as $field) { But you have to check what types of field you can export to csv, I think. I'm not sure but I think so. Or maybe I'm wrong. If you want to check for fieldtypes you do it like if($field->type instanceof FieldtypeFile) // or FieldtypeText, or ...

@Sakkoulas: as far as I understood, every article page has a counterfield that needs to be counted up one and also needs to be displayed into the article page? If so, you can set up a new branch in your page tree, lets say you call it counter and assign a new created template, also called counter, to it. This branch will hold all article pages by its ids. And it has only one additional filed, the counter field. Now you can exclude this from ProCache. With your (cached) article pages you use an AJAX - request to a bootstrapped script (we call it countMeUp.php and it resides in your webroot where we guessing pw's index.php also). Just send the article id to it and get back the current countvalue to display it. // JS in the article pages template $.ajax({ url: '/countMeUp.php', // here is your Ajax-URL type: 'POST', data: { action: 'articleCounter', // only needed if you use this script for more than only the counter articleId: '<?php echo $page->id;?>', }, success: function(data) { // here you have to validate that you have got an integer and nothing else ... // if you have an integer you can assign it to your DOM-node to display it $('span#idOfTheArticleCounterDisplay').html(data); } }); The countMeUp.php may look like <?php // bootstrap PW require_once(dirname(__FILE__).'/index.php'); // validation of untrusted user input if(!isset($input->post->action) || !in_array($input->post->action, array('articleCounter'))) { echo "INVALID1"; return; } if(!isset($input->post->articleId) || !is_numeric($input->post->articleId)) { echo "INVALID2"; return; } // now check if it is a valid page id, we use find to respect hidden and unpublished pages, otherwise we could use ->get() $p = wire('page')->find('id=' . intval($input->post->articleId)); if(0==$p->id) { echo "INVALID3"; return; } // is the found page an article page? you should validate template or something other to be sure if('article-template' != $p->template) { echo "INVALID4"; return; } // uff! - we have a valid id - lets get its counter $parent = wire('pages')->get('template=counter,name=counter'); if(0==$parent->id) { // uhm, someone must have messed up our Page Tree, damn! Where is the Counters Parent? echo "INVALID5"; return; } $cp = wire('pages')->find("parent=$parent,title=" . $p->id); if(0==$cp->id) { // assuming the first call of a new page from the frontend $cp = new Page(); $cp->of(false); $cp->template = 'counterChild'; // or what ever you have set up for it $cp->parent = $parent; $cp->title = $p->id; $cp->counterField = 1; $cp->save(); } else { // we have the counter, lets count it up $cp->of(false); $cp->counterField = intval($cp->counterField) + 1; $cp->save(); } // finally we return the current countValue echo intval($cp->counterField); This is not tested! And yes it could be done more shortened. If you have got it work, you highly want to add some security to it, (sending a hash together with the AJAX that resolves to something what is unique to the article page and not public) otherwise people can mess up your counter by just sending integers to it. EDIT: and everything what you are allready doing to avoid counter manipulation you also have to add into the countMeUp.php.

@Martijn: Normally the module should handle this and all other options simply by adding them to the url in the TinyMCE. Ryan has answered to my post that this should be, but it isn't. Looking to the code shows parts that deal with the params, but they never get executed or after the embed-linkis already created and saved. Haven't investigated further, unfortunately not enough time to do so.

small update: added separate inputfield for HTML signature into config page to solve an issue found by tuomassalo. https://github.com/horst-n/WireMailSmtp/issues/1 version now is 0.1.8

you may try sharpening 'none', but may be to blurry or you try out PageImageManipulator. It has additional sharpening methods (stepResize, unsharpMask).

This one I use for something other, so please modify to your needs (maybe 'saveReady' ): public function init() { $this->addHookAfter('Pages::save', $this, 'hookAfterPagesSave'); } Following code is not tested! // in your function, first get the page with something like $p = $event->arguments('page'); // depends on hooked method // check to avoid endless loop if($p->skipMe) return; // validate if it is a page of the right type, maybe check template if('video'!=$p->template) return; // don't do it for videos that have already their unique id if($p->video_id) return; // get the last used number $data = wire('modules')->getModuleConfigData($this); // get the modules data $id = intval($data['myIncrementalId']) + 1; // get the last used number and add +1 $data['myIncrementalId'] = $id; wire('modules')->saveModuleConfigData($this, $data); // save back the data // save this to the template field $p->video_id = $id; // add this to avoid endless loop $p->skipMe = true; // ready $event->return = $p;

Hi Zahari, with $input->urlSegment you can only use type casting for integers, but that's easy and secure. If you have to use strings with it, you need to validate it. This depends on what you are uses, but possible could be: strlen() min / max / exact in_array() against array with valid values ... and so on It depends on what you need to send as urlSegment.

Hi Zahari, don't forget: $page = $pages->get("video_id=" . (int)$input->urlSegment1); // type casting for untrusted user inputs !!

JPEG compression is lossy, JPEG compression with 8-bit images is very lossy. (http://www.4p8.com/eric.brasseur/gamma.html#introduction) And the GD-lib is not the photoshop engine.