Leaderboard

Just finished a website for a Branding Agency I work together with in Karlsruhe, Germany. "Classic" Masonry stuff, but some nice additions for the client: They can - according to their client's brand - define the main color in RBG values in a field. These values are translated in Hex values and output via PW, so the tiles get the client's colors (mostly on hover) Tile sizes are controlled via a field They can decide to start a tile with an image, headline or logo Images are cycled through no matter how much images they define They can control the whole website, either if they want to create a new tiles overview or a single page or a page which collects its children for a one pager Cheers!

Or a bit of API vodoo. $old_name = 'lizard.jpg'; $new_name = 'wizard'; $p = $pages->find("image.data=$old_name")->first; $p->of(false); // outputformatting off, single and multiple image fields are from now on wire array's $path = $p->image->path; $page_image = $p->image->first(); $ext = $page_image->ext; $orig_image = $page_image->filename $new_image = $path . $new_name . "." . $ext; echo "orig: " . $orig_image . "<br/>"; echo "path: " . $path . "<br/>"; echo "ext: " . $ext . "<br/>"; echo "new: " . $new_image . "<br/>"; // copy and rename copy($orig_image, $new_image); // remove old, add new image to page $p->image->remove($page_image); // orig, will get deleted $p->image->add($new_image); // new $p->save(); Or in a shorter code: https://gist.github.com/somatonic/6282944

Sorry about that guys. It turns out that it was trying to execute a query to update the schema of the DB table, before the table existed. The exception interrupted the creation of the field in the DB. I've fixed the issue and posted an update. This applies to new MapMarker fields only, no problem with existing fields (which is why I hadn't noticed). This update should also enable you to delete any fields you created that had this error (you'll want to delete it and re-create it, since it doesn't have a table). Regarding the "ENGINE=MYISAM" statement, that should already be getting added by the base Fieldtype.php. In your case, it probably didn't because the field creation process was getting interrupted. But I did double check to be sure: echo "<pre>"; $ft = $modules->get('FieldtypeMapMarker') print_r($ft->getDatabaseSchema($fields->get('map'))); results in: Array ( [pages_id] => int UNSIGNED NOT NULL [data] => VARCHAR(255) NOT NULL DEFAULT '' [keys] => Array ( [primary] => PRIMARY KEY (`pages_id`) [data] => FULLTEXT KEY `data` (`data`) [latlng] => KEY latlng (lat, lng) [zoom] => KEY zoom (zoom) ) [xtra] => ENGINE=MyISAM DEFAULT CHARSET=utf8 [lat] => FLOAT(10,6) NOT NULL DEFAULT 0 [lng] => FLOAT(10,6) NOT NULL DEFAULT 0 [status] => TINYINT NOT NULL DEFAULT 0 [zoom] => TINYINT NOT NULL DEFAULT 0 ) Please let me know if you are getting a different result or still needing to specify the engine separately?

This is kinda fun... Q: How could I easily replace the original pageimage keeping same filename?

I looked closer and it doesn't work as simple, you have to call trackChange on image field for basename and remove variations too. So this will work: $old_name = 'wizard.jpg'; $new_name = 'lizard'; $p = $pages->get("image.data=$old_name"); $p->of(false); // outputformatting off, single and multiple image fields are from now on wire array's // get the image and the extension $image = $p->image->find("name=$old_name")->first(); $ext = $image->ext; $newFilename = $new_name . "." . $ext; $p->image->trackChange("basename"); $image->removeVariations(); $image->rename($newFilename); $p->save("image");

Ahhh Mr. ImageHorstManipulation No it doesn't work I'm afraid to say. Also the image variations doesn't get deleted and the image will not be changed in DB.

I did not try the following code, but I think it should work: foreach ($pages->find("status>=" . Page::statusTrash) as $p) { $p->delete(); } Edit: Soma was faster again..

If that's right it would the the first child or the first child that has children? Not sure. But he's speaking of a "parent"? So this would be easy with $page->child("template=xy, children.count>0"); To get the first child of a page: $page->child() will give you the first child with regarding to the sorting. $page->child("template=sowieso") same as $page->children("template=xy")->first();

When you are running APC a good function to know is apc_clear_cache(). Put that in a file and run it, or maybe added it to your homepage template file with some code like this: if($user->isSuperuser() && $input->get->clear_apc) apc_clear_cache(); Then you could just access your site and do this: http://domain.com/?clear_apc=1. It's not often you'll need to clear the APC cache, but it's a good idea any time you see anything weird like this. However, I'm guessing that the table really doesn't exist and the error messages are correct. Though I'm also guessing the table creation process got screwed up by the APC cache somehow. I would go into PhpMyAdmin and create the table manually, so that you can either use it or delete it. Paste this into the PhpMyAdmin SQL tab and execute it: CREATE TABLE `field_event_image` ( `pages_id` int(10) unsigned NOT NULL, `data` varchar(255) NOT NULL, `sort` int(10) unsigned NOT NULL, `description` text NOT NULL, `modified` datetime DEFAULT NULL, `created` datetime DEFAULT NULL, PRIMARY KEY (`pages_id`,`sort`), KEY `data` (`data`), KEY `modified` (`modified`), KEY `created` (`created`), FULLTEXT KEY `description` (`description`) ) ENGINE=MyISAM DEFAULT CHARSET=utf8; After clearing the APC cache, try creating a new image field and see if it's still having problems?

Just so we are on the same page understand each other Home About Mission History 1800 1900 2000 rootParent of About = About rootParent of Mission = Mission rootParent of History = History rootParent of 1800, 1900, 2000 = History $page->parent of About, Mission, History = Home $page->parent of 1800, 1900, 2000 = History $page->parents of About, Mission, History = Home $page->parents of 1800, 1900, 2000 = History, Home

I wouldn't consider it a bug necessarily, but it sure would be nice if it would throw a JS error or something. This was a difficult one to track down.

Ryan, glad to see you working on this module! It looks like you already figured this out, but /site/assets/cache/[your dir] is usually a good place to store things like XML cache files. If connected with a page, then just use the page's files dir ($page->filesManager->path or $page->[your files field]->path). Horst is right that you can add files to pages and manipulate them using PW's methods from there. He's also written an excellent manipulation module. If you just need to resize images, also look into PW's ImageSizer class, which is ready to operate on any file (doesn't need to be connected to a page). In the dev branch, I'm about to push some updates to that class from Horst that add sharpening and auto rotation among other tweaks. Lastly, I wanted to mention that the dev branch also has the WireHttp class, which you may find more convenient than CURL.

Top level page $page->rootParent Top level pages of a template $pages->find("template=thing, parent=1") // 1 is the ID of the homepage, so a child will automatically be the top level page

I went ahead and made a "powered by processwire" animated GIF if anyone would like to use it Have two versions - one for black backgrounds and one for white. I made it kind of large so you can shrink it to whatever size you'd like. I am using a setting of 140 by 47 pixels. You can see the one for black backgrounds in action at one of the sites I designed here. I am searching for a GIF animator that will allow PNG files so I can have it completely transparent on any background. Will upload soon. For White Background For Black Backgrounds

You can't just rename them physically and then think PW magically still knows which file it is. This is because PW saves the name of the file to the db. It's like the key! So you'd also have to rename it in the DB table field_yourfieldname also and you'll see.

When searching pages with images field, there's no subfield "name" for images, but you can use images.data. And you won't get the image but a page(s) $p = $wire->pages->get("images.data%=mode"); // get return the first match echo $p->images->get("filename%=mode")->url; Or $p = $wire->pages->find("images.data=modelifestyle.jpg")->first(); // returns a pagearray and we access first echo $p->images->get("filename%=mode")->url; Or echo $p->images->get("name%=mode")->url; Or echo $p->images->find("filename%=mode")->first()->url; Or echo $p->images->get("modelifestyle.jpg")->url; Or echo $p->images->get("modelifestyle.jpg")->name; // image name or echo $p->images->get("modelifestyle.jpg")->filename; // full path

1) you may do this by using a hidden tools page with an images field and than you only have to use $page->images->add($shotImageUrl) to save the image to the tools page assets directory. And you have it as PageImage and you can do all image api stuff 2) I have uploaded a new module for Image Manipulation. With this you are able to use some well known image methods (width, height, size) and you can store the image together with your xml or json file instead of creating and using a tools page with InputFieldtypeImage. Example (this could be somewhere in your makeRequest method): // get your image from dribble and save it to your cache directory $shotImageUrl = 'http://dribble.com/some/path/to/image.jpg'; $imgCacheFile = $this->cachePath . md5($url) . '.image.jpg'; $result = file_put_contents($imgCacheFile, file_get_contents($shotImageUrl)); // if $result is not false and greater than zero the image was successfully saved, // now you can load the $imgCacheFile into the ImageManipulator, resize it and save it by overwriting the $imgCacheFile $boolResult = wire('modules')->get('PageImageManipulator')->imLoad($imgCacheFile)->resize(360)->save(); // thats all PS: if you want rely on the PageImageManipulator module, you can set it as needed dependency for your module: public static function getModuleInfo() { return array( // ... 'requires' => array('PageImageManipulator'), ); } see: http://processwire.com/talk/topic/778-module-dependencies/

Would something like this work? (written in browser, so might need tweaking). This should print all events sorted by date descending, but grouped by day and sorted by time ascending within the day. $allEvents = $pages->find("parent=/events/, sort=-date"); while($allEvents->count()) { $event = $allEvents->first(); $from = strtotime(date('Y-m-d 00:00', $event->getUnformatted('date'))); $to = strtotime("+1 day", $from); $events = $events->find("date>=$from, date<$to, sort=date"); echo "<h3>Events on " . date('F j, Y', $from) . "</h3>"; foreach($events as $event) { echo "<p><a href='$event->url'>$event->title</a> $event->date</p>"; $allEvents->remove($event); } }

You could use the config options for page secure files... $config->pagefileSecure = true; $config->pagefileSecurePathPrefix = '-'; and make unpublished pages and their files will not be accessible via url. So you could create child pages under the users page with a file field, and leave those pages unpublished. The assets directory will be prefixed with "-" which is restricted by htaccess. But then you can use a passthru script to send the file to the user if certain requirements are given using wireSendFile(); So for example construct the download link to the file like this on a page the user can see. <a href="/download.php?user=1007&file=filename.pdf">Download file</a> and in download.php with something like this for the passthru and user check // bootstrap PW include("./index.php"); // make sure user is logged in if(wire("user")->isLoggedin()){ $file = $_GET['file']; $userid = $_GET['user']; $userpage = wire("pages")->get(wire("user")->id); if($userpage->id != $userid) die("no access"); // make sure it's the user if($filepage = $userpage->child("include=all")){ // since page is unpublished we add include all // get the file from the page $filename = $filepage->images->get($file)->filename; if(!$filename) die("download not found"); // send file to browser wireSendFile($filename, array('exit' => true)); } else { die("no user page found"); } } else { wire("session")->redirect("/somepage/"); }

Create custom admin pages easily without having to build a Process Module especially for that. ☞ This module makes it easy to create simple admin pages but you can also create them in much more powerfull way without the need of a module. Have a look at this post written by Bernhard Baumrock to know how it's done https://processwire.com/blog/posts/building-custom-admin-pages-with-process-modules/ ------- I just updated the module, I kind of merged the two versions and now it works with both stable and dev versions of PW. Only difference is that with the stable version you still need to create the child pages and with dev version that is not needed. The instructions are on Github. Enjoy ---- Download or clone from Github https://github.com/ocorreiododiogo/pw-admin-custom-pages Module page is here http://modules.processwire.com/modules/process-admin-custom-pages/

--------------------------------------------------------------------------------------------------------------------------------- when working with PW version 2.6+, please use Pim2, not Pim! read more here on how to change from the older to the newer version in existing sites --------------------------------------------------------------------------------------------------------------------------------- PageImage Manipulator, API for version 1 & 2 The Page Image Manipulator is a module that let you in a first place do ImageManipulations with your PageImages. - And in a second place there is the possibility to let it work on any imagefile that exists in your servers filesystem, regardless if it is a 'known PW-image'. The Page Image Manipulator is a Toolbox for Users and Moduledevelopers. It is written to be as close to the Core ImageSizer as possible. Besides the GD-filterfunctions it contains resize, crop, canvas, rotate, flip, sharpen, unsharpMask and 3 watermark methods. How does it work? You can enter the ImageManipulator by calling the method pim2Load(). After that you can chain together how many actions in what ever order you like. If your manipulation is finished, you call pimSave() to write the memory Image into a diskfile. pimSave() returns the PageImage-Object of the new written file so we are able to further use any known PW-image property or method. This way it integrates best into the ProcessWire flow. The three examples above put out the same visual result: a grayscale image with a width of 240px. Only the filenames will slightly differ. You have to define a name-prefix that you pass with the pimLoad() method. If the file with that prefix already exists, all operations are skipped and only the desired PageImage-Object gets returned by pimSave(). If you want to force recreation of the file, you can pass as second param a boolean true: pim2Load('myPrefix', true). You may also want to get rid of all variations at once? Than you can call $pageimage->pim2Load('myPrefix')->removePimVariations()! A complete list of all methods and actions are at the end of this post. You may also visit the post with tips & examples for users and module developers. How to Install Download the module Place the module files in /site/modules/PageImageManipulator/ In your admin, click Modules > Check for new modules Click "install" for PageImageManipulator Done! There are no configuration settings needed, just install and use it. Download (version 0.2.0) get it from the Modules Directory History of origins http://processwire.com/talk/topic/3278-core-imagemanipulation/ ---------------------------------------------------------------------------------------------------------- Page Image Manipulator - Methods * pimLoad or pim2Load, depends on the version you use! pimLoad($prefix, $param2=optional, $param3=optional) param 1: $prefix - (string) = mandatory! param 2: mixed, $forceRecreation or $options param 3: mixed, $forceRecreation or $options return: pim - (class handle) $options - (array) default is empty, see the next method for a list of valid options! $forceRecreation - (bool) default is false It check if the desired image variation exists, if not or if forceRecreation is set to true, it prepares all settings to get ready for image manipulation ------------------------------------------------------------------- * setOptions setOptions(array $options) param: $options - (array) default is empty return: pim - (class handle) Takes an array with any number valid options / properties and set them by replacing the class-defaults and / or the global config defaults optionally set in the site/config.php under imageSizerOptions or imageManipulatorOptions. valid options are: quality = 1 - 100 (integer) upscaling = true | false (boolean) cropping = true | false (boolean) autoRotation =true | false (boolean) sharpening = 'none' | 'soft' | 'medium' | 'strong' (string) bgcolor = (array) css rgb or css rgba, first three values are integer 0-255 and optional 4 value is float 0-1, - default is array(255,255,255,0) thumbnailColorizeCustom = (array) rgb with values for colorize, integer -255 - 255 (this can be used to set a custom color when working together with Thumbnails-Module) outputFormat = 'gif' | 'jpg' | 'png' (Attention: outputFormat cannot be specified as global option in $config->imageManipulatorOptions!) set {singleOption} ($value) For every valid option there is also a single method that you can call, like setQuality(90), setUpscaling(false), etc. ------------------------------------------------------------------- * pimSave pimSave() return: PageImage-Object If a new image is hold in memory, it saves the current content into a diskfile, according to the settings of filename, imagetype, targetFilename and outputFormat. Returns a PageImage-Object! ------------------------------------------------------------------- * release release() return: void (nothing) if you, for what ever reason, first load image into memory but than do not save it, you should call release() to do the dishes! ? If you use pimSave() to leave the ImageManipulator, release() is called automatically. ------------------------------------------------------------------- * getOptions getOptions() return: associative array with all final option values example: ["autoRotation"] bool(true) ["upscaling"] bool(false) ["cropping"] bool(true) ["quality"] int(90) ["sharpening"] string(6) "medium" ["targetFilename"] string(96) "/htdocs/site/assets/files/1124/pim_prefix_filename.jpg" ["outputFormat"] string(3) "jpg" get {singleOption} () For every valid option there is also a single method that you can call, like getQuality(), getUpscaling(), etc. See method setOptions for a list of valid options! ------------------------------------------------------------------- * getImageInfo getImageInfo() return: associative array with useful informations of source imagefile example: ["type"] string(3) "jpg" ["imageType"] int(2) ["mimetype"] string(10) "image/jpeg" ["width"] int(500) ["height"] int(331) ["landscape"] bool(true) ["ratio"] float(1.5105740181269) ["bits"] int(8) ["channels"] int(3) ["colspace"] string(9) "DeviceRGB" ------------------------------------------------------------------- * getPimVariations getPimVariations() return: array of Pageimages Collect all pimVariations of this Pageimage as a Pageimages array of Pageimage objects. All variations created by the core ImageSizer are not included in the collection. ------------------------------------------------------------------- * removePimVariations removePimVariations() return: pim - (class handle) Removes all image variations that was created using the PIM, all variations that are created by the core ImageSizer are left untouched! ------------------------------------------------------------------- * width width($dst_width, $sharpen_mode=null) param: $dst_width - (integer) param: $auto_sharpen - (boolean) default is true was deleted with version 0.0.8, - sorry for breaking compatibility param: $sharpen_mode - (string) possible: 'none' | 'soft' | 'medium' | 'strong', default is 'soft' return: pim - (class handle) Is a call to resize where you prioritize the width, like with pageimage. Additionally, after resizing, an automatic sharpening can be done with one of the three modes. ------------------------------------------------------------------- * height height($dst_height, $sharpen_mode=null) param: $dst_height - (integer) param: $auto_sharpen - (boolean) default is true was deleted with version 0.0.8, - sorry for breaking compatibility param: $sharpen_mode - (string) possible: 'none' | 'soft' | 'medium' | 'strong', default is 'soft' return: pim - (class handle) Is a call to resize where you prioritize the height, like with pageimage. Additionally, after resizing, an automatic sharpening can be done with one of the three modes. ------------------------------------------------------------------- * resize resize($dst_width=0, $dst_height=0, $sharpen_mode=null) param: $dst_width - (integer) default is 0 param: $dst_height - (integer) default is 0 param: $auto_sharpen - (boolean) default is true was deleted with version 0.0.8, - sorry for breaking compatibility param: $sharpen_mode - (string) possible: 'none' | 'soft' | 'medium' | 'strong', default is 'soft' return: pim - (class handle) Is a call to resize where you have to set width and / or height, like with pageimage size(). Additionally, after resizing, an automatic sharpening can be done with one of the three modes. ------------------------------------------------------------------- * stepResize stepResize($dst_width=0, $dst_height=0) param: $dst_width - (integer) default is 0 param: $dst_height - (integer) default is 0 return: pim - (class handle) this performs a resizing but with multiple little steps, each step followed by a soft sharpening. That way you can get better result of sharpened images. ------------------------------------------------------------------- * sharpen sharpen($mode='soft') param: $mode - (string) possible values 'none' | 'soft'| 'medium'| 'strong' return: pim - (class handle) Applys sharpening to the current memory image. You can call it with one of the three predefined pattern, or you can pass an array with your own pattern. ------------------------------------------------------------------- * unsharpMask unsharpMask($amount, $radius, $threshold) param: $amount - (integer) 0 - 500, default is 100 param: $radius - (float) 0.1 - 50, default is 0.5 param: $threshold - (integer) 0 - 255, default is 3 return: pim - (class handle) Applys sharpening to the current memory image like the equal named filter in photoshop. Credit for the used unsharp mask algorithm goes to Torstein Hønsi who has created the function back in 2003. ------------------------------------------------------------------- * smooth smooth($level=127) param: $level - (integer) 1 - 255, default is 127 return: pim - (class handle) Smooth is the opposite of sharpen. You can define how strong it should be applied, 1 is low and 255 is strong. ------------------------------------------------------------------- * blur blur() return: pim - (class handle) Blur is like smooth, but cannot called with a value. It seems to be similar like a result of smooth with a value greater than 200. ------------------------------------------------------------------- * crop crop($pos_x, $pos_y, $width, $height) param: $pos_x - (integer) start position left param: $pos_y - (integer) start position top param: $width - (integer) horizontal length of desired image part param: $height - (integer) vertical length of desired image part return: pim - (class handle) This method cut out a part of the memory image. ------------------------------------------------------------------- * canvas canvas($width, $height, $bgcolor, $position, $padding) param: $width = mixed, associative array with options or integer, - mandatory! param: $height = integer, - mandatory if $width is integer! param: $bgcolor = array with rgb or rgba, - default is array(255, 255, 255, 0) param: $position = one out of north, northwest, center, etc, - default is center param: $padding = integer as percent of canvas length, - default is 0 return: pim - (class handle) This method creates a canvas according to the given width and height and position the memory image onto it. You can pass an associative options array as the first and only param. With it you have to set width and height and optionally any other valid param. Or you have to set at least width and height as integers. Hint: If you want use transparency with rgba and your sourceImage isn't of type PNG, you have to define 'png' as outputFormat with your initially options array or, for example, like this: $image->pimLoad('prefix')->setOutputFormat('png')->canvas(300, 300, array(210,233,238,0.5), 'c', 5)->pimSave() ------------------------------------------------------------------- * flip flip($vertical=false) param: $vertical - (boolean) default is false return: pim - (class handle) This flips the image horizontal by default. (mirroring) If the boolean param is set to true, it flips the image vertical instead. ------------------------------------------------------------------- * rotate rotate($degree, $backgroundColor=127) param: $degree - (integer) valid is -360 0 360 param: $backgroundColor - (integer) valid is 0 - 255, default is 127 return: pim - (class handle) This rotates the image. Positive values for degree rotates clockwise, negative values counter clockwise. If you use other values than 90, 180, 270, the additional space gets filled with the defined background color. ------------------------------------------------------------------- * brightness brightness($level) param: $level - (integer) -255 0 255 return: pim - (class handle) You can adjust brightness by defining a value between -255 and +255. Zero lets it unchanged, negative values results in darker images and positive values in lighter images. ------------------------------------------------------------------- * contrast contrast($level) param: $level - (integer) -255 0 255 return: pim - (class handle) You can adjust contrast by defining a value between -255 and +255. Zero lets it unchanged, negative values results in lesser contrast and positive values in higher contrast. ------------------------------------------------------------------- * grayscale grayscale() return: pim - (class handle) Turns an image into grayscale. Remove all colors. ------------------------------------------------------------------- * sepia sepia() return: pim - (class handle) Turns the memory image into a colorized grayscale image with a predefined rgb-color that is known as "sepia". ------------------------------------------------------------------- * colorize colorize($anyColor) param: $anyColor - (array) like css rgb or css rgba - but with values for rgb -255 - +255, - value for alpha is float 0 - 1, 0 = transparent 1 = opaque return: pim - (class handle) Here you can adjust each of the RGB colors and optionally the alpha channel. Zero lets the channel unchanged whereas negative values results in lesser / darker parts of that channel and higher values in stronger saturisation of that channel. ------------------------------------------------------------------- * negate negate() return: pim - (class handle) Turns an image into a "negative". ------------------------------------------------------------------- * pixelate pixelate($blockSize=3) param: $blockSize - (integer) 1 - ??, default is 3 return: pim - (class handle) This apply the well known PixelLook to the memory image. It is stronger with higher values for blockSize. ------------------------------------------------------------------- * emboss emboss() return: pim - (class handle) This apply the emboss effect to the memory image. ------------------------------------------------------------------- * edgedetect edgedetect() return: pim - (class handle) This apply the edge-detect effect to the memory image. ------------------------------------------------------------------- * getMemoryImage getMemoryImage() return: memoryimage - (GD-Resource) If you want apply something that isn't available with that class, you simply can check out the current memory image and apply your image - voodoo - stuff ------------------------------------------------------------------- * setMemoryImage setMemoryImage($memoryImage) param: $memoryImage - (GD-Resource) return: pim - (class handle) If you are ready with your own image stuff, you can check in the memory image for further use with the class. ------------------------------------------------------------------- * watermarkLogo watermarkLogo($pngAlphaImage, $position='center', $padding=2) param: $pngAlphaImage - mixed [systemfilepath or PageImageObject] to/from a PNG with transparency param: $position - (string) is one out of: N, E, S, W, C, NE, SE, SW, NW, - or: north, east, south, west, center, northeast, southeast, southwest, northwest default is 'center' param: $padding - (integer) 0 - 25, default is 5, padding to the borders in percent of the images length! return: pim - (class handle) You can pass a transparent image with its filename or as a PageImage to the method. If the watermark is bigger than the destination-image, it gets shrinked to fit into the targetimage. If it is a small watermark image you can define the position of it: NW - N - NE | | | W - C - E | | | SW - S - SE The easiest and best way I have discovered to apply a big transparency watermark to an image is as follows: create a square transparent png image of e.g. 2000 x 2000 px, place your mark into the center with enough (percent) of space to the borders. You can see an example here! The $pngAlphaImage get centered and shrinked to fit into the memory image. No hassle with what width and / or height should I use?, how many space for the borders?, etc. ------------------------------------------------------------------- * watermarkLogoTiled watermarkLogoTiled($pngAlphaImage) param: $pngAlphaImage - mixed [systemfilepath or PageImageObject] to/from a PNG with transparency return: pim - (class handle) Here you have to pass a tile png with transparency (e.g. something between 150-300 px?) to your bigger images. It got repeated all over the memory image starting at the top left corner. ------------------------------------------------------------------- * watermarkText watermarkText($text, $size=10, $position='center', $padding=2, $opacity=50, $trueTypeFont=null) param: $text - (string) the text that you want to display on the image param: $size - (integer) 1 - 100, unit = points, good value seems to be around 10 to 15 param: $position - (string) is one out of: N, E, S, W, C, NE, SE, SW, NW, - or: north, east, south, west, center, northeast, southeast, southwest, northwest default is 'center' param: $padding - (integer) 0 - 25, default is 2, padding to the borders in percent of the images length! param: $opacity- (integer) 1 - 100, default is 50 param: $trueTypeFont - (string) systemfilepath to a TrueTypeFont, default is freesansbold.ttf (is GPL & comes with the module) return: pim - (class handle) Here you can display (dynamic) text with transparency over the memory image. You have to define your text, and optionally size, position, padding, opacity for it. And if you don't like the default font, freesansbold, you have to point to a TrueTypeFont-File of your choice. Please have a look to example output: http://processwire.com/talk/topic/4264-release-page-image-manipulator/page-2#entry41989 ------------------------------------------------------------------- PageImage Manipulator - Example Output

And this is my first draft for french. That was easy, well done Ryan, the interface for translations is very simple. ProcessWire-Language-French.zip

I found the parseTags() routine from Ryan's Login Notify plugin pretty useful in a couple of modules I wrote recently and will probably reuse it again in other modules. I thought others might find it useful too, especially if it were slightly more flexible in the setup of the context from which it pulled the values to use in its substitutions so I rewrote it as a Textformatter. Originally parseTags() would turn something like this... "Date: {datetime}\nUser: {name}\nIP: {REMOTE_ADDR}" …into something like this… Date: 12th September 2012, 14:45 User: ryan IP: 127.0.0.1 ...using a User as the context for the substitutions. This text formatter extends this to allow an array of WireData instances to be used as the context for substitutions and extends the tag format from simply {fieldname} to {context.fieldname} to allow substitutions from specific places. This could allow you to use data from, say, a User and a Page when parsing your string. Something more complex can then be parsed successfully; like this... Hello {user.name}, where have you been? It's {datetime} now and we haven't seen you in two weeks. Your last edit was on page '{page.name}' from address {REMOTE_ADDR} ...where the name field from both the supplied User and Page can be substituted into the text. It's entered in the modules directory here but most of the documentation is in the readme file on github. There is also a handy Process module that allows you to experiment with it from within the PW admin (thanks to Nik for the idea as it's based on his Test Selectors module.)

You've been using MODX but now you've found ProcessWire. It’s totally amazed you and you can’t wait to get started. But…you are wondering where everything is. If this is you, read on… This guide is primarily aimed at those who are coming in from MODX and wish to know how to accomplish “MODX things” the “ProcessWire (PW) way”. This is not meant to be a full blown PW tutorial. It will focus on some key MODX concepts/tasks and how to accomplish those in PW. It will cover, whenever possible, both versions of MODX - Evolution and Revolution. The guide assumes that you’ve at least logged into a PW site and/or viewed a demo. The Table of Contents mostly reflects MODX terminology. Table of Contents 1. Manager 2. File System 3. Resources 4. Templates 5. Template Variables (TVs) 6. Template Files 7. Snippets 8. Modules 9. Plugins 10. Chunks 11. Miscellaneous 12. Examples - the PW way… a. Template Variables b. Snippets c. Modules d. Plugins e. Chunks 1. Manager In PW, the “manager” is referred to as the “Admin”. The default location of the Admin is www.yoursite.com/processwire. As of PW 2.3, you can rename the Admin to anything you wish during install. Just be careful to remember the name you use or you will be locked out! (If that happens, there are ways to get around it though). Logging into Admin, you will notice a tree just like in MODX. The Admin runs on jQuery UI and as you’ve seen, it is insanely fast! Don’t be fooled by its simple facade. PW is a really powerful CMS, highly extensible and very easy to use. Customising the PW admin is very easy. There are a number of custom themes available. It is also trivial to make yours. Custom Admin themes go into the folder site/templates-admin/. You can have only one theme at a time. On a related matter, if you wish to create a custom Admin page, it is easy to do so. See this thread for more info. 2. File System After installing PW, you will see two main folders; “site” and “wire” in your file system. Site is where all things related to your site reside. This is your playground and will survive an upgrade. Wire houses the Core. You will never have to go into that folder. 3. Resources In MODX, Resources can be many things (documents, etc.). There is no such term in PW. However, the most important “resources” you need to know about in PW are page and pages. Pages are a very powerful concept in PW. Page can refer to your website’s frontend pages, i.e. what can be viewable by your website users. I say can be for a reason. There are many uses for Pages in PW. This can be confusing to newbies but once you get the concept, you will appreciate the power of the system. Just because something is a Page does not mean it has to be viewable. It can have other uses such as a container that holds data for use by other Pages - in this case the Pages do not have to be displayed on the frontend. In fact, everything you see on the PW tree is a Page. That’s right; even the Admin and its components (Users, Roles, etc.) are all Pages! Still confused by Pages? Have a read here. Pages reside in the PW tree - you may have noticed . You can drag and drop pages to move them around. If drag and drop doesn’t work you probably have MySQL 5.0.5.1 installed. Upgrade your MySQL and you are sorted. The root of your site is the uppermost Page in the tree. In the default PW install this is called Home. You can change the name to something else. The default PW install comes with a number of Pages pre-installed. Try editing a Page. All those Fields you see on that Page when under the “CONTENT” tab? They are not default Fields. They are all Custom Fields! Yes, not even the Title! The only required Field for a Page is “name”. You find this under the “SETTINGS” tab on the page edit screen. More about Fields below… Other related stuff: Menuindex: As an aside, if outputting something like a menu, unless you state otherwise, it will reflect the tree hierarchy. Show in Menu: This functionality is covered by the Page status, whether hidden or not. Hidden pages do not get output on menus (more about menus later) unless explicitly stated so using PW API selectors (see below). Menu Title: No such term in PW. You can name your menu items what you wish to name them. Very important: All Pages must be assigned a Template. 4. Templates In PW, Templates mean something slightly different compared to MODX and many other CMS. MODX describes templates as: That is not entirely true of PW Templates. In PW, the term Template is used in the sense of the English definition of the term: PW Templates serve as a pattern for the foundation of your Pages. By foundation, I do not mean the HTML or CSS. Rather, the Template servers as blueprint for your Pages. What is available to the Template is available to the Page that uses it. Templates establish a pattern for the Pages by the inclusion of Fields to the Template. A Template can have as many or as few Fields as you wish. You can create as many or as few Templates as you wish. You can easily change the Template a Page uses when editing the Page. See under SETTINGS. Note that if you have Fields on that Page that are not in the Template you are switching to, those Page Fields will be lost! PW will warn you about this when switching Templates though. OK, so how do you show “Resources to the world”? That will be the work of Template Files which we’ll look at in section 6. 5. Template Variables A powerful feature of MODX is Template Variables (TVs). If you loved MODX TVs you will absolutely adore the PW equivalent. In PW, TVs are known as Fields. You can define your own Custom Fields. In fact, you will need to create your own in most cases. This is because PW does not have any required Field except for “name”. It is perfectly reasonable to have a Page with only the name Field! Many people do add at least a Title Field for such Pages. In the default PW install, the reason you see the Title Field in all Templates is because it has been set as a “Global” Field under the ADVANCED settings of the Field (edit the Field to see this setting). There are many types of Fields to hold all sorts of data - images, texts, urls, passwords, reference to Pages, etc. You can call your Fields anything you wish. You can call the Field for your main content “body”, or “stuff”, or “content” or whatever you wish as long as you follow the naming convention, i.e. “[a-z], numbers [0-9], or underscores (no dashes or spaces)”. Fields are reusable across different Templates. The order in which they appear on your Page follows the order in which they are arranged on your Template. However, it is important to note that: The order in which Fields appear on your page and/or the inclusion of a Field on your Page does not mean that: The Field will be output on the Frontend. The inclusion of a Field on a Page does not automatically mean it will be output; PW does not make that decision for you. It only makes the Field available to you to use as you require. You can output all or none or few of the Fields on your Page. The order in which Fields appear on a Page does not mean the same order will be reflected when you output the Page. You make that decision. Also note that you are able to arrange Fields side-by-side on your Page (via settings on the Page’s Template) to mimic your site’s layout or for other visual/ease-of-use purposes as you edit the Page in the Admin. You can also give each Field a label and a description. These will appear above each Field when editing a Page. In most cases, the content of Fields will be saved directly to the database. In the case of file related Fields, the path to the file will be stored in the database. There are no direct equivalents of MODX TVs “@Bindings” (data sources). These are inherently built into the different types of Fields. Note that you cannot run PHP code within Fields (so no @Eval). This is by design. Fields are a very powerful and much loved concept in PW. Just Google "custom fields cms" and you’ll see what comes up tops. 6. Template Files So far, we've seen that you create Fields, add them to a Template you've created and edit a Page using that Template to input your content into that Page’s Fields. So far so good but how do you output the content to the world? You do this via Template Files. Template Files live in /site/templates/. You have to create your own Template Files. In MODX, a Template will have both system fields, e.g. body, title, etc. and custom fields (TVs). Rendering a Template is achieved by adding MODX tags to your Template. In PW, in order for the content of your Page to be seen by the world, its Template must have a Template File (or there must be some other Template File associated with a different Template that is dynamically pulling and outputting elsewhere the content of a Page whose Template does not have a Template File). This does not mean that all content within a Page will be automatically output by the Template File. No; in the Template File you can choose to render all or some Fields present in the Pages using that Template or none at all! You tell the Template about the associated Template File when you create/edit the Template. PW assumes that there is a Template File with the same name as the Template in /site/templates/ and will tell you if it does not find one. However, you have two other choices. You can either enter an alternative name for your Template File or tell PW you do not wish to have a Template File for that Template. This means that a Template does not require a Template File. Obviously, in such a case, you will not be able to directly output the content of the Pages using that Template. In some cases, that is exactly what you want . As you get to know more about the system, you will find out how powerful and flexible the PW Template system can be. For instance, you can use your Template as a controller. That’s beyond this guide but feel free to search the forums for more info. Template Files are typically PHP files with logic to dynamically output your content. In most cases, Template Files are HTML with PHP tags inserted to output your content. The PHP in the Template File will in most cases be PW API. Hence, you will see things like $page and $pages in Template Files. The former always refers to the current Page and the latter to any other Pages in the system. These are very powerful variables in PW and give you access to ALL information about ALL pages including their Fields and whether those are empty or not, etc. See below for more info about these variables and have a look the docs too. Note that Templates do not care about what’s in your Template Files. In fact, they won’t even check. All they want is for you to tell them if and how you wish your Pages' contents to be rendered. Your Template Files can even contain pure HTML (although that won’t be dynamic!)! Your Template Files can have references to other things related (or not related!) to the Page using that Template File. For instance, within your Template File, you can pull in the 10 latest “posts” from your Blog or the Children Pages of that Page. There are just too many possibilities to list them all here. Don’t let the PHP in Template Files scare you if you are no coder. I am no coder but I am able to use PW. You will only need to know at least some very basic PHP to use PW. The most important are: echo; foreach; and if… Anything else is a bonus in most cases. In addition, you will need to know how to use the two most important PW variables - $page and $pages. With these two, most of what you would have done in vanilla PHP is covered. They are easy to use and to understand and very much follow the jQuery concept. Check out the docs to learn more. 7. Snippets In MODX, Snippets are the method by which MODX allows you to run dynamic PHP code in any of your pages. In PW, the term Snippets does not exist. What!?! Not to worry; in PW MODX-like Snippet functionality can be achieved in two ways: Template Files: Most PW Template Files are essentially dynamic PHP code. That’s Snippets for you right there. PW Modules: PW Modules do what MODX Snippets do and more (see below). It’s just an issue of terminology. For instance, the popular MODX Snippet WayFinder has a Module counterpart in PW. This is the Module Markup Simple Navigation. However, you do not need to use the Module to create a menu in PW. You can do the same thing using PHP in your Template File. See the default PW install for a simple example. Check out section 12 of this guide for example “popular-MODX-Snippets-to-PW-how-tos”. 8. Modules MODX Evolution defines Modules as “a program that can only be executed from within the manager.” There are PW Modules that fit this definition, for instance, the Module Batcher which is equivalent to the MODX Revolution add-on Batcher. However, there are other PW Modules that are executed in the frontend, e.g. Markup Simple Navigation previously mentioned. In fact, in PW, a Module is PHP that extends the functionality of PW. Modules contain PHP classes that adhere to PW’s Module interface. 9. Plugins In MODX Plugins are PHP code that are set to execute during certain system events. In PW, although the term Plugin does not exist (except maybe in reference to Modules), MODX Plugin functionality is easily doable in PW. This is achieved via Hooks. There is one difference though. In MODX, Plugins are standalone code you can download and install. You cannot download and install PW Hooks. Instead, PW contains many methods that you may hook into in order to modify the behaviour of the method. In other words, PW offers the ability to hook into its processes/events and manipulate them before or after the event or even replace them, etc. Hooks are usually invoked inside Modules. However, Hooks may be attached from anywhere that you use PW's API, for instance in Template Files. The average PW user will not need to use Hooks. For more info about Hooks check the documentation. 10. Chunks MODX defines Chunks as “bits of static text which you can reuse across your site”. There is no equivalent term in PW. You can, however, easily create Chunks in PW. You can create Chunks as a Page that contains various Fields each of which can act as a Chunk. This means you can have Chunks of all sorts of data. You can then set the Page you create to hold your Chunks as hidden (not available to searches). The Page can also be assigned a Template without a Template File to further limit frontend access. It can also be created as a child/grandchild of the page Admin. That will limit access by User (e.g. login required to view it in Admin). Accessing the Fields of that Page as your Chunks using PW API is quite trivial really. Since you can use labels and descriptions to further define each of your Pages’ Fields, this makes it quite easy to describe what each Chunk is for and/or give instructions on how to use the Chunks. See this example for more info. You can also simply use text files to pull into your content as Chunks. Personally I prefer using Pages as Chunks when I need to. In MODX, it is usual for many Snippets to use Chunks (HTML + placeholders) to structure their output (i.e. tpl Chunks). You do not need to do this in PW. Code output can be wrapped in HTML right within the Template File. The important thing to remember is that any Field in any PW Page is available to any other Page and any Template File. Cross-referencing Fields and Pages is child’s play. Seriously; it is that easy. 11. Miscellaneous Tag Syntax: PW does not use a templating language (tagging syntax) like MODX does. See this article why this decision was taken. I agree 100% with the approach and have come to realise its many benefits over using a templating language. However, there are two Modules that allow you to use template language tags in PW. I have never used them so cannot comment further. They are here and here. Settings Page: PW has no settings page like MODX. Many settings are set in the /site/config.php. Other MODX settings equivalents are interspersed in various places including caching content on a Template by Template basis and in Modules. You can also store custom settings needed for your site in the /site/config.php. You can even use Pages to store your settings as mentioned in section 10 (Chunks). Modularity: PW is a very modular system. The whole of PW is made up of Modules (Core Modules) that accomplish different tasks. 12. Examples - the PW way… In this section I will show you equivalent MODX versus PW add-ons as well as how to accomplish various task using PW “Snippets” equivalent. a. Template Variables As previously mentioned, MODX TVs are PW Fields (although PW Fields are more versatile). Outputting the contents of your Fields is very simple. echo $page->name_of_your_field; This gives you the contents of the Field in the current page. Works slightly different for image fields though. For other pages echo: One page $pages->get(ID or PATH or NAME, etc.)->name_of_your_field; //note replace ID with ID of the Page you want, etc. Many pages $pages->find("selectors"); //this will return an array. You can then go through the array using foreach as shown in the examples below to output the field(s) contents MODX - output main content of Page //MODX Evolution[*content*] //MODX Revolution[[*content]] ProcessWire - output main content of Page //ProcessWire echo $page->content;//note; this assumes you have a Field called content in the Template of the current page. In ProcessWire you can find Fields of other pages like so $fruits = $pages->find("template=yumyum, limit=10"); foreach($fruits as $fruit) { echo "<li><a href='{$fruit->url}'>{$fruit->title}</a></li>"; } //find 10 Pages that use the Template yumyum and echo their url and titles in a list. From these examples, you can see the elegance and flexibility of TVs done the PW way. Since there is separation between a Template and a Template File, you can conditionally echo out the contents of Fields found in Pages. b. Snippets Common MODX Snippets and PW equivalent Modules 1. WayFinder: Markup Simple Navigation or code in Template File (see head.inc in default PW installation for a simple menu). 2. Ditto (Evolution) and getResources (Revolution): Functionality inbuilt in PW. Use $page and $pages variables + selectors to find anything, anywhere. 3. Jot (Evolution) and Quip (Revolution): Comments Module is part of the PW Core. It is not enabled by default. You will have to enable it in the Admin. See also the related Comments Manager Module. 4. eForm (Evolution) and FormIt and FormItBuilder (Revolution): There are various Form parser codes in the Forums. There is also a commercial Form Builder Module. It’s not expensive, is developed by PW’s lead developer and proceeds support the PW project. 5. MaxiGallery (Evolution) and Gallery (Revolution): Presently, there is no equivalent. However, it is quite easy to build a photo album. See this tutorial in the wiki. There is also an Images Manager Module (still in alpha though). 6. AjaxSearch: Ajax Page Search Module. 7. Breadcrumbs: Quite easy to accomplish using PW API. See default PW install for an example. 8. FirstChildRedirect: Very easy to do using PW API like this: $session->redirect($page->children->first()->url); in a Template File. 9. getField (Evolution) and getResourceField (Revolution): Inbuilt in PW $page and $pages variables as shown above. 10. GetParent: Inbuilt in PW $page and $pages variables. E.g. $page->parent. 11. getPage: PW has inbuilt pagination as part of the Core (Pagination Markup Module). See this article for a quick tutorial. 12. UltimateParent: Inbuilt in PW API as rootParent. 13. if (Revolution): Use vanilla PHP with PW variable and selectors in Template Files. 14. VersionX (Revolution): Versioning for text-based fields is coming in PW 2.4 (release date summer 2013). Support for maintaining separate draft and live versions coming in PW 2.5 (Winter 2013/2014). Currently, there is also the Module Version Control for Text Fields. 15. getRelated (Revolution): No out-of-the-box Module for this. Has been previously accomplished using PW API in various ways. Have a look in the forums. 16. importX (Revolution): Import Pages CSV Module. 17. phpThumbOf: Thumbnail functionality is inbuilt in PW. There is also the Module Thumbnails that further extends this functionality. 18. getValue and getValues (Revolution): Inbuilt in PW. You can get the value of any Page using PW API - $page and $pages. 19. getFeed (Revolution): RSS Feed Loader Module. 20. MIGX (Revolution): Repeater Module which is part of the PW Core. It is not installed by default. You will need to do that yourself. For more info see this tutorial. 21. Articles (Revolution): See the Blog Profile Module. 22. NewsPublisher (Revolution): See below under Plugins. Examples MODX Ditto [!Ditto? &parents=`5`&extenders=`summary` &tpl=`tplBlog` &orderBy=`createdon ASC`&display=`6` &truncText=`Continue Reading This Article` !] PW equivalent $items = $pages->get(5)->children("sort=date,limit=6"); foreach ($items as $item) { echo $item->title; echo $item->summary;//etc. } //this assumes you have a Field called summary on that Page The first line in the above gives you all information about the 6 child Pages of the Page with ID #5. It returns an array. In other words, a basket of various documents containing all the info about those documents. Next, you traverse the array using foreach. In layman terms, you rummage through the basket picking goodies! In order to wrap HTML around the code output, we do it like this instead (there’s other ways to do it as well!) echo "<ul class='articles'>"; foreach($pages->get(5)->children("sort=date,limit=6") as $item) { echo "<li><p><a href='{$item->url}'>{$item->title}</a><br /> <span class='summary'>{$item->summary}</span></p></li>"; } echo "</ul>"; In this example, we have asked PW to grab the child Pages directly within the foreach rather than creating a variable $items first. MODX getResources // Output a list of child Resources of the current Resource, using the 'myRowTpl' chunk: [[!getResources? &parents=`[[*id]]` &tpl=`myRowTpl`]] PW equivalent echo "<ul>"; foreach ($page->children as $child) { echo "<li><a href='{$child->url}'>{$child->title}</a></li>"; } echo "</ul>"; //You might want to limit the number of child Pages you are getting if they are many! MODX getResources // Output the top 5 latest published Resources beneath the Resource with ID '5', with tpl 'blogPost': [[!getResources? &parents=`5` &limit=`5` &tpl=`blogPost` &includeContent=`1`]] PW equivalent echo "<h3>Latest Posts</h3>"; $posts = $pages->get(5)->children("limit=5"); foreach ($posts as $post) { echo $post->body; } c. Modules 1. Batcher and Docmanager (Revolution): Batcher Module (covers most equivalent functions). 2. DocFinder (Evolution): Inbuilt in PW default install. d. Plugins 1. QuickManager (Evolution): Several Modules can do this, i.e., Fredi, Page Frontend Edit and Inline Editor Modules. 2. ManagerManager (Evolution): Same functionality can be achieved using Templates, Access Control and the Modules Page Edit Field Permission, Page Edit Per User and Page Edit Per Role. e. Chunks See this example. Btw, the PW Cheat Sheet is you best friend... Hope this has been helpful! /kongondo

I recently created a Dribbble API wrapper module (I am pretty new at creating modules) and wanted to know if its possible to use the $image API to retrieve the external Dribbble "shot" (image), resize it and store them along with the XML in the asset cache. That way I can load an image locally via the cached file(s) for the module instead of hitting Dribbble every time for the full size images. Any thoughts on how to best do this? Here is the current state of the module on Github: https://github.com/ryanscherler/ProcessDribbble

"north, northwest, center, etc" is perfect

Simply Love it. Great design, good typeface. (And, why customers don't update news sections...)

$templates = $event->return; ... since the method returns the templates

Yeah I like it better.

To delete pages you may use delete. http://cheatsheet.processwire.com/?filter=delete (must have been still in m clipboard ) $pages->delete($page, true); // recursive with children $pages->delete($page); $page->delete(); To get pages from the trash you would need include all $pa = $pages->find("parent=/trash/,include=all"); $pages->get() will give you only 1 page. http://cheatsheet.processwire.com/?filter=pages-%3Eget

"What I'm looking for is the topmost page right under an arbitrary page. "The top most parent page under page X". That sounds to me like you are looking for the first child of an arbitrary page - is that right?

This has never been the goal with selectors. I think we'd have an unusually complex selector system if it could entirely replace SQL. SQL is very powerful and–relative to it's power–probably as simple as it can be. So when needs come up that are more easily accomplished by SQL, that's the way to go. The goal with selectors is to remain simpler than SQL for the majority of cases, but not to replace everything you can do with SQL. No doubt we'll continue adding new options and capabilities to selectors in the future, but it's always got to be a balance in focusing on the things that will get the kind of usage and mileage that warrant their inclusion. If the sorting by date then reverse by time function that you mention comes up regular need for many people, then it may be worth adding at some point.

Horst, would you consider adding a resize mode that adds a colored or transparent padding instead of distorting the image? Something like this:

owzim, that's an old one, use the version of the module that is on github, and follow the instructions from there https://github.com/ocorreiododiogo/pw-admin-custom-pages I will remove that file from that post...

with a pageimage loaded into the {Pageimage} {Manipulator} you are not able to overwrite the original! You have to use the {Image} {Manipulator} manually with a filename. Here you can do everything you want, - or the opposite: you alone are fully responsible for _all_ actions, ;-) $pim = $wire->modules->get('PageImageManipulator')->imLoad($imageFilename, $options); // here it is used imLoad = image manipulator instead of page image manipulator If you do not specify an alternate filename or outputFormat with the options array, the sourcefile loaded into the IM is overwritten by default! Note: if you overwrite your original image, you wipe out all EXIF-data, whereas all IPTC-data is kept! ------------- Hey Soma, it looks like you are building a visual Photo-Editor based on PW. cool!

lol, maybe you installed FieldsetSchrink.module to. That little module removes the padding border and margin from a fieldset. And you only see that it sepeates the fields, you're not seeing the fiedset. (ps, the more dummy you are the more you discover)

Hi Ryan, Could I make a humble feature request for ServicePages? I'd like it to support subfields in the queries. For example, I have a template called program that has a PageReference field named regions. Then, I have a template called regions that has a field called code. I made sure that both templates and the fields involved were allowed in the ServicePages config screen. I'd like to use a selector like this (which works in Batcher and Selector Test modules): template=program,regions.code=35,title|body*=Export which in the URL would be: ?template=program&title%7Cbody*=Export&regions.code=35&debug=1 But I'm getting the error: "Field 'regions_code' is not allowed in queries" It works fine, of course, if I substitute regions.code for regions=124 (where 124 is the id of the Regions page that has a code value of 35). It seems like the field sanitizer is renaming regions.code to regions_code instead of sanitizing both the parent and child fields to make sure they're both allowed in queries. I'm using Page references for all kinds of metadata, so to efficiently use ServicePages, it would nice not to have to rely on knowing the child page's ID. I could see this being used as 'parent_field'.title quite often. I guess having "." in a URL parameter name might be problematic - maybe we'd have to use ":" instead? Thanks for a great module! -Brent

I was being nice - the man behind the counter even said he thought I was very nice as he dialed the police.

People please, be nice

Hi Matthew, Soma & others Sorry to be that unclear and a half day to late with this post. I gonna try to explain the Fieldtype again, I was not clear enough. ( Explaining things is always difficult and even more when it's not in your native language ) I gave the fieldtype an other name: Fieldtype Import Pages. As it describes better what it should do. --- @MatthewSchenker, most things can handled easily from api. But the context (where to handle data) is very important. If you give an editor a page to edit*** and they can handle all the data there, then there's no confusion. In MODX evolution galleries are created from the front-end of the website not the back-end. As a result: Customers calling that they can't edit galleries, you explain where to do it and a year later, the same customer is calling again with the same question. *** example: /processwire/page/edit/?id=1047 --------------------------------------------------------------------------------------------------- Fieldtype Import Pages (Handeling Page imports) The settings for inputfields using this fieldtype make things more clear I hope: --- What should the Fieldtype do? import pages to a parent. (handeling page imports)What data should be saved to the current $page? No data, it should create pages under a parent page.What a "Fieldtype Import Pages" Fieldtype needs from it Inputfield: page array (pages to store) and a parent. What is the required output ( $page->name_of_the_field ) of the Inputfield using this Fieldtype: nothing, ( the Imported pages are the things you querie from template/api level )What output is possible for a Inputfield ( $page->name_of_the_field ) using this Fieldtype: whatever the developer wants to output. ( depending on the saved pages.)--- An Inputfield example: Inputfield querying the latests tweets containing the hash tag #processwire and creating a list of it. In the inputfield select the tweets you want to import to a parent. On saveReady*** , create a Pagearray of tweet pages. Then the Fieldtype kicks in and saves the tweets in the parent. *** (or what ever state it is possible to create a pagearray before the Fieldtype kicks in ) --- Other Inputfield example An inputfield using Wanze & Kongondo'z handsonetable creates a Pagearray and the Fieldtype wil store the pages.

Greetings, Renobird: I agree. However, I still have several legacy Joomla projects where I am getting clients to make the move to ProcessWire. The number is dropping, but there are enough of them to keep reminding myself of how Joomla pales in comparison. Which brings me to another major praise for ProcessWire: it is easier to re-make a site from scratch with ProcessWire than it is just to maintain a Joomla site with all its plugins and modules and conflicting Mootools messes. Soon, these legacy contracts will come to an end, and they will all have to be on ProcessWire! Thanks, Matthew

One of the best compliments I can give ProcessWire/Ryan (and all the other amazing contributors) is that I no longer think about CMSs. I just think about making things - knowing that whatever I come up with will be possible with ProcessWire. Can ProcessWire do (x)? Yes, in several devastatingly simple ways. Everything else feels like a kludge when compared.

Noticed that on a test install the other day and just assumed I had messed something up. I gave up and switched it to tinyMCE. Glad you found that, I really like CKEditor. Thanks.

I've been really enjoying using Bohemian Coding's Sketch app for the past couple of months and recently I noticed their official user manual for Sketch is powered by ProcessWire! How cool is that?! http://www.bohemiancoding.com/sketch/help/

When I get a new VPS or dedicated server (usually from ServInt) the first things I ask them to do are: Upgrade PHP to the latest version available (preferably 5.4+). Install an opcode cache like APC (except for PHP 5.5, which apparently has one built in). Make sure that PDO is enabled (some ServInt default configs don't have it for some reason). I also usually make two tweaks to the php.in file: Bump up the memory_limit to 128M or 256M. Not technically necessary, but nice when you need to import or manipulate a lot of data or deal with large photos. Bump up the upload_max_filesize and post_max_size to a number at least as large as the largest files I'll be uploading (usually 100M).

Glad you found that one Ryan. It was real mystery to me. Kind of bug in ckeditor though to allow that kind of config...?

RewriteCond %{HTTP_HOST} ^www\.(.*)$ [NC] RewriteRule ^(.*)$ http://%1/$1 [R=301,L] Just for the record, you might want to consider the benefits of using www-subdomain before doing this, though.

Nghi, welcome to PW and the forums Maybe use the "custom selector" right below the template selection field instead? I am assuming you are aware that template setting is optional

PageImage Manipulator - Tips & Examples * how to create a PNG with transparency for the watermarkLogo method If you can use adobe photoshop, you simply may download and install this action: photoshop_action_PW-png-creations.zip create an empty image (transparent, not white or black) of 2000 x 2000 pixel write / paste your text and / or logo in a single color, (e.g. black) when finished with your text you should have one single layer with text on transparent background then click the action PW-png-creations -> 2000px-square-to-smooth and you are done. Hhm, maybe before saving you want to tweak the global transparency of the image a bit. That one used in the ProcessWire example was set to 75% instead of 100%. Just try out what looks best for you. ------------------------------------------------------------------- * did you know that you can save to different file formats, regardless of source format? You only have to specify your desired format (gif, jpg, png) with the optionally options array with a key named outputFormat and pass it with your call to pimLoad() or use setOptions() before any other action-method: // assuming the first image is a jpeg $img = $page->images->first(); // define outputFormat $options = array('outputFormat'=>'png'); // apply it together with other actions $myPng = $img->pimLoad('myPrefix')->setOptions($options)->width(240)->pimSave(); //------------------------------------------------------------------------------------------ // you may also do it as a OneLiner only with the image format conversion $myPng = $page->images->eq(0)->pimLoad('myPrefix', array('outputFormat'=>'png'))->pimSave(); // or you can use the setOutputFormat method $myPng = $page->images->first()->pimLoad('myPrefix')->setOutputFormat('png')->pimSave(); ------------------------------------------------------------------- * (how) can I use the ImageManipulator with other imagefiles than PW-Pageimages? You can load any imagefile from your servers filesystem into the ImageManipulator with: $pim = wire('modules')->get('PageImageManipulator')->imLoad($imageFilename); // or $pim = $wire->modules->get('PageImageManipulator')->imLoad($imageFilename, $options); You can directly with the imLoad-method pass specific $options or you can do a separate call to setOptions(). Then you do your desired actions and last but not least you call save()! Most time I think the original passed file gets overwritten with the manipulation result, but you are also able to save to a different name and / or fileformat. If so, it is useful to get the final (sanitized) filename back after saveing. $optionalNewFilename = $pim->setOptions($options)->height(360)->flip()->blur()->save(); Also you may call this in one line if you prefer: if(false!==$wire->modules->get('PageImageManipulator')->imLoad($imageFilename,$options)->height(360)->flip()->blur()->save()) { // success !! } ------------------------------------------------------------------- * how can I use the PageImageManipulator with my own module/s? If you build a module that do some image manipulation you can define the PIM as needed dependency in your ModulesInfo method with the key 'requires'. You may also force to install the PIM if it isn't already with the key 'installs': public static function getModuleInfo() { return array( // ... 'requires' => array('PageImageManipulator'), 'installs' => 'PageImageManipulator', // ... ); } detailed infos are here: http://processwire.com/talk/topic/778-module-dependencies/ additionally, if you need to check if a module dependency has a minimum version number, you can do it in your install method like this: public function ___install() { // check that at least the minimum version number is installed $needed = '0.0.3'; $a = wire('modules')->get('PageImageManipulator')->getModuleInfo(); $actual = preg_replace('/(\d)(?=\d)/', '$1.', str_pad("{$a['version']}", 3, "0", STR_PAD_LEFT)); if(version_compare($actual, $needed, '<')) { throw new WireException(sprintf($this->_(__CLASS__ . " requires PageImageManipulator %s or newer. Please update."), $needed)); return; } // ... more code } ------------------------------------------------------------------- * global options in site/config.php You can create a config-array in your site/config.php. If you look into it you will find a config array for the ImageSizer that comes with the PW core $config->imageSizerOptions = array( 'autoRotation' => true, 'sharpening' => 'soft', 'upscaling' => true, 'cropping' => true, 'quality' => 90 ); You can define another array with these keys: $config->imageManipulatorOptions = array( 'autoRotation' => true, 'sharpening' => 'soft', 'upscaling' => false, 'cropping' => true, 'quality' => 90, 'bgcolor' => array(255,255,255,0), ); You don't have to specify all of the options. PiM reads the imageSizerOptions and merge them with the imageManipulatorOptions. So if you want to have different values you can specify them in imageManipulatorOptions to override those from imageSizerOptions. Only one option isn't present with the imageSizer: bgcolor. This is only used by the imageManipulator. ------------------------------------------------------------------- * using PiM together with the awesome Thumbnails Module (http://mods.pw/1b) If you use the Thumbnails Module together with PiM, you can set two options in the site/config.php under imageManipulatorOptions: $config->imageManipulatorOptions = array( // ... 'thumbnailColorizeCustom' => array(40,-35,0), 'thumbnailCoordsPermanent' => true ); For the colorize dropdown select you can define the custom color here and with the second param you enable/disable permanent storage of RectangleCoords and params. The coords and params are stored with Thumbnails Module per session, but are lost after the session is closed. If you enable permanent storage these data is written into a custom IPTC field of the original imagefile. ------------------------------------------------------------------- * some more examples will folow here . . . -------------------------------------------------------------------

Yes, I think that a lot of modules currently in the core should be removed from the core. But we can't just remove modules from the core because that could break someone's site during an upgrade. So it has to be part of a longer plan that involves a custom-download packager (enabling one to download PW with user-chosen modules included), and tied to a major version where users would be expecting something more to an upgrade process. I actually think CKEditor's download packager is a pretty good example of what would work well for us. You can browse their plugin directory and click "add to cart" (or something like that) to add any given plugin to your CKEditor download. Then when you "checkout", you are downloading a CKEditor ZIP with all the plugins you wanted, ready-to-go.