Leaderboard

ImageSizerEngine ImageMagick CLI Version 0.1.1 beta (requires PW 3.0.10+) Get it from the modules directory or from github. For information what it is and how to use and install, please read this Blogpost.

New public method: TD::templateVars() templateVars() tv() Basically what this does is strip any system PW variables and returns just those that you have defined in your template file. It replicates what is output on the "Variables" panel, but lets you dump, barDump, fireLog, or log at whatever points you want throughout the execution of your template file script. Obviously if you are only interested in the changes to one variable there is no point in using this, but if you want to see how they all change, this is a nice shortcut. It is really only designed to work with PHP's get_defined_vars() Here's an example output via barDump: bd() $i=0; $x=10; bd(tv(get_defined_vars()), 'breakpoint one'); $i++; $x--; bd(tv(get_defined_vars()), 'breakpoint two'); This results in: Without tv() in there it would include all PW variables/objects and it would be difficult to see the variables you are interested in. Note that the templateVars() and tv() shortcuts/aliases may need to be turned on in the config settings if you are upgrading.

ImageSizerEngine NETPBM CLI Version 0.1.0 beta (requires PW 3.0.10+) Get it from the modules directory or from github. https://github.com/horst-n/ImageSizerEngineNetpbmCLI For information what it is and how to use and install, please read this Blogpost. Currently supported by Version 0.1.0: only JPEG, - no PNG, - no GIF GIF and PNG will fallback and handled by GD currently. This will be changed when I have a bit more time.

Ah, sorry, don't got this fully. With the everywhere available GD lib it is not possible to do any sort of colorspace detection / prevention / conversion. With ImageMagick, as CLI or PHP-Extension, it is only possible with compiled-in lcms to proceed colorspace operations. And only then, it would make sense to keep an ICC profile. To clarify my understanding of a colorspace workflow: detect the colorspace (ICC profile) of the incoming image transform it into a workflow colorspace (e.g. AdobeRGB or ECI-RGB) do all manipulations transform it into sRGB colorspace just before output optionally embedd sRGB profile I never would use the incoming profile as the output-profile, I ever would transform into sRGB. (Browsers and CMS's are not Photoshop, ;-)) Embedding an output profile into an imagevariation requires lcms. Processing it in the above workflow will increase the processing time up to 4 times for every variation. We have tested a lot on this two years ago.

The first thing is, if you do not have the PHP-IMagick Extension available on a server, but are able to use the PHP exec() function for CLI operations. Than this and the NETPBM module are useful. A quick and short comparision of the current state of all currently available modules is: The core implemented PHP-Extension Imagick module lacks of support / detection of PNG 8bit transparency files and correct GIF support. Therefor it only processes JPEG and PNG24 images. GIF and PNG8 images are handed over to the GD engine. If the ImageMagick-CLI can handle PNG8 bit images with transparency is not inspected before image processing. It may or may not, but with a recent, and fully functional ImageMagick installation it should be able to process all sort of image formats and subformats. The NETPBM-CLI is currently work in progress. With Version 0.1.0, It supports JPEG only. But the other formats will be added as soon as I get time for it. There are no known downsides, I just need time to test and implement this. The difference in quality is minimal between those three modules. They are all better than the GD lib. To choose one before the other ATM only depends on what is supported on a webserver, or may be on personal preferences. When the modules are finished, so that they support all kind of formats and subformats, I will publsh a comparision table of the most useful aspects. Until then, it will be helpful if people can test one or more of them and report back how it goes.

If anyone interested, I installed Imagick on Win8.1 x64, IIS 8.5, PHP 7.0 x86. I took ImageMagick-6.9.3-6-Q16-x86-dll.exe from http://www.imagemagick.org/script/binary-releases.php#windows (I think the latest version would be ok too). Installed as usual, then I created env variable MAGICK_HOME, pointing to the C:\Program Files (x86)\ImageMagick-6.9.3-Q16\modules\coders. Checked that application is running. Then I downloaded PHP 7.0 Non Thread Safe (NTS) x86 of Imagick from http://pecl.php.net/package/imagick/3.4.0/windows, copied php_imagick.dll to the PHP's extension dir, in my case C:\Program Files (x86)\PHP\v7.0\ext, and added extension=php_imagick.dll to php.ini. Finally I had to restart the computer!

For those interested, I've released a new prerelease and dropped the PHP 5.5.0 requirement. I've also added a few features and will be creating a forum thread soon.

@Jugibur: that's all right what you are saying. - But, ... the -strip param is only available in the CLI version of ImageMagick, not with the PHP extension. But the PHP extension can handle embedded image markers as well, if, and only if: needed dependencies are compiled in. For ICC conversion, the lcms lib needs to be compiled in, what seems not by default or not with all extensions. Other cons are: with the PHP extension of Imagick, you cannot determine if it is supported / compiled in or not! And if it is supported, it will expand the processing time up to 3-4 times, compared to the processing time without ICC conversion. Therefore, and to have a homogenuous behave across all engines, we strip all image markers by default, but excluding IPTC. (stripped ones are: ICC, EXIF, XMP, JPEG-Comments, and others) Here are two more modules for the new ImageSizerEngine System: ImageMagick CLI Netpbm CLI

Small update that enhances links from the PW Info panel Summary section - now you can have shortcuts to either view (page name) or edit (page id) each of the linked pages that are related to the current page. The children item now has: an "open tree" link (opens this page in the page tree expanded to show all children) an "edit" link (opens this page to the Children tab, which is particularly useful if you have Batch Child Editor installed). The template filename in the Template Info section uses the defined editor protocol handler to open the file directly in your code editor. Hopefully you'll all find these nice little time/click savers And page edit and template file edit buttons are also in the footer of this panel for instant access:

@jugibur: just to clarify: PW doesn't alter the original image per default. There is only one situation where the original image will be altered: If you have settings for max-image-width or height set with an imagefield and an uploaded image exeed those limits, then PW creates a resized variation and stores that as the original! Otherwise, the original image will not get touched in any way! So, in short, ;-) The common denomination for colorspaces is sRGB! Browsers (and all other PC devices in a colorspace chain) per default do assume the sRGB profile, at least, if a profile is missing. Therefore, no ICC profile is needed. If you want to use more advanced features, should this be done automated by a webbrowser? We all know that different webbrowsers has done and do interpret features in different implementations, regardless of W3C standards. This is for different reasons: product- / company- political, simply missunderstood things or bugs, or what ever. If you want to publish images, do you really want to go that far, that you want use/try browser- or feature-sniffing, and than serve different imagevariations (with and without ICC) on assumed browsertypes? Using sRGB is the fastest (and a painless) way to serve homogenious results to different browsers. But what I meant with homogenious, was not how the images will look like in browsers of different vendors. I meant, that the way how PW handles the manipulations should be nearly independend of the used or available engine(s). So, per default, we use the lowest denominator, what is GD or everything else without ICC conversion possibilties. Also, for the average user and in most cases ( > 99% ?), the images will be in sRGB colorspace. Hopefully, most people who uses other colorspaces, also have a bit knowledge about imagehandling and therefor will know what they do. So, for those people, it may be an optional comfort feature to have ICC, but I'm not 100% sure, if this is really a comfort, despite all downside aspects. Long story / short saying: The default and core in PW only will have features that are used and or available for more than 30% of (assumed) PW installations. All other things belong into third party tools / modules.

Kay those 4 are now translatable (already pushed to gh) But I hav to investigate a little further why they not properly work..got another project to finish first.. But any hint is always welcome ;-) PS: Actually I planned to include a german translation file in the repo in the first place, but never made it

I think what you are looking for is whitelist: $input->whitelist($name, $value) Read about it under the getVars section on this page: https://processwire.com/api/modules/markup-pager-nav/

in MarkupCookieConsent.config.php line 54, 55 'dark' => __('dark (Default)'), 'light' => __('light') line 66, 67 'top' => __('top'), 'bottom' => __('bottom (Default)')

Ok, now it's clear, thanks for your explanations!

Recent Netpbm binaries for Windows are compiled and served by Terry Ron Vantreese. They can be found here: https://onedrive.live.com/?id=9E7DB242359A93F0!28283&cid=9E7DB242359A93F0 To use them, unpack them and put them into a subfolder. Enter the path to that directory into the designated inputfield in the modules config page. Save it, done!

Hi Jon, Actually a 500 internal server error is a very classical one and in many cases related to the .htaccess ? uncomment # RewriteBase / ? Options -Indexes ? Options +FollowSymLinks ? a module that needs to be updated. ? bad database connection Always do a new fresh install of processwire on the new host. This will tell you first hand if the .htaccess and the settings on the new host match up. Second replace your site folder with the one on the new host, but leave the config.php. Only replace the user salt in the config.php. Normally everything works at this stage but sometimes you have to empty out cache and sessions in /site/assets/cache/ and /site/assets/sessions/, or simply have to set the right php version on the host. If things still don't work set $config->debug = true; check your site/assets/logs/errors.txt, apache error logs.

Do you have any (even short) info about the use-cases for those engines? Even a "Just an alternative. Mostly comparable to … in speed/performance/quality" would be helpful for anyone looking at those.

Sorry you are having problems. Please review and go through the informative Troubleshooting Guide tutorial. https://processwire.com/docs/tutorials/troubleshooting-guide/ Here is information for the ProcessWire 3.x Version https://github.com/ryancramerdesign/ProcessWire/blob/devns/README.md Hopefully these 2 links will provide some help to you.

NOt an easy one, but maybe easier for you now: https://processwire.com/talk/topic/6096-imagick-resizer-need-to-be-tested-2/#entry59711

In my opinion this is a good idea, though it should be made clear that feature x getting a lot of votes doesn't mean it will be implemented – just that it's what most users voted on. If product development was all about "ask the crowd what they want and do it", products like ProcessWire – ones that dare to approach things from a different point of view – wouldn't exist. We'd just have a ton of WordPress clones. I'm not sure where I've heard it from and if it's even really true, but they claim that Nokia once asked their users what were the main griefs they had with their phones. The one they heard most was that the battery was drained too fast. For a long time their phones had terrific batteries, but in all other aspects they were way behind companies like Apple who literally decided not to listen to their customers. Sorry for going slightly off-topic, but my point here is that while it's good to ask what your users think, it doesn't mean that you should always do as they tell you. It can, nevertheless, provide you with new ideas and feedback regarding the direction you're going with your product. The idea is good, but needs to be put into right context

Thank you for the snippet lostkobrakai. Do you think it would somehow be possible or make sense to have kind of an export button (like the one at templates) that makes it possible to copy/download a script with all the API commands to create an exact copy of that field with all settings?

The system that's proven more effective for me is: 1 — do all the non destructive database changes on the live site (adding fields and adding them to templates, creating new templates and so on) 2 — import the database to the development server and do the templates changes 3 — pull the new files to the live site without touching the database 4 — do some cleaning on the live database if needed (remove fields, templates and so on) Another tip, although this one doesn't really answer your question, just because I think it can be useful One system that I already used effectively was to create another install of PW (a copy of the other) in the live server (on a subdirectory or subdomain) that connects to the same database, and develop all the changes on the template files right there, using real and up-to-date content. Then I simply replace the template folder by the new one.

Here's what solved the problem for me. Left page original settings of the auto generated publish fields, right page are my modification of the settings. no more "hh" and "ss" strings and the page scheduling works now so maybe for some reasons time formating options that need to be choosen was missed by the auto generated post_from/post_until fields, which i did'nt touched since creation.

I'll doubt this will find it's way into the core as extension of FieldtypeImage. A images field is a field to store images, not to choose them. Fields are first and foremost there to hold data. If you want to choose images then you'd need some kind of reference field, that just stores references to images, then it doesn't matter if they are from the current page or from another one.

Waarom opgeven ? Mocht ProcessWire niet werken, geef ik je weinig kans dat andere pakketten wel werken.