horst

a nice one: http://whatcolourisit.scn9a.org/

There is one thing that needs a bit attention when importing data. We need to check if a record was also imported by a previous run of the script, otherwise you may end up with numerous duplicates. while($row = $result->fetch_assoc()) { $title = wire("sanitizer")->text($row['title'], array("maxLength"=>128)); // fetch and sanitize the title $p = wire('pages')->get("title={$title}"); // check if it already exists if(0 < $p->id) continue; // move on to the next record if it exists $p = new Page(); $p->template = "dam"; $p->parent = "something"; $p->title = $title; // use the sanitized title $p->save(); }

Best information is given from the author himself in his blogpost

another goodie I have found a view days ago: http://www.fnordware.com/superpng/ (Source is at https://github.com/fnordware/SuperPNG)

... that now also lives in my Editor. - http://sourcefoundry.org/hack/ - .

Welcome @mauricius. This looks really awesome! PS: Best way to get early feedback is to publish a alpha- or beta-state github repo and post the link here. EDIT: PPS: yuhu, I saw & liked it first!

It depends on what PW version and third party modules you are using. If you only use the core imagesizer, you can use it with all the dis /-advantages mentioned above. This lines if ($field->type instanceof FieldtypeImage) { foreach ($file->getVariations() as $f) { fetch all valid variations that will be kept, regardless of the PW version you use. If you use the thumbnails module, this will work too. If you use the Pim 1 module this will work if you have $keepPimVariations enabled. With Pim 2 module, you don't need to enable $keepPimVariations, because Variations of Pim2 will be detected and kept by the core ->getVariations() method already. If you use other third party modules that create image variations, you need to check how they name the variations. If it matches the core naming scheme with -suffixes added to the original name or -suffixes added to a variation name, it will work. You can run the script and let the unlink() line commented the first time(s). This way you can read and check all selected filenames first, before you enable the deletion!

If you change options for image variations, you always can set "forceNew" => true, to force a recreation of the variation(s). This can be done everywhere, in line of code in a template to affect only those images, or in a module or even in site/config.php to force recreations for every variation on every page load site wide! (SO BE VERY CAREFULLY!) You can also use PIA. She has an option for that sitewide setting to switch on and off. This also only takes affect for logged in admin users, and not for page views by guest users. But I like the idea! I also have had a module (or proof of concept) that supported it, but it worked only with PW 2.4. and stopped working with all the changes on pageimage / imagesizer introduced in PW 2.5+ One minor thing: cropping is reflected in the variation names by the current core! Only upscaling, quality and sharpening is missing!

Hi Martin, uhm yeah, the imagickSizer is very old. It doesn't work with PW versions other than PW 2.4.x There were many changes done in PW core after I have created it and I haven't found the time to write a new one. Also there is an issue with transparent and / or indexed PNGs with IMagick that makes it very uncomfortable because exactly some issues with transparent PNGs in GD was the most annoying point why we once have started to build this as an alternative!

Ah, good to hear. I have used Photoshop CS5 to inspect & play with the images. It is always the best practice (if possible!) to upload unoptimized images with max quality to use them as the original source only. The only downside is that you cannot / should not serve those original source to the public. (But you can serve a variation with identical dimensions, but optimized and/or with lesser quality).

@soma: the above attached images seem to work fine here on my machine. ?? I don't see those lines. But in the past there were other images that had some artefacts. It mostly depends on settings for defaultGamma, sharpening and if sharpening uses USM (useUSM) or not. I suggest you try / experiment with the following options: $options = array( "forceNew" => true, "defaultGamma" => -1, // disable Gammacorrection "sharpening" => "none", // disable sharpening or use "soft" "useUSM" => true // use USM or disable it with false ); Sorry that I cannot more helpful with this. I used PW 2.6 stable and GD-lib with PHP 5.3 and PHP 5.4.

If you like, I can have a look at it if you pm me one of the original trasparent png images.

Martin, I would go with a fileupload field, not with an image field. If this has to do with the project we have talked about, you can copy / create a new inputfield of the default file upload field or use the default file-field and hook into file_added to further process the uploaded images with e.g. imagick or equivalent software on the server. PS: @Lostkobrakai, you are mainly right with what you say here, but I would avoid any clientside imageprocessing and only let the users upload the high quality file because there is a good chance that it will be a mix of RGB and CMYK files (maybe grayscaled too) each colorspace with different ICC-Profiles, what I think isn't handled by clientside imageuploaders.

when under fields: edit field -> tab input -> required [x] you can tip the checkbox, (like with the title field).

Hi Martin, if the filesize limit is 50 MB, the post_max_size should be a bit higher. I think it has to do with that post data is encoded so that the final post data is always greater than the original binary file data. Can you try upload_max_filesize 50M and post_max_size 65M?

this line will not work I believe: $p->parent = wire('pages')->get('/$parent/'); //set the parent '/$parent/' : if you use it with a variable as shown in your code, you must surround it with doublequotes: "/$parent/". Variables will not be populated within singlequotes. ------ Where is the code (line) where you check for existing records? Are there unique fields in your drupal data with the records that you can use? steps to do: 1) read (next) record from drupal source 2) fetch and prepare data for a unique identifier from it This can be a unique field within the drupal data, or, if this is not present, create a selector that may contain sanitized values for name / author / date or what is the best for your data. 3) do a get() with this selector If the page exists, modify it where needed or move on to the next record. If it do not exist, create it and populate fields.

$a->import($items); . or one of the other methods that are available with pagearrays / wirearrays.

I'm not completely sure if this is possible within the admin, but I think yes: one way can be to build a simple little module, another way can be to use one of the new implemented _ready.php | _install.php etc. files, if you use the one of the latest dev versions (PW 2.6.9+ ??) But regardless of that, you need to hook into after InputfieldURL::render Within your function you fetch the result ($event->return) and the url, if any given and prepend an image tag to the result. pseudo code, simplified: $url = ... ; // you need to fetch the url here $event->return = "<img src='{$url}' width='100' alt='' />" . $event->return; $event->replace = true; . EDIT: After rethinking it, I think you need to build a little custom module and cannot use the new _ready.php etc. files, but would be nice if some one can clarify this more precisly than I currently can.

I thought we are never ever advised to edit wire/config.php, we are strongly advised to edit site/config.php Or do I miss something new?

Ah, ok. It's an error ID. Feels like "thin air",

Oh, thanks, thats very helpful. I have a cron running there that starts a bootstrapped script two times per day. I think I put in some code to make it first login as a special user to be sure that it is the script that produces sometimes the errors. A bit weird with the error message is, that a page with ID 1062 exists, but it get not touched with the bootstrapped script. Also I have dumped the complete DB into an editor and searched for the string '41-0', but it isn't present, not only one times. And yes, it is a little annoying if one do not know this. The first thing I have done was uninstalling a module (jumplinks) that can be configured to deal with 404s. I've put all redirects into the htaccess file and after that for two weeks no error occured. But than it occured again without any further change on the site.

Every now and then (once a week or lesser) I get emailed the following error notification on one site that's running PW 2.6: Page: http://example.com/http404/ User: guest Error: Exception: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '41-0' for key 'PRIMARY' (in /www/htdocs/example.com/wire/core/FieldtypeMulti.php line 261) Does someone know what I may have missconfigured or what is responsible for it / where I should look into?

Does you have the folder and file mentioned in the error: site/templates/layouts/default.php? means: does it exist? AFAIK does SPEX want/need to copy some files during installation to site/templates/layouts/ and in regard of the filesystem settings this may have failed without notice. But the default files it uses are _base.php and one-column.php, but not default.php. So, with the template / page you are loading you must have set $spex->setLayout('default'); Does that help?

I would also check database setting: database character encoding should be utf-8 template files need to be utf-8 encoded HTML-Output need to be utf-8 encoded (header)

@valan: makes sense!