horst

You can post an issue on github, as Ryan may not see this here in the post. But he will see it on Github!

I don't get any letters, but I had deleted my FF-Sync Account because I got doomed by their expired Cert for AddOns. First it deleted my local AddOns and then "uploaded" it to my Sync-Account, what in fact deleted all AddOns there too. For me it was the drop that broke the camel's back. I switched to Opera and there are now only two points of 20+ left which I haven't solved to my satisfaction in Opera yet. In some regards Opera even is a better tool then FF. I really liked it after two weeks using. It seems that this has caused, among other things, a great loss of trust or resentment, which may have led to reduced user numbers. I still use the FF to test websites in the FF, but for nothing else.

This is not an easy question, and so also isn't the answer. Personally I would prefer Git submodules as it would be less effort for users who doesn't have either Git nor Composer understanding. Also Git is very tiny action to install and running, composer seems to take more effort. So, for users who have both capabilities, I also would go with option 3, the composer dependencies. My conclusion is, it depends on your main target group.

@Robin S Many thanks for this. I will try it soon!

@huseyin Welcome to ProcessWire and many thanks for sharing this project with us. Its impressive and well done. Paylaştığın için teşekkür ederim

Why do you not include type hidden fields into your forms where you add identifiers? $validFormIdentifier = ['aaaaaaaa', 'bbbbbbb', 'ccccccc']; $myIdentifiedForm = $sanitizer->text($input->post->hiddenidentifier); if(!in_array($myIdentifiedForm, $validFormIdentifier)) { // invalid formsubmission, do not process further }

@psy You can set webpQuality to lower values what will result in smaller filesizes. Examples:

@teppo === "Mr Eagle Eye"

The only thing what may occure in very rare cases is, that another module in the same PW installation also uses the TwitterOAuth lib, stored in a different place. To avoid conflicts, one can add a conditional check before including it, using the PHP function class_exists(). <?PHP namespace ProcessWire; if(!class_exists("Abraham\TwitterOAuth\TwitterOAuth") { /* load the TwitterOAuth library from my Module folder */ require_once("./twitteroauth/autoload.php"); } use Abraham\TwitterOAuth\TwitterOAuth; Also one may prefer require_once() over require(), if there is a chance that the class / class file is loaded twice.

Hi all users of the croppable image 3 fieldtype. I'm currently working on the module, or better I'm reworking the module to support webp copys like the core image field does. Unfortunately this will break backwards compatibility! My questions are, how should we handle this? Until now the crop variation has this sort of names: basename.ext becomes basename.-suffix.ext But with the new version, it looks like regular image variation files with a -suffix: basename.ext becomes basename.100x200-suffix.ext My current thoughts are along that lines: I create a new named module: CroppableImage4, that supports the same API as the CAI3 version plus an alternative method like getCrop4("suffix"), and I add some checking, when the CAI3 is installed / active, it only hooks the plus method, not the regular one. What do you think? Any suggestions, ideas, wishes? And how can we savely update from CAI3 to CAI4, for example with existing websites containing tons of images PS: Besides that, the new module now supports individual $options as array or selector strings. It generates 0x48 thumbs and webp copies by auto generation and by manually creating a crop. It removes all variations on every changes: changing a single image, changing or removing settings. It has input fields in modules config for webpAdd and webpQuality, so you can handle it different from the $config->imageSizerSettings, and you now can add individual options with every API call, like with the core image field: $pageimage->getCrop("suffix", $options)->url, or $pageimage->getCrop("suffix", $options)->webp->url. And some more minor tweaks.

Hohoho, a 3000 x 3000 PNG, for what do you need this? You generate a 1000 x 1000 variation? If you use photoshop jpeg quality 12 you also has lossless master images. My favor would be to have LZW-Tiffs as master, = Lossless compression and a format that cannot wrongly used for web output.

Yep, and I / we don't like version hunting for all the format issues in Imagick or GD.

Besides the broken Imagesupport for PNG8 I want to say: "Uploading ImageOptim optimized images are ONLY for output use as is(!), NOT for serving as master image from what one should generate new variations. " Everytime when I read something like this, my photographer heart hurts and somewhere a kitten dies, I believe.

Ah, @ryan has added support for PNG8 to the Imagick engine, what wasn't before. He also asked me why this wasn't added and I was unsure if I simply forgot to add it. But now when I see this, I think I had tested it and removed it from the Imagick supported filetypes / subtypes, so that this images always were rendered by GD! until before the last Update. https://github.com/processwire/processwire/pull/141#issuecomment-495983196 So it seems it should be rolled back again, at least for PNG8. EDIT: I couldn't remember as it is (how many?) years ago as the Image Engine System was introduced. And yep, it would have been better to add some comments. ;-)

You should try harder!