horst

what's about ? wireshell-drafts.zip

Hehe, started!

@marcus, when I have read this about status, it came to my mind that we already have those Diagnostic Tools. Do you already know them? Maybe it is possible to integrate some of the submodules into wireshell by calling status:(submodule)?

Hi Kent, yes indeed, there were some thoughts behind this. The naming scheme for images in PW core has changed somewhere between PW 2.4 and 2.5, but finally and fully functional it is implemented since 2.5.11, if I remember right. The naming scheme is: // original image name looks like basename . ext // all variation descriptions are appended to basename, introduced by a . (dot) basename . {variation description} . ext // variation descriptions start with sizes, if present basename . {WxH} . ext basename . 0x100 . ext basename . 80x80 . ext // sizes can be followed by cropsettings, if present basename . {WxH}{cropsetting} . ext basename . 80x80p30x40 . ext basename . 80x80nw . ext // resized variations also can have suffixes, introduced by a - (minus sign) basename . 80x80 - soft . ext basename . 80x80 - medium . ext basename . 80x80 - strong . ext basename . 80x80nw - soft . ext // variations also can have ONLY suffixes, without a resize part basename . - suffix . ext The goal with this was and is: the core pageimage class only should (be able to) handle the cleaning of variations, regardless if variations were created by the core imagesizer or by any third party image module. And the authors of third party image modules should not be made responsible for that. The only thing they have to do is to follow the naming scheme. There are also possibilities that image variations are passed through a chain of manipulations from different modules, e.g. Cropimage -> coresizer || pia -> pim, what results in a much more weird looking filename. But there never will be an image variation stay orphaned when an original image gets deleted. This is even valid if you have variations created by third party modules where the module is uninstalled already! So, if you have suggestions to the naming scheme, please first do a check if the above requirements can be fullfilled with them. (see: https://github.com/ryancramerdesign/ProcessWire/blob/dev/wire/core/Pageimage.php#L607)

CroppableImages and its mother "Thumbnails" are not intended for use in RTEs. But since PW version 2.5.19 Ryan has introduced cropping, rotating, cloning of images in RTEs. It isn't fully implemented yet, (or I must have missed some updates ), but is still very good working already. see: https://processwire.com/blog/posts/new-image-editing-features-2.5.19/

How it can look like with the current dev branch version PW 2.5.27: //Find all gyms sorted by location $gyms = $pages->find("parent=/gyms/, sort=location"); //Do another find on gyms to find the top three ratings and echo output directly echo $gyms->find("limit=3, sort=-rating")->each("{title}: {rating} Stars"); // output all $gyms echo $gyms->each("{title} in {location}"); Wow, very clearly laid and less writing.

a good one may also be this with track changes (see Somas post there)

Aha, but in your first post you was talking about "severe quality loss" of images, without showing an example. What have you expected as (serious) answer? (please keep in mind that I know that GIF does not have an option for quality setting. There is no chance for me to think of something in regard to quality-setting.) ------ GIF does not have any quality- setting / option by design of the image format. PNG also does not have this. PNG has an option for compression, but this does not affect the visual quality. JPEG is the only image format that has a setting for visual quality. ------ So, when ever talking about visual and also (by its nature) individually different interpreted aspects of images, it is best to show an example.

Unfortunately no. Because I do not have a glass ball

Hey @noodles, many thanks for sharing. I go ahead and change this in the repo.

The german name for that is "betriebsblind", don't know a good matching english word. Maybe blind operating, blind operation or something like that.

Yes there is no function username_validation($username). You call it in Line 102 and in 114 (?). I think it is in a dependent file that you have excluded. Can you have a look where it is and post the code of this function too please?

Hhm, exactly what was posted 2 years ago here in the same thread by soma: https://processwire.com/talk/topic/3718-lots-of-images-to-resize-timeout-in-frontend/#entry36291

Finally I have had time to download it. Its simply fantastic and a lot of fun! Regarding the windows users I share how I have set it up. Its only a bit slightly different than the very good explanation here from @marcus and @Mike_Anthony. I have done installation step 1 and 2, but not step 3. Instead of adding something to my path I simply created a single wireshell.bat file that I put somewhere into my already existing system path. I also have no PHP directory accessible through the system path, because I use minimum 5 different PHP versions (3 for CLI and 2 with the local Apache). If there were one in the system path this can lead to weird behavior of PHP, at least with the old PHP 4 that I need for older CLI tasks. My wireshell.bat looks like @ECHO OFF SET phpexe=C:\bin\php-54\php.exe SET phpparams=-c C:\bin\php-54\wireshell\ SET wireshell=%appdata%\Composer\vendor\wireshell\wireshell\wireshell TITLE WIRESHELL :: %CD% "%phpexe%" %phpparams% "%wireshell%" %* TITLE %CD% With the phpparam -c I have specified a directory where the php interpreter has to pickup its php.ini. I have one setup that is different than I need with other CLI scripts. I also could have linked to the php directory what is running under apache. But unfortunately I switch this between php 5.3.8 and 5.4.x for modules testing currently. (and composer and wireshell needs minimum 5.4.0) That with setting the title in the cli windows is nice if you have running several tasks. When hovering over the stacked icons on the taskbar, you can see which one is in "WIRESHELL mode" and which one is finished.

Updated Pia to version 0.3.0 Resolved a naming conflict with Pias crop() method: around PW version 2.5.17 there was a new pageimage::crop method introduced. If you use Pia with a recent PW dev version, please update!

The module is now fully functional again and its version number is set to 2.0.0, because it was a full rewrite. Finally it supports all sorts of crops again: cropExtra what is needed by CroppingTools north - south west | east And by x/y params and centered of course too. I updated the first post here in the thread, where yo can find the links to Github and the modules directory.

Very nice start! I saw this and before I go on with viewing the module and forget to tell you, you need to specify the version number as integer: 1 or as string "0.0.1". Using 001 will lead in complications with modules upgrades, modules manager etc.

I'm not sure with it anymore. The older or actually more common way is to implements ConfigurableModule, which has to lead into include a getModuleConfigInputfields() method. But with the newer way (external ModuleConfigfile) I'm unsure if we need to implement ConfigurableModule too? If not, the generator needs a little logic to allow only one way. And that with the default value types also is much better now! very nice Nico! static public function getDefaults() { return array( "string" => "ABC", "boolean" => true, "integer" => 1234 ); }

Since PW 2.5 it is also possible to use a MyModuleName.info.json file instead of the integrated getModuleInfo() method. With it, it is the same case as with the new module config possibilities. Both needs some logic, but worth to support it. (And now the logic can become an own function, because it will be used twice )

There is currently a dev branch available where I started a complete rewrite of the Module. This is needed because the 1.0.0 Version only handles animated GIFs with photos right, but fails with some sort of graphics: After a short and successful research (5 minutes in a support forum thread of László Zsidis GIFdecoder class) I found an enhanced class of GIFdecoder. With it, I was able to position the frames correct, but has many trouble with background colors and transparency (example). More can be read here at Github, where I asked xurei, the author of the GIFDecoder_optimized class for help. And with an upload of the corresponding GIFEncoder_optimized class, I was able to submit the manipulated frames with respect for transparency, what the old encoder couldn't handle. Sometimes you get lucky! So, a big big thanks to xurei from all future PW users that need support for animated GIFs with GD-lib. The results of the current dev branch, version 1.0.2 looks much better now: Only thing currently missing is cropping with tools like Thumbnails etc (cropExtra). This is on the ToDo.

Oh Nico, SuperMom, what a fine thing! I have tested it and love it. - Now, after you have removed the closing PHP-tag, the closing class bracket is also missing } - I would remove the option for makin a module permanent. This would be only needed in very very special cases only. - my requires for PW and PHP are not shown in the getModuleInfo() - I have selected to make it a ConfigurableModule and to get a configpage as external file, but it seems it has not all needed code in its result. I the attached zip is the generated code and a screenshot of my choices. @adrian: yes, supporting the new module config possibilities would be nice, but than there is a logic needed in regard of the PW versions a module supports.

No, this is not as good as it could be. The format of the folder should be in a descriptive name where the first part should be a category where sufficient: Markup or Inputfield or Process etc. folllowed by the rest of the name. The complete name has to be InCamelCase, only containing a-z A-Z, maybe 0-9 is allowed too, but I'm not sure about it. Your modules root folder should have this name and in it there has to be at least one module file, the main file if you like to call it that way. Its name is the same like the folder (InCamelCase) with the file extension .module - The module file must have a class definition with also exact that name. All other you can handle as you like, with subfolders or not, etc.

Nice to hear that it works perfect for you, but, ähm, a) I haven't built it just for your current case, b) we need to have support for cropping, definetly, c) but I have pushed the intermediate work to that dev branch to support you with your current case!

UPDATE: Now the dev branch also supports centered crop! Only thing missing is cropping with tools like Thumbnails etc (cropExtra) and other API crop calls then centered are currently not tested.

// maybe a link to the PDF is enough echo "<a href='{$page->showPdf->url}' target='_blank'> download a nice PDF here </a>";