horst

The reason it wasn't detected was, that no module was in the root directory of the module, but all each of the three modules resides in its own subdirectory.

@Robin S it was due to an needed upgrade from Pim1 to Pim2 because of changes in the naming conventions for images in PW > 2.6.?. At this time Pim1 already was installed and used in many sites. When people upgraded their PW version in those sites, they could not / cannot simply change Pim1 with Pim2. There was a manually action in changing API calls in template files needed. This was / is the reason for this weird behave. For the simply case of first install of the module, I can use a PW version detection of course, but that wasn't the problem. The problem was / is, that in prior PW versions with use of Pim1: i must used the Pim1 as first / only module, to get the people informed about update changes via upgrade-module(s) must ommit an automated change from old naming convention to the new one, because sites possibly would break down if I would raise a need to recreate every image (!) So, yes, I was and I'am very unhappy with this situation. If someone has a better solution, please tell me. ------- BTW, with the CroppableImage3 I run into something similar: Croppable3 isn't recognized by the widely used upgrade-module from Ryan, so people don't get informed about updates of it. I believe, many sites are running a version prior to 0.9.17. Everytime someone updates an older PW version site to a newer version, they run into a bug that was already fixed a year ago in version 0.9.17. People than always report that they just upgraded from x to PW > 3.0.31* (or similar), and the module now wouldn't work anymore. But it is already fixed. They all need to do a manual update, but how can I inform them? The updater should do so, but doesn't do.

Have you disabled or refreshed browser caching? Have you checked the files in local and or FTP directory? or do you only noticed this "not changing" in the website by using the browser?

I used it at least here: https://nogajski.de http://joerg-hempel.com http://bella-italia-aachen.de/

@jploch: a question from me to clarify: You have installed ImageAnimatedGif module and it produces correct resized and animated variations with calls to pageimage methods (widt, height, size), but it doesn't produce the same result when you use it with MarkupSrcSet? The ImageAnimatedGif hooks into before pageimage resize, and MarkupSrcSet simply calls pageimage size, so I'm wondering what could be the difference here? What is the result of MarkupSrcSet? Images are scaled down and animated, but with artefacts? Can you provide an example? (a variation from direct call to pageimage and one result from MarkupSrcSet)

It seems to be wrong as you call wire() in the global namespace, but you must call it in ProcessWire namespace. What you do is calling \wire(), but it must be ProcessWire\wire(), what would be really weird to add it with every call to a PW function (in a PW programm). Best way would be to add the namespace on top of each *.php file in your template system, (template file, view files, snippet files, ...): <?php namespace ProcessWire; Than it should be valid and functional.

@rick: In your code that handles the form input, you simply can call the module or public module method: //if(<condition for form was posted>) { $myModule = $modules->get("MyModulesName"); // get a module handle $myModule->passNewDataIn($input->post->someData); // call the public method for data input // rest is done in modules method, ... // if you are not in template scope, you can use $myModule = wire("modules")->get("MyModulesName"); //}

I have found my better checkerbox background image again: in use as BG it looks like this:

To show our *.module files with the correct PHP syntax highlighter is now possible on Github. With new repos, you first need to add a .gitattributes file to it. After that you can view *.module files with the PHP syntax highlighter applied: MetadataExif.module So, this doesn't work with already created / comitted repos by simply adding the .gitattributes file. But it will find its way through different caching layers on github if you add it to your repos and further committs to them. (https://github.com/github/linguist/issues/1792#issuecomment-286379822)

Hi, here is a very useful tool that check your images in websites against responsiveness: https://github.com/ausi/respimagelint

@rayorg: currently only the method ->watermarkText() has a param opacity (0-100%). For overlaying images, there isn't a configurable option currently.

@Mackski: please refer to the RFCs for email! https://tools.ietf.org/html/rfc2822#section-2.2

Tinifying images is ONLY useful on the final variations. Tinifying an original source image is completly WRONG. This tinifying is often misunderstood. You can resize an image on upload to variuos varirations and also tinify them, if you exactly know which variations you will need around in your site. Here is an example how to hook into upload and process something with the image:

@ank I updated my above post with an example. ;-)

In the modules config screen you can set it under "sender_reply". Also a "sender_errors_to" is available. If you need to set it dynamically, you must go the workaround with modifying module config-settings via API. If so, you will find examples here in this thread or the forums in general. you can use this: $data = wire('modules')->getModuleConfigData("WireMailSmtp"); // or, regarding on scope, $data = $modules->getModuleConfigData("WireMailSmtp"); than modify the reply adress: $data["sender_reply"] = "you@example.com"; after modifying, you can write it back: wire('modules')->saveModuleConfigData("WireMailSmtp", $data); // or $modules->saveModuleConfigData("WireMailSmtp", $data);

High Performance Browser Networking © Ilya Grigorik the complete book is online now for free reading: https://hpbn.co/

@tpr there seems to be an option to collect those too:

@szabesz but the files are there. You have to look at uikit/src/scss/variables.scss or less instead of scss.

maybe you can find some posts here in the forums already. I remeber very vague that this has been discussed already. google search or

you are running PHP 7? or what PHP version?

Ok, no, that wasn't exactly what I suggested. But if this works too, it is a good alternative.

You need to manually install pim2 under site/modules/, and UN-install pim. Than you can use pim2load. You can read about it in the very first post of this thread: https://processwire.com/talk/topic/4264-page-image-manipulator-1/ right at the top of that post.

You definetly have to check the user rights. If you prviously used apache module, and afterwards changed to cgi mode, I bet that this are different users on the server. Common usage on shared hosts is, that php as apache module is a user something like wwwrun. As cgi version, mostly it is identical with your own ftp user. So, after you switched to cgi, all messages that say you don't have the access rights to the assets directory totally make sence!

you need to use ->filename instead of ->url $pdf = $homepage->pdf_marketing->filename;

..., and you should enable the IMagick Imagesizer Engine if your server supports it! (under PW 3) ..., and additionally to the quality-value, you can try out differend sharpening values (none, soft, medium, strong)