horst

Happy Birthday Ryan, this is the only year where you are exactly 10 times that old than ProcessWire. So, one of the big future milestones will be when you are "really official" old. It's when PW reaches your actual age. (this will be in 2050 when PW has age 40 and you are one year older then 75)

@Joss: you should not use the PHP 5.5.9 - it has a buggy GD-lib, (if has a installed one ) You should use one greater than 5.5.11! You should run processdiagnostics when starting with new server setups. This one would have told you everything at once.

He uses a CropImagefield, and the Error is explainend exactly! in the link I have posted in my first answer. And it is not another error, it is exactly the same, because there is only one place in PW pageimage / imagesizer where this is done, (writing Errormessages into a image-variation.). So please, @julbr, read the explanation in the thread I have linked too. There is also described that you can open the image-variation and or the original image in a simple Texteditor to see what the error was when trying to resize / upload the image. Can you tell me what there is to read. Also the filesize is only a few Bytes.

@adrian: I have found a workaround for me. I set it up like this: parent installs: child1, child2 parent requires: child1 requires: parent child1 installs: child2 requires: parent child2 installs: I would not need this with my workaround but found it to be usefull to display all those infos about requires and installs in the modules admin. In the Parent uninstall method I use this code: public function ___uninstall() { $GLOBALS['UNINSTALLROUTINE_RUNNING_PARENTNAME'] = array(); foreach(array('ModuleNameChild1', 'ModuleNameChild2') as $mod) { $this->modules->resetCache(); if (!$this->modules->isInstalled($mod)) continue; $GLOBALS['UNINSTALLROUTINE_RUNNING_PARENTNAME'][] = $mod; $m = $this->modules->get($mod); $m->uninstall(); } parent::___uninstall(); } and in the Children uninstall methods: public function ___uninstall() { if (!isset($GLOBALS['UNINSTALLROUTINE_RUNNING_PARENTNAME']) || !in_array(__CLASS__, $GLOBALS['UNINSTALLROUTINE_RUNNING_PARENTNAME'])) { throw new WireException("Please only use the ParentModulesName to uninstall the complete ModulesPackage!"); } parent::___uninstall(); ... This way you can use the ParentModule to uninstall all, but you cannot uninstall one of the Children. A bit weird is, that the children modules get uninstalled two times, , this is because of the auto-install / auto-uninstall routine of PW modules dependencies. But if one would not specify dependencies, this could be avoided, but also the dependency messages will not be displayed then.

I saw I little typo in the config description: "Supply a custom port separated by a column" ... should be colon I believe.

I don't understand what caching issues you mean. Do you use ProCache or other Caching methods?

Thanks Adrian! Now I know what was going on. I have had this code, what was working before: $p = $this->pages->get(3)->children()->get('name=image-crop'); and then I have broken it at the children() part, because in the install-routine when the adminPage gets created, I have set the page to hidden. So a simple 'include=all' or 'include=hidden' as selector for the children() will make it work again. Hhm, I love it when I get to know why / how things do work the way they do. PS: yes it seems there is much similarity between our works at the moment.

I have done a fresh install of PW 2.5.3 Classic-Profile, copied and installed 3 modules (that belong together) into the site/modules directory and installed them. I haven't done anything other, only refresh the modules cache by hitting a few times the refresh button in the modules section. After that I have deinstalled those modules and hitted the refresh a few times. Now after that, when I want to install them again, I get that error for the third of it: The module want to install a process admin page called 'image-crop' but without the '-3' suffix. ?? I have dumped the DB after the install and the uninstall of the modules, the only difference showing are here: with modules, in table modules: (155, 'ProcessRecentPages', 1, '', '2014-10-06 15:39:35'), (165, 'FieldtypeCropImage', 0, '', '2014-10-06 16:18:15'), (166, 'InputfieldCropImage', 0, '', '2014-10-06 16:18:15'), (167, 'ProcessCropImage', 1, '', '2014-10-06 16:18:15'); /*!40000 ALTER TABLE `modules` ENABLE KEYS */; without modules, in table modules (155, 'ProcessRecentPages', 1, '', '2014-10-06 15:39:35'); /*!40000 ALTER TABLE `modules` ENABLE KEYS */; Also the table 'caches' is different. But everything looks ok. Also I cannot find the string 'image-crop-3' in the dump(s). I can provide the dumps or informations of the modules if necessary or do further investigation, but actually I have no clue how and what I should do with it.

https://processwire.com/talk/topic/7749-max-image-dimensions-not-a-recognized-image-bug/

Maybe you can post them on GitHub? There are actually no open issues.

I have already tested this with the Fieldtype set as the parent. Fieldtype installs child1, child2 child1 requires Fieldtype child2 requires Fieldtype With this setup I simply can click into one of the children and uninstall it! This way I can uninstall the ProcessModule but let the Fieldtype and Inputfield there, but not operable. This should not be doable in our case. ----- I don't want to throw an exception, I would like to test if some criteria are matched when a user try to uninstall any of the modules, and if the criteria are not matched, guide him on how to go further. Or is that the (only) way how I can 'guide' him, throwing a short warning message, may be with pointing him to other resources?

@Ivan: I appreciate your contributions / tipps. But, - 1) the script was hacked together last night in under 30 minutes including testing. It comes from that source (a proof of concept) 2) there is a very big black hole whith this: The script iterates over imagefields and than over single images, calling getVariations() bzw. removeVariations(). That's all. This leads into that all images used by RTE-Fields on the same page could not be identified as those. So the script simply deletes them too There may be a possibilty to detect some of the embedded images in RTE-fields, those using an HTML <img tag, but there are a lot of known and unknown possibilties how images can be embedded into RTEs. Think of HannaCodes, Markdown, BBCode, other Tools/Modules that store (generic) code into RTE's to later on runtime build a proper URL or img tag from it. All those get dropped and cannot recreated automatically, like those from imagefields. Also CropImage-fields will lost there individual CropAreas and fall back to automaticlly created ones. Therefore this is a very pour solution, only offered to some people here who do know about that risc and who are able to handle that right (during development only). (hopefully) As long as there is no solution that can cover the above noted cases, I do not release it elsewhere. Finally I'm glad that it can be of help in a small use case.

I have updated the Github repo and the entry in the modules directory to version 0.1.9 @JasonS: sorry that I tend not to believe that a server says success on testconnection and then returns a "No unauthenticated relaying permitted" error. Together with the confusion that the hoster has said it needs no credentials, it sounded too unlikely for me. But it was real. I have liked all posts of you here in the thread trying to say appologize. (If you post one more I will like it too)

Wow! I have found out that in the Connect() method of the base SMTP class it comes to a point after trying to start a TLS connection that a variable $success is set to true if the smtp-server simply supports TLS. After that a if condition checks if there are settings available for user, if not it passes through to the end of the method with $success set to true! A Bummer! If there is given a username, it trys to authenticate that user and the variable $success is set to that result. So, at least this is not a bug, because in the past or in private networks SMTP servers could be configured to work without authentication, that is what this class does. What should I do with this situation? I tend to ignore a usage without user authentication. This way it tries everytime to establish a connection via authentication, what will fail with an empty user or pass. Good to know that typos would be detected in the past but only empty usernames raised this behave. Now the class gives two errors: WireMailSmtpConfig: ERROR: SMTP settings did not work. WireMailSmtpConfig: 535 5.7.8 Error: authentication failed

Sure? This would make the testconnection nearly useless. The only reason for it is to test if one has no typos in the server settings and credentials. I will try this gmail and with other servers and report back.

Ok Adrian that may be right, but I think you have entered your credentials for the SMTP account(?). In this special case JasonS hasn't entered any credentials and got everytime a "No unauthenticated relaying permitted" in the error-log. Also he said that the test-connection works everytime! Hhm? Finally he has found that he need credentials for using the SMTP server, (not a big surprise at all, isn't it?). The times when you could use a mail relay without authentication are gone for a decade or two! We have 2014.

The connection-test uses your credentials and try to establish a connection to the server you has entered in the configscreen together with your credentials. If the connection-test always succeed, there is no reason why the connection when trying to send a mail shouldn't do so too. (Because it is 100% the same code used in both cases, and the same credentials, empty or not.) The error you are getting tells another story: "No unauthenticated relaying permitted" - Do you have a personal SMTP account at ipage? - Have you asked them if you need credentials for sending through your personal SMTP-Account and they have answered to you that you do not need those? - Or do you have asked them if you need credentials for sending emails via php, and they think you mean simply using the php mail() function through your webhost? The wiremailSmtp module cannot use php's native mail() function. This can be used with the base class wiremail and without credentials.

I have made a module for you (all). I have had allready a routine that iterates through all pages and clears all imagevariations. But this only can be safely used if you have not used images in RTE's from the same page. If you have done so, those cannot be identified and gets deleted too. So please double check that you do not use Pageimages in your RTE fields before running this module. To run it you have to install it, go to its configscreen and check the box to run it. Also there is a second box, always checked by default, that let the script run in testmode. In testmode it doesn't delete the variations but list all found pages and the images count. So, if you really want to delte all ImageVariations sitewide, tipp the box to run the script, untipp the box to run it in testmode and press the submit button. PageimageRemoveVariations.zip EDIT: better use this enhanced module version from @tpr, with configuration for excluding imagefields: enhanced version!

At the moment you only can add a boolean param to every pimLoad('prefix', $forcenew) call. This way you can set it at one centralized (template prepend file?) place to true or false. You can leave this in your templates, also once when deployed to production site, but then set to false, of course. Don't know if it is a good idea to bind it to $config->debug? $forcenew = (bool)$config->debug;

@Joss: I have started with my portfolio site too. (for the third time now ) I use "rem" the first time. I have set html to 62.5% and body to 1.6rem. This should be equiv to 16px, not to 14px what you have noted in your css. Also I have read that one should / can use a fallback for browsers that do not support rem: first specify it in px and after that in rem: html { font-size: 62.5%; } body { font-size: 16px; font-size: 1.6rem; line-height: 20px; line-height: 2.0rem; } h1 { font-size: 32px; font-size: 3.2rem; line-height: 40px; line-height: 4.0rem; } So I'm not an expert in this, also browser support should be widely these days. I have read a good article about rem here: http://snook.ca/archives/html_and_css/font-size-with-rem This together with box-sizing-border-box (what has got an update in August 2014!) and a small css (pocket)grid, it should be fun to build it from scratch. I'm looking forward what you will build. The last site I have seen is really good.

Do you know: https://processwire.com/talk/topic/4420-migrator/ ? EDIT: completly OT, but does you have seen the inofficial trailer already?

I have another question regarding this: If I have 3 modules belonging together: FieldtypeExample (has "requires: ProcessExample") InputfieldExample (has "requires: ProcessExample") ProcessExample (should be the parent, has "installs: FieldtypeExample, InputfieldExample") If I copy all together into a site/modules directory, I only get a install-button for ProcessExample, what is fine and as expected. If I install it, it auto-installs the other two modules, what is fine, too. If I build a field upon the FieldtypeExample, I cannot uninstall the FieldtypeExample-Module unless I have removed all Fields of that type from all Templates and have deleted all Fields of that type, (in this order). But if I use the ParentModule (ProcessExample) to uninstall all 3 modules, it doesn't handle this. It just uninstalls the InputfieldExample-Module and itself. It lets the FieldtypeExample-Module installed. Can I prevent it from uninstalling itself somehow from within its ___uninstall() routine? Another thing is that I simply can uninstall one of the children, leaving the other both modules installed. Also not what should be able for my usecase.

@soma: are your questions answered somewhere else? I'm interested in reading it.

Maybe this is usefull link: https://wiki.apache.org/httpd/RewriteHTTPToHTTPS

Hi Stefan, image presentation on the web is a compromise between less loading and good image quality. If you can avoid to show the original image at the front end I would recommend to use those "only as resources" for the derivatives that are shown to the public. This way you should use the best quality for the original images, 100% quality, saved as default. Optimized Jpegimages have artefacts, more or less, depending on the quality setting. If you use an image that has already artefacts (q90 optimized for web) you will become artefacts of the artefacts, but at least more artefacts as from a resource image with q100 saved default. Which finally quality setting is usefull for your images you only simply can try out. I believe that you can use between 80 and 90 with good quality.