horst

No sorry, this isn't possible.

A module yes. But instead to hook into upload, you also can hook into page::save or page::saveReady I think. It depends upon how you have organized your site. Have those unity project pages an own template or not etc. Or do you only upload html files to those pages and not in others too. At least it will work this or that way. You will find many posts with example code here in the forums. One that hooks into upload / fileAdd is here. page::save is here and page::saveReady here. But there are lots more

a single point I don't understand: What does it mean, good IDE support?

It is mostly possible to cache values or even markup. Don't know how your site works, but if it isn't updated every minute there is a good chance to cache and re-use the markup of your filter form. This would speed up things a lot.

I believe it only can used with field=value, not with path or parent. So, one may define and add a hidden field to that template and hook into page::saveready and populate this field with a true or false value regarding if the current page has that parent or not. my_hidden_field=1 If you want to go that road we can show some examples how to achieve that.

But I think the checkbox states are saved with the pages, or not? if ($pages->checkbox_bc) { // the fields bundled to "Basic Car" are in use You once have to manually note which fields belong to which subtemplate, (will be good if the fields will not grow in the future) or you stick with a naming scheme and iterate over all template fields to get that information. Maybe not very elegant or high dynamcly, but a fast way to get the job done. EDIT: $subtemplateIds = array('bc'=>aray(), 'fwd'=>array()); foreach($page->template->fields as $field) { foreach(array_keys($subtemplateIds) as $k) { $fn = $field->name; $len = strlen($k) + 1; if (substr($fn, 0, $len) == $k . '_') { $subtemplateIds[$k][] = $fn; } } } // later on you can check like: if ($page->checkbox_bc) { // use also all fields from $subtemplateIds['bc'] } (written in browser, be careful )

Yipieh! Looks like a task for an importer script! The XML has <DocumentID>123456</DocumentID> what seems to be the boat-article-ids. So, you can go with it manually via importer script, or first have a look for getting a PHP conversion lib that converts xml to csv and then maybe use the CSV module for importing. But it is also very easy done manually with an importer script, (bootstrapping PW, running via cron or via PWs lazyCron). If you need any further explanation, please ask here. EDIT: @Adrian beats me a few seconds

Na, there is also PageTable and PageTableExtended available.

Is it needed for the Backend Editmode? What's about to simply have one template with some fieldsets, each fieldset contains a few fields (those you mentioned in your subtemplates) and the visibility of the fieldsets are bound through checkboxes and the onlyShowIf settings for templates? | Select granule Subtemplates: | | | | [ ] use Basic-Car | [ ] use Diesel-Engine | [ ] use Turbo-Engine | [ ] use Four-Wheel-Drive | | | | Select granule Subtemplates: | | | | [x] use Basic-Car | [ ] use Diesel-Engine | [ ] use Turbo-Engine | [ ] use Four-Wheel-Drive | | | |--- Basic car -------------------------------------------------------------------------------| | | | BC_textfield_1 BC_ceckbox_1 ... | | | |---------------------------------------------------------------------------------------------| | Select granule Subtemplates: | | | | [x] use Basic-Car | [ ] use Diesel-Engine | [ ] use Turbo-Engine | [x] use Four-Wheel-Drive | | | |--- Basic car -------------------------------------------------------------------------------| | | | BC_textfield_1 BC_ceckbox_1 ... | | | |---------------------------------------------------------------------------------------------| |--- Four-Wheel-Drive ------------------------------------------------------------------------| | | | FWD_textfield_1 FWD_ceckbox_1 .... | | | |---------------------------------------------------------------------------------------------| - Pseudocode is like: only show Fieldset_BasicCar if Checkbox_BC is checked

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.