horst

@interrobang: Great! I will try to test it in the next days and give some feedback. But because the issue with "upscaling = false" I'm 99% sure this is a bug in imagesizer and not in your module. It is allready filed at GitHub: https://github.com/horst-n/ProcessWire/commit/6640df43212620532bcd7c24c5936823178d3af6

This with the Textareas in COnfigurable Modules I have tracked down to this line: https://github.com/ryancramerdesign/ProcessWire/blob/master/wire/core/InputfieldWrapper.php#L300 Before this line the content of $ffout looks like: "\n<textarea id=\"Inputfield_textarea-value\" class=\"InputfieldMaxWidth\" name=\"textarea-value\" rows=\"5\">line one\r\nline two\r\nline three\r\n</textarea>" and after processing the preg_replace, $ffout holds "\n\t\t\t<textarea id=\"Inputfield_textarea-value\" class=\"InputfieldMaxWidth\" name=\"textarea-value\" rows=\"5\">line one\r\nline two\r\nline three\r\n\t\t\t</textarea>" I have filed an issue at GitHub: https://github.com/ryancramerdesign/ProcessWire/issues/759

What is the content of contact.inc? Or why is it outputting directly? If you want to go the delayed route, you should wrap an $out .= "..." around the content of contact.inc. At least this is how I do understand that concept. Your variable in contact.inc could be $contact = " .... "; and then you add it to your sidebar: // $sidebar is allready available in your main.inc if ( pseudo code says I need contact information ) { include('./contact.inc'); $sidebar .= $contact; // $contact is initiated in your contact.inc } if ( pseudo code says I need teasers ) { include('./teasers.inc'); $sidebar .= $teasers; } if ( pseudo code says I need teasers elsewhere) { include('./teasers.inc'); $footer = $teasers . $footer; } ...

I remember that this is also with configurable modules, if you have a textarea in a config screen where you should add params one per line, for example, and if you simply end the last line with a "new-line char", line one (new-line-char) line two (new-line-char) line three (new-line-char) hit submit, you will get back your content with three tab characters added! If you do nothing but only hit submit once again, you will get three more tabs added, and so on and so on. Whereas if you let out the last "new-line-char", you will get back only the content you want, without added tabs: line one (new-line-char) line two (new-line-char) line three This is with PW 2.3, 2.4 and 2.5, you can test this simply by make the HelloWorld Module configurable: class Helloworld2 extends WireData implements Module, ConfigurableModule { public static function getModuleInfo() { return array( 'title' => 'Hello World 2', 'version' => 2, 'summary' => 'An example module used for demonstration purposes.', 'href' => 'http://processwire.com', 'singular' => true, 'autoload' => true, 'icon' => 'smile-o' ); } public function init() { } static public function getModuleConfigInputfields(array $data) { $form = new InputfieldWrapper(); $field = wire()->modules->get('InputfieldTextarea'); $field->label = 'Textarea'; $field->attr('name', 'textarea-value'); $field->attr('value', $data['textarea-value']); $field->columnWidth = 100; $form->add($field); return $form; } }

@JanRomero: +1! if the images are the only difference, this is much better. I have a script that does something along this, maybe it is a good starting point: pwimg_(as-starting-point).zip EDIT: found that old thread, where I initially created that script. It has some htaccess rules that also can be a starting point if one want to go the htaccess route: https://processwire.com/talk/topic/4668-protect-original-images-in-siteassetsfiles/#entry46189

Another solution could be to wrap a function around the include for the remote file. This way it gets opened in its own scope and doesn't override your $config object: function readRemoteConfig($pathToFile) { $config = new stdClass(); // it is enough to use a StandardObject here, - without that, PHP will raise a 'notice' I believe. include($pathToFile); return $config; } $remoteConf1 = readRemoteConfig("path/to/remote1/site/config.php"); $remoteConf2 = readRemoteConfig("path/to/remote2/site/config.php"); $remoteConf3 = readRemoteConfig("path/to/remote3/site/config.php"); // and your (local) $config isn't affected or touched in any way

I don't understand much from DB things, but hopefully we never run into something like this with PW: drupal-pre-auth-sql-injection-vulnerability: https://www.sektioneins.de/en/advisories/advisory-012014-drupal-pre-auth-sql-injection-vulnerability.html https://www.drupal.org/SA-CORE-2014-005 https://www.drupal.org/node/2357241

Without really knowing about that, Have you tried to create a complete new user "Editor2" and change settings in a template to give him the edit-rights? And of course, I think you have done it right, but what are the exact rights this editor have? And what restrictions has the Parent-Template and what has the Child-Template? OT: For me in those situations, I go and write things down (into an Editor or on a plain sheet of paper), and sometimes in such a process I see a bit clearer afterwards. If you do not find anything push the thread once more!

Chaching and personalized pages are not the best friends. I'm not really sure where are the differences with this caching methods, but I think there is no way around some clientside action (JS! + ajax?). What comes into my mind is: does you serve the complete page from cache, like with ProCache? Or do you serve a little part with uncached output? If the latter one, you may store a JS-var that flags if a user is loggedin, and regardless if in the cached or uncached part a JS function that do a ajax call only if the user is logged in to fetch unpixelated content.

@julbr: And after that you get the error: thumbnail_4_copiar.jpg is not a recognized image. Please have a look into /home/bts003/public_html/site/assets/files/1012/ for the files: 4_copiar.jpg, thumbnail_4_copiar.jpg and 4_copiar.0x100.jpg. Can you please any of them you find pack into a zip and upload here? At least the first two should be there, maybe that the 4_copiar.0x100.jpg is missing.

looking at Timestamp.php method get: /** * Retrieve a value from the timestamp: date, location or notes * */ public function get($key) { $value = parent::get($key); // if the page's output formatting is on, then we'll return formatted values <<< !!! if($this->page && $this->page->of()) { if($key == 'date') { // format a unix timestamp to a date string $value = date(self::dateFormat, $value); } ...

I think your $timestamp->date should be not the formatted one, but needs to be an integer because it gets compared > 0 what is an numeric / integer comparision. The formatted finally goes into $date, but it needs the integer timestamp to build it from. (php.net date) I would try to get the integer (UnixTimestamp) into $t in your foreach loop. foreach ($times as $t) { ... $timestamp = new Timestamp();//this is the Class Timestamp found in Timestamp.php. Included via FieldtypeTimestamps. $timestamp->date = $t; // $t should be integer here

You should know I'm not very familiar with CSS / JS. I run into an issue when I have developed a responsive site that should show different designs for phones, tablets and desktops. Also the site uses infinite scrolling, loading image thumbs. The number of loaded images at once and the dimensions of the requested images needs to be very different regarding to the device type a visitor uses. (for phones it should load 2 thumbs at once, for tablets 12 and for desktops 36) I have used a serverside UA-Sniffer (PHP) and have set a class in the body tag to represent the found devicetype "<body class='tablet' ..", This way all the CSS for the different device types could be derived from there. After the site was nearly finished, one of the last things to implement was ProCache. This was planned from the beginning, but I haven't used it before. After installing and configuring ProCache, the first device-type entering an URL was written into the cached page-version. Uhh! It is very important to build the caching strategy at an early point. (Now I know this too) I came around my issue with the caching with changing from the serverside UA-Sniffer to a JS-UA-Sniffer and adding a JS snippet right after the body tag that adds the relevant device-type-class to the body. var md = new MobileDetect(window.navigator.userAgent); if(md.phone()) { document.body.className += (' phone'); } if(md.tablet()) { document.body.className += (' tablet'); } The code is called directly after the opening body-tag. Also the small JS-lib does not depend on jQuery, it is the only one that needs to be called in the head. All other JS files can be called after the body content. I used this PHP UA-Sniffer: https://github.com/serbanghita/Mobile-Detect and this JS-Port of the above: http://hgoebl.github.io/mobile-detect.js/

http://processwire.tv/downloads/ https://processwire.com/talk/topic/6642-processwire-logo-vector/

Since February 2013 there were some changes with PW and thirdparty modules. Now you can use PageImageManipulator for this.

Ok, now I got it. It is a bug. For now you can A) set the value for memory_limit to 512M or 1024M or 1G (but not greater than 2G!!) if this is possible for you. or B) If this is not possible for you, you can change this line to be: if($phpMaxMem <= 0) return null; // we couldn't read the MaxMemorySetting, so we do not know if there is enough or not I will file an issue at Github that fixes the setting with -1. Sorry for the inconvenience, I haven't recognized that setting to -1 in the post above:

can you enable the multilanguage description option an dfill out the default-language with the text you want use for the single-description field? Just for testing?

Good! Don't know for what it is good in this regard, but it also do not bother. Now the final question: How much memory is available for PHP?

Did you have deleted the images from the previous Errors? (Where you have no Thumbnail but the Message "Not enough memory to load/resize"?) You need to delete those in your EditPage-Screen, save the Page and upload them again. If this doesn't work, then you definitely need to bump up memory for PHP.

Can you bump up the available memory for PHP? It is explained here in detail: https://processwire.com/talk/topic/7749-max-image-dimensions-not-a-recognized-image-bug/ So as the factor setting actually in PW is 2.5, I will ask Ryan to set it to 2.2 by default. Edit: have sent a question to Ryan: https://github.com/ryancramerdesign/ProcessWire/issues/739

+1 for hookable compared against extending!

I try to sum up what I have read from your posts: You have uploaded an image named "4_copiar.jpg" into a CropImage field: Did you get errors during upload? How looks the Default-Thumbnail in Backend (the 4_copiar.0x100.jpg)? How do you go to the editor? Is there a link under a Thumb? How is the name of the Link? What is it's exact content, (the Link-URL with query)? What are the settings for 'thumbnail' in the Imagefield-InputTab under ThumbSettings?

EDIT: Attention, changed the code because have overlooked the $params variable! Tom, you can get the information from PiM with this code: // create 4 variables that need to be passed by reference and set them initially to 0; $x = $y = $w = $h = 0; // create an empty array variable named params, it is needed to pass by reference to the method $params = array(); // now call the public static methode fileThumbnailModuleCoordsRead, what additionally to the above variables needs the pageimage and the name of your thumb, (prefix) if (ImageManipulator::fileThumbnailModuleCoordsRead( $pageimage, $x, $y, $w, $h, $params, 'thumb') { // it returns true if could get permanent settings, and now you can do what you want with it ... // does this work:?? $large = $pageimage->size($w, $h, array("quality" => 25, "cropping" => "{$x},{$y}" )); } else { // to bad, no permanent settings available ... do you have a fallback? } ----- If you want to use this with PW 2.5.+, you can use a new option together with ImageSizer. It is called cropExtra and takes an array with the 4 dimensions for a crop. You can use it like this: $x = $y = $w = $h = 0; $params = array(); if (ImageManipulator::fileThumbnailModuleCoordsRead( $image, $x, $y, $w, $h, $params, 'thumb') { $large = $image->size($w, $h, array('quality' => 25, 'cropExtra' => array($x, $y, $w +1, $h))); // * } * we need the 'w +1' actually, because there is an issue with this new functionallity in ImageSizer

Welcome and thanks!