horst

I use the central .htaccess file with php_value settings for controlling error reporting and some others. php.ini settings affects all virtual hosts on my dev machine.

@PhotoWebMax: I do not see any "jiggles" viewing with FF / IE / Chrome on Win. Does it looks good / interesting? Then I want to have it too. @Sanyaissues: Really well done site! And also really well done pictures (from the photographers working for superpola). I think you have fun working with / for these people.

ah, have to re-read before answer! Please, what code do you use in image() ?? Heureka! Ok, now I have it! $membre->professionnel_photo is a collection (Pageimages), but it should be a single Pageimage!

Perfect Ryan! Exactly what I have done: using/adding a constructor without inheriting the parent constructor. Shame on me, ! It hasn't had a constructor before. I have written a lot of code, without calling the page / Module, maybe for 1,5 hours. Then I went to test it. First error was that needed dependencies are not included. I do it quickly by adding a constructor which includes the two libs. Going on with my Test, only focused on my new written functionality, it goes past the first submit when adding a new field. But I only had in mind my newly written code, completly forgott the added constructor! And then I haven't understood why my code has so drastically broken things. Stupid me Now everything is working again, thanks!

This with the photos on user pages was discussed here before. But I do not remember a solution, only that people have created extra pages and bound them to the userpages, like Kongondo has said above. https://processwire.com/talk/topic/5644-images-in-user-profile/ not necessary to read the whole thread, just scroll down to where ryan has posted and read the few posts around that. You also may reopen the related issue at GitHub: https://github.com/ryancramerdesign/ProcessWire/issues/444

I have tracked it down to this: The last executed Lines in FieldtypeFile.module are: public function getInputfield(Page $page, Field $field) { $inputfield = null; if($field->inputfieldClass) $inputfield = $this->modules->get($field->inputfieldClass); if(!$inputfield) $inputfield = $this->modules->get($this->defaultInputfieldClass); $inputfield->class = $this->className(); When this is called, $this holds an empty defaultInputfieldClass. Therefore $inputfield becomes null, what is returned from modules->get($this->defaultInputfieldClass) in line 58. (sure, it cannot get a module "") And thus it crashes! When the FieltypeFile is initialised, it has this line in construct(): public function __construct() { $this->defaultInputfieldClass = str_replace('Fieldtype', 'Inputfield', $this->className); } but in my case, at this time $this holds an empty className AND an empty defaultInputfieldClass. (it must have to do with load priority or if a module is autoload or not, I think) Later, when coming to getInputfield() at lines 56-58, className is populated with the right name! Now once more calling the line from constructor, it goes a bit further: if(!$inputfield) { if(!$this->defaultInputfieldClass) $this->defaultInputfieldClass = str_replace('Fieldtype', 'Inputfield', $this->className); $inputfield = $this->modules->get($this->defaultInputfieldClass); } $inputfield->class = $this->className(); It loads the Field-Editpage, but lacks a InputfieldType: Session: Missing required value (inputfieldClass) I think, somewhere between running the constructor and coming to getInputfield, there must be a same situation like above, where it fails to populate a variable, I think. Does someone know if Fieldtype- and / or Inputfield- modules can / should be set to autoload? Autoload doesn't help here.

@reems: in this case, you and your client have done it completely thewrong way around Your client has uploaded already compressed JPEGs (maybe with a quality of 80%) and you have rendered them uncompressed with quality 100. Your client should upload images with max quality and those originals never should passed as frontend output. They only should serve as source for variations! This way round you get nicer looking images, and if you need more compression than the GD-lib can serve, use Philipps service. . If you need, for what ever reason the exact original sized image output on frontend, you can call it like: $image = $page->images->first(); echo "<img src='{$image->width($image->width)->url}' />";

@interrobang: If I get this right, with Pageimage / Imagesizer you can use the lately (2.4.? but before 2.5.0) introduced images option "forceNew" to tell Pageimage::size to always create this desired variation new: $image->size($width, $height, array('forceNew'=>true)) No need to call $image->removeVariations(); anymore! If you are speaking about something different here, - sorry, I'm a bit in a hurry and haven't read carefully or twice. --- IMO, the suffix should be added internally by your module as with your example above. And what is if the user want to set an individual suffix? Well, this could be added to the default suffix from your module by simply concatenate together with a "-": // somewhere in your module, after you have selected one out of "inside, outside, align, center": $suffix .= isset($options["suffix"]) ? '-' . $options["suffix"] : ''; // $options is the options

Ahrrrgh! I get this same error now for the second time. I'm using PW 2.5.6 dev and I get this while working on a Fork of CropImage. I couldn't find why this is always raising now and makes it unpossible to enter the edit-page of the field or any edit page where that field is used. Yesterday it raises the first time and I only could get rid of it by completly drop the DB and start from scratch. Today I have used a DB-Backup where the module isn't installed and no fields of this fieldtype exists. So I can set it back workable quickly. I will try to investigate further on this, but want to note this here because of the similarity with what Lars has described, (same error and CropImage!) ----- EDIT: Just some notes for later, if I don't get it solved by myself: it is reproducable for me now by starting with a fresh DB, installing my module and when creating a new field after pressing submit: I get the exact above error in DB a table is created: pages_id (INT 10), data (VARCHAR 255), sort (INT 10), description (TEXT), modified (DATETIME), created (DATETIME) table fields holds a new entry which is complete

There is one possible workaround: if your images with wrong orientations couldn't be corrected before uploading, and all of them have greater dimensions as you maximal need for your site output, you can define the max-image-dimensions under Setup -> Fields -> (name of your images field) -> TAB:input - [Max Image Dimensions]. All (original)-images that have greater width or height then defined there gets resized with autorotation and saved as original image on upload. (Personally I don't like this behave because in some cases it could do damage to the original images like I have described in the linked post above.)

What does you mean with "the Select Image Modal"? Do you mean the fullsize image, the original image in the Backend? We do not overwrite the original images, this is answered and linked to a few times, also directly in the post above yours: => https://processwire.com/talk/topic/6848-recognising-image-orientation-on-upload/ If you have images that have a wrong rotation setting and you upload those images, the original image stays untouched (with wrong orientation setting), but all derived variations are auto-rotated to the correct orientation.

@interrobang: I have installed and tested it and I only can say: wow, really lightweight and straight forward!

As a sidenote, regarding the detection of imagefields if (! (bool) ($field->type instanceof FieldtypeImage)) continue; // the only way I know to find all image fields, also those coming in the future, is to check for the instance of FieldtypeImage, what also is true if a field extends FieldtypeImage . As of today (date of this post) we allready have those known image fieldtypes that extend the core images fieldtype: Cropimage -> (also known as Thumbnails) ImageFocusArea -> (formerly known as ImageFocusrect) ImageExtra -> ImageExtraLanguage -> CroppableImage (a fork of Cropimage, coming soon) Images section is growing!

Hi Philipp, at first, to get the original name from a variations name, you simply have to drop all after the first dot in the basename: (this works with all PW versions, 2.2, 2.3, 2.4 and also with the changed NamingScheme in PW 2.5.+) $imageName = pathinfo($variationName, PATHINFO_BASENAME); // I do not use PATHINFO_FILENAME here because this way it also matches original filenames $imageName = substr($imageName, 0, strpos($imageName, '.')) . '.' . pathinfo($variationName, PATHINFO_EXTENSION); // determines where the first dot is and drops all after that position, and simply add the extension // the only way to find all image fields, also those coming in the future, is to check for the instance of FieldtypeImage, what also is true if a field extends FieldtypeImage: foreach($page->fields as $field) { if (! (bool) ($field->type instanceof FieldtypeImage)) continue; // if no images field, go on //if (count($page->get($field->name)) == 0) continue; // this isn't needed I think because the next check with ->has() covers that case too // find the field that holds the image if (!$page->get($field->name)->has('name=' . $imageName)) continue; // if you reach this line, you have your field and your original image If you are in template scope, you may test to switch of outputformatting when asking with ->has(), or it could raise an error if the imagefield only allows a single image and doesn't return a wireArray. (I'm not sure on this, - just want to note not to forgett to test on this)

+1 for ImageFocusArea

And besides all what @Totoff has said: regarding the german tax (Steuer, Finanzamt), it very differently handles those things. If you are 'only' working as a designer, you maybe able to write 'only' bills with MwSt 7%, but if you also do other things, like selling webspace etc. this is another business what need to take MwSt 19%. And really, you will end up with double and triple work on this (tax, finanzamt) site if you go into this hell. (And of course you need to work with a good 'steuerberater', and he will bill you the 'double', maybe.) I never have heared about something functional in regards of "making money without doing stuff". (at least not for people without some million euros/dollars, - also not for people with some million euros/dollars and with morality)

@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!