horst

I would place one global jquery.min.js at a central place and name it specific to that uploaded files: /unity.jquery.min.js Then I would delete all uploaded jquery.min.js or still would them leave unused. And in the html file I would correct the url to point to the global one: $htmlfilename = 'index.html'; // this need to hold the relative or better the absolute *filesystem path* (not url) to the unity html file $search = './jquery.min.js'; // this is how the jquery.min.js is embedded originally in the html file $replace = '/unity.jquery.min.js'; // this is the absolute URL to the global js file // a very rude method would be to just read the file content, replace the url and write it back into the file in just one line: file_put_contents($htmlfilename, str_replace($search, $replace, file_get_contents($htmlfilename))); . . But instead to do it in one line, you can use this steps one by one and optionally with validation: // fetch the file content $content = file_get_contents($htmlfilename); // optional validation if it has the whole content if (false === $content || strlen($content) != filesize($htmlfilename)) { // uups, we have had a read error ... } // replace the url of jquery.min.js $content2 = str_replace($search, $replace, $content); // optional validation if it exactly one time has changed the url in the content if (strlen($content2) != (strlen($content) - strlen($search) + strlen($replace))) { // uups, an error occured ... } // write it back into the html file $result = file_put_contents($htmlfilename, $content2, LOCK_EX); // optionally check if all data could be written into the file if (false === $result || strlen($content2) != $result) { // uups, we have had a write failure ... } . The validation for str_replace can also be done with an optional fourth parameter: // replace the url of jquery.min.js $replacementCounter = 0; $content = str_replace($search, $replace, $content, $replacementCounter); // optional validation if it exactly one time has changed the url in the content if (1 != $replacementCounter) { // uups, an error occured ... }

@cb2004: welcome to PW and the forums. Uploading through / or from within a RTE field is a very new feature in PW. I never have done it 'til now . But I also try to organize population of content where & when ever I can with other fieldtypes. So, this 'Display in Select Image plugin only' - visibility - setting may sound interesting.

In a first glance it looks interesting, but after the second I would say it isn't worth. You just would mimik something what is already available, only on another layer. For me it would be better to invest the needed energy into something like using linux / unix system calls via ssh. There is already everything one need for those stuff. And if one do not have access to shell on cheap shared hostings, I believe one also will not get something useful to work via a PHP-PW extra layer. EDIT: and for all things related to PW, I use bootstrap scripts from the commandline.

Not imagesizer options but "during development" forceNew setting was of interest, but this also doesn't affect it here. Have you disabled the other modules too? Can you do it, (maybe in a new test install)? And then try it one by one. Uninstall all site modules. Then only install Pia and try it. If no other site module is installed, I believe it will work with Pia too. If it does, install the next module to it, e.g. ImageExtra. If it works together, install the next one, etc. (Do this also for other modules, e.g. SEO or other you may have installed yet.)

Thanks for the screencast. But that's what I also do and it works here. Only thing that seems other here is I have no german language pack installed. What are your settings for Pia? I have tried it with the global ForceNew set to true and to false, both is working here. So, what makes me completly wonder is why Pia is / should be invoked in your site when editing with the new pageimage field cropping tool. It doesn't make sense. The new image tool don't call Pia, and Pia only should get invoked by explicitly calling her: $this->addHook('Pageimage::pia', $this, 'PiaBallerina'); $this->addHook('Pageimage::crop', $this, 'PiaMakeCrop'); $this->addHook('Pageimage::cover', $this, 'PiaMakeCover'); $this->addHook('Pageimage::contain', $this, 'PiaMakeContain'); $this->addHook('Pageimage::retinafy', $this, 'PiaCreateRetinafy'); $this->addHook('Pageimage::hiDPI', $this, 'PiaCreateRetinafy'); She only add her own methods to the Pageimage and do not hook into any existing one. And in my testsite it doesn't get invoked. Why is it with your site? There must be something other that interferes with using the new cropping tool.

Hey Torsten, What exactly have you done? Can you explain exactly, step by step, so that I can reproduce it? Edit: Can you reproduce it? I have installed latest dev from today 2.5.22, but it is a bit different from an earlier 2.5.22 (maybe a week ago) and everything in regard to Pia works fine.

You Need to fetch the dev branch, Not the stable branch. Have a look at download. (Sorry, on mobile currently)

A bit OT, but if you can plan the languages hirarchy right from the start of a new site, you can do it this way: enable languages support set Title / Label of the default language to your desired none english native language, (e.g. 'Deutsch' (German)) drop in the none english language pack (for admin backend) into the default language, (e.g. german langpack) add a new language to it and drop in a language pack for any none english language or simply don't drop in a language pack to get the english version (but not as the default one!) As a nice sideeffect every new user in your system gets the native language per default without have it to select from the list. So, yes, this is no solution if you once have set it up and need to switch the default language afterwards, but just want to note it.

Maybe I don't know the right words to describe it, but PHP 5.3 is somehow bundled with Ubuntu LongTermSystems support for example and it gets hardened and patched via their update channels, so it still is secure. Those Ubuntu systems are very common on hosting machines and it is a good idea for PW to orientate on their lifecycle.

@owzim: best way to understand how it works is to look into Pageimage. There you see that ImageSizer only gets a filename of an image variation and the manipulation params ($options) and that it saves the result right into that given filename. All other, (caching, renewing, etc) isn't handled by ImageSizer (but by Pageimage).

completly OT: welcome to the forums m-artin. May I say that your avatar looks a bit like it has got to many noise added with photoshop? As a experienced photoshoper I think this way it looks a bit better: But that's only my personal opinion.

@formulate: in which size do you request the images? Is it greater than the original image size and if so, what is your setting for "upscaling"? Do you know, bzw. have read, that Reno removed all variations before calling size()? Do you do so too? Depending on your PW version you also can add a "forceNew"=>true to the options array instead of using removeVariations() before calling size().

DatabaseStopwords.php and https://github.com/ryancramerdesign/ProcessWire/blob/master/wire/core/DatabaseStopwords.php#L83 Maybe something like: DatabaseStopwords::remove("about"); in the config.php or on top of a / the search.php ?

@Adrian: this one is obsolete. It only would work with PW before 2.5 I think and also the IMagick Extension struggles with one sort of transparent PNG. There are 5 different sorts of PNG possible: 24 bit none transparent 8 bit none transparent 24 bit transparent (smooth) 8 bit transparent (hard), (a bit like GIF with 255 palette and 1 transparent pixel) 8 bit transparent (with a sort of semi transparent pixels, not like with the 24 bit but also different then hard cutted) The IMagick extension doesn't detect 8 bit hard transparent images and renders them with black noice, but not only a few pixels. It renders most of the transparent area black. I haven't found any information on the net about how to work around that.

I don't know what .PagefilesManagerxxx is. CroppableImages doesn't use it or interacts with it. ImageSizer also don't. I think it stays there from a upgrade or something? It is preceded by a dot, what is a sign that it isn't read from any PW object. It is a backup directory. (That's all I can think of)

Hi @icreation, thanks for dropping in all relevant things: original image, scaled image variation and issue description. But, however, I have no good message for you. The GD-Image-Library that is shipped with PHP for image handling cannot handle smooth transients from opaque to transparent. Also if the image looks like it would only have hard cuts between full color and full transparent areas, it isn't that way. Have a look to my screenshots to understand what I try to say (as a none native english speaker / writer). Especially look at the red dot from the colorpicker and the values for RGB in the info palette: here it shows the values for blue (46, 172, 250) . here in the transparent area it shows nothing . but here, almost 4-5 pixel away from the color area, it shows the exact RGB values like in the blue area (46, 172, 250). Obviously this area has a transparency from nearly 100%, but only nearly. In fact it has only 98 - 99% transparency what let the GD-Library struggle with it. --- I don't know how comfortable your client are with image manipulation in regard of understanding this. The graphics look professional though. If they could try to cut them without that smooth area maybe it will be better. Or you / they could try to export the graphics to GIF instead of PNG. Additionally to that you can tweak the imageSizerOptions for those images to render with these values: $options = array( 'defaultGamma' = -1, 'sharpening' = 'none' ); $image = $image->size($width, $height, $options); Hope that helps a bit.

@Martijn: I have installed this the first time now because I needed to overwrite some Admin Theme styles and also add some new. An awesome experience, - I just installed it, tipped the checkbox for including the AdminTheme-files and dropped the css files into templates/AdminCustomFiles.

Ah ok, - now I understand. I should had read better the descriptions. Version Control is the following Module of Version Control For Text Fields and replaces it. Version Control For Text Fields now is obsolete with PW 2.5+ and I should use Version Control also for one single Textfield. Thanks @Mike_Anthony, you have read it more thoroughly!

But the right Module page don't. It only says 2.2, 2.3, 2.4! That's why I have asked here You are on the wrong page. PS: I only need the small solution.

Hi Teppo, is it compatible with PW 2.5 ?

what is the name of your imagefield? does it contain mixed chars, I mean upper and lower case? If so, can you try it with a fieldname that only has lowercase chars? As I said above for me the caching works as expected with PW 2.5.19

This doesn't help me much because I have tested it today with PW 2.5.19 dev and it works well with caching here. ?? Maybe there is something different with previously installed and used fields, (before upgrading PW to 2.5.18 or 2.5.19) in regard to new created fields? Another thing you may test is a check for forceNew just before you call the getCrop: $forceNew = isset($config->imageSizerOptions['forceNew']) ? $config->imageSizerOptions['forceNew'] : false; $forceNew = $forceNew ? '<p>forceNew is ON</p>' : '<p>forceNew is off</p>'; $page->imageCrop->getCrop('test')->url;

@adrian: this is a bit weird. I cannot think of any possibility how you got this. In the __construct() it is explicitly set, at least it get populated with null. And there is no code in the whole class where it is unset. So, after initiating the class, it is set. The function where the notice came from isn't a static one, so ...? Can you reproduce it?

Hey, regarding the serious performance issues, can you please tell a bit more about what it is what you have done etc? Is it in the Backend with displaying the items in the Inputfield, or is it in the Frontend or is it on Uploading or with the CropEditor? I have installed the PW 2.5.19 and run some tests where I cannot see differences between PW 2.5.11. So, I don't have had PW 2.5.18 at hand. Please can someone confirm that the performance issues consists with PW 2.5.19 and explain a bit more detailed what the issues are. (reproducable!) Caching of the cropvariations does work as expected here.

If someone want to give something for modules that I have shared, I would much appreciate if he/she donate something for children or children's projects where he/she lives. There is no better investment than our children and it makes good spirit and good karma! Edit: just to clarify: By "our children" I mean all (our) children!