Leaderboard

ProcessWire 3.0.180 contains 20 commits containing various minor new features, issue resolutions and pull requests. While there's no single major feature to write a big blog post around, combined there are a lot of worthwhile and useful updates so this version is definitely worth updating to. More details can be found in the dev branch commit log and at ProcessWire Weekly (issue #370 covered an addition to our $files API var). Yesterday the forums were running a little slow because we had our yearly DDOS’er pay the site a visit once again (remember last time?), and from an apparently unlimited supply of IP addresses around the world this time. We shut down the forums to users that weren't logged in while the load was high. Actually, it does this automatically now. We also updated the forums from using memcached to AWS Redis, which should also help as a nice upgrade for the forums. Big thanks to @Pete and @Jan V. for setting it up and keeping everything running smoothly. I'll keep it short today because it's supposed to rain here all weekend, so I'm going to spend some time outside while I can. Thanks for reading and have a great weekend!

Probably the easiest method would be having their clients each with their own page, and each report is it's own child page. One template for the client pages and one template for the pdf pages. You can add the necessary fields to the pdf template to facilitate searching. Personally, I shy away from building intelligence into a naming conventions. You might have your client person(s) doing the uploading select the client then select the pdf file, and enter any other necessary data associated with that report. If your client already has a data system from which the reports are generated at a specific interval, then you might tap into that workflow. You might also consider using the created user ids for access control. Your client has clients (customers). Each customer would be a user in the system. That customer user id is used for their page and subsequent report page. Now you can use the logged in user to determine which pages are accessible. Just some thoughts out loud.

Hi there, I'm starting a small series of tutorials here. The first one(s) deal with the topic "How can I add a watermark to all pageimages of a site?" first episode "Tutorial how to add a site wide optional watermarking method to all pageimages" second episode "Second Episode: "How can I add a watermark to all pageimages of a site?"" This is targeted to all, - beginners, intermediate, pros, - but mainly to interested PW lovers. The fictitious starting situation could be that a website owner has been creating beautiful photos for many years and would like to show them on his site in higher output sizes. A reference to real people or events does not exist, or would be "purely coincidental". Could someone please tell @Rob(AU) about this. ? This first episode shows a really straight and forward solution that could be an answer to the question "How can I get things be done?". We will create a PHP function that will give back a watermarked variation of every pageimage we put into it. We don't want bother our self to much with coding or image manipulation stuff. So for this first example we will setup our site with a single centralized image field that can contain one PNG image that should be used as our alpha transparency overlay for all watermarked image variations. Additionally to that, we install a PW third party module that does the image manipulation stuff. I will use the Page Image Manipulation module for this, because I know it very well. There are also *other good solutions in the PW ecosystem and if you would like you can add and use every existing PHP library that can assist you, or write your own individual low level code for that. But that's not our topic here. We want to get things done. Lets start! 1) Create a single centralized image field somewhere on a settings page if you have one. If your site doesn't has one, because you haven't had a need for that til now, the homepage may be a good place too. If you go with the homepage, but for other situations too, it may be a good idea to separate the overlay image input field from other content you have on that page. 1.1) Create an image field that should contain one file, and only of type PNG 1.2) Create a fieldset tab 1.3) Add both to the template of your choice 2) Add the Page Image Manipulator module to your site ... 2.1) ... by going to your modules section in the admin, select the tab "New" and add the Modules Classname under "Add Module From Directory": PageImageManipulator 2.2) Download and install it. 2.3) Go to the modules site tab and scroll down to the position where you find the entries for a Pageimage Manipulator 1 and a Pageimage Manipulator 2. There you can savely uninstall the legacy version 1 that is only needed for PW version prior to 2.6. 3) Provide a PNG overlay image. For this example we want use a 2000 x 2000 px transparent PNG image with our watermark sign or watermark text. If you don't have one ready but have an image manipulation program on your local machine at hand that excepts photoshop actions, you can download one here for fast creation: photoshop_action_PW-png-creations.zip 3.1) Create a new image 2000px x 2000px with a transparent background 3.2) Add some meaningful text at a position you like. If you want to use the PS action, don't forget to rasterize all vector text before starting it. 3.3) Regardless if you used the PS action or created some nice overlay in another way, you should set the opacity of the final image to something between 20 and 40 percent. You may have to test this out for a production version. But now we want to get things done. Save the final version and ... 3.4) Upload it into the centralized image field in your site! 4) Create a PHP function that encapsulates the watermark overlay process and outputs a finished pageimage as a variation. To get a go here without messing up our site, we can create a test.php file as sibling of PWs index.php. We will *boostrap PW there and get full access to the API site this way: <?php namespace ProcessWire; include __DIR__ . '/index.php'; function ourWatermarkTestfunction(Pageimage $image) { return $watermarkedImage; } Let the file operating in the PW namespace, boostrap the PW API and our barebone function. We want to pass in a pageimage and we want to get out a pageimage that is a watermarked variation of the source pageimage. If we want to test what we have so far, we would fetch us an image from a page we know it has one and pass it into the function: <?php namespace ProcessWire; include __DIR__ . '/index.php'; function ourWatermarkTestfunction(Pageimage $originalImage) { $watermarkedImage = $originalImage; return $watermarkedImage; } $image = $pages->get('[your selector here to a well known page that has an images field called images]')->images->first(); $variation = ourWatermarkTestfunction($image); $variation = $variation->width(800); echo "<img src='{$variation->url}' alt='{$variation->description}' />"; We tweaked our function to pass us the input image as output. And we echo out it as a HTML image. If this is working as expected, we can start to do code the main part of our function. We will use the module Pageimage Manipulator for that and referring to its description page, when we scroll down to the method called watermarkLogo, it tells us how we can use it. watermarkLogo($pngAlphaImage, $position='center', $padding=2) It want to have one mandatory param, the transparent PNG overlay image. Optionally it can take params for positioning the overlay. For our test we will use the defaults and as they are optional arguments, we don't need to call them. Referring to the PIM2 API, we have to start the process by calling pim2Load($prefix, $param2=optional, $param3=optional) And at the end we have to call pimSave() Putting this together we will get this: function ourWatermarkTestfunction(Pageimage $originalImage) { $watermarkedImage = $originalImage->pim2Load('wm')->watermarkLogo($pngAlphaImage)->pimSave(); return $watermarkedImage; } So, this will produce an error as we have not specified what $pngAlphaImage is. It should be our site wide overlay image that we have stored at a well known place, for example on our homepage. Also we want to apply a check if we really get a Pageimage from there, to avoid unhandled errors if for whatever reason the image gets deleted by accident at some time in the future. function ourWatermarkTestfunction(Pageimage $originalImage) { // get the field of the transparent watermark overlay image in a robust way, // regardless if it is set to 1 image or multiple images, and if it gets changed or not in the future $watermarkImages = wire()->pages->get('id=1')->getUnformatted('setting_watermark'); if(!$watermarkImages) { // return the unmodified original image to do not break our front end site return $originalImage; } // check if it at least contain one image, than fetch it if(0 == count($watermarkImages)) { // return the unmodified original image to do not break our front end site return $originalImage; } $pngAlphaImage = $watermarkImages->first(); // is the same as wire()->pages->get('id=1')->getUnformatted('setting_watermark')->first() // now let the module process our watermarking and save it into a variation $watermarkedImage = $originalImage->pim2Load('wm')->watermarkLogo($pngAlphaImage)->pimSave(); // return the watermarked variation return $watermarkedImage; } Lets have a visually check if all went well: $image = $pages->get('[your selector here to a well known page that has an images field called images]')->images->first(); $variation = ourWatermarkTestfunction($image); $variation = $variation->width(800); ?> <img src='<?=$variation->url?>' alt='<?=$variation->description?>' /> Now we should see our watermarked variation in the same dimensions as the original is. That's fine and it's time to leave the test and implement that into our custom site API. We will add a hook to the Pageimage object that we want call 'wm' and that does exactly what we have created here. 5) Open your site/ready.php and add the following hook into it: <?php namespace ProcessWire; $this->addHook('Pageimage::wm', function(HookEvent $event) { }); Now we can call on every Pageimage the new method wm: $image->wm->width(500) to get a watermarked and 500px width resized variation out. Ok, first we have to add our functions body into it. And we slightly have to change it a bit, because now it became a anonymous function of a HookEvent. Therefore it has not a own name anymore, and the input is not a Pageimage in the first time, but a HookEvent. (But in the end, it is a Pageimage, because it is a hooked event of a Pageimage. ?) /** * Example Pageimage Hook for watermarking functionality, * adds a new method to Pageimage objetcs named wm. * Used in a small tutorial series in the ProcessWire forums * https://processwire.com/talk/topic/25752-tutorial-how-to-add-a-site-wide-optional-watermarking-method-to-all-pageimages/ * * @version 0.0.1 * * @var HookEvent */ $this->addHook('Pageimage::wm', function(HookEvent $event) { // get the image out of the event object $originalImage = $event->object; // access the field of the transparent watermark overlay image in a robust way, // regardless if it is set to 1 image or multiple images, and if it has changed // in this regard since we wrote this hook function $watermarkImages = wire()->pages->get('id=1')->getUnformatted('setting_watermark'); // check if the imagefield exists and it at least contain one image, than fetch it if(!$watermarkImages || 0 == count($watermarkImages)) { // return the unmodified original image to do not break our front end site $event->return = $originalImage; // inform the admin about the missing watermark overlay, (or do something other useful) wireMail('admin@example.com', 'noreply@example.com', 'MISSING SITEWIDE WATERMARK OVERLAY IMAGE'); wireLog('errors', 'MISSING SITEWIDE WATERMARK OVERLAY IMAGE'); // stop further execution return; } $pngAlphaImage = $watermarkImages->first(); // is the same as wire()->pages->get('id=1')->getUnformatted('setting_watermark')->first() // now let the module process our watermarking and save it into a variation $watermarkedImage = $originalImage->pim2Load('wm')->watermarkLogo($pngAlphaImage)->pimSave(); // to return the watermarked variation, // we have to replace the event object with our watermark variation $event->return = $watermarkedImage; }); Now we can call our watermarked images like this: $image = $page->images->first(); $variation = $image->wm()->width(800); ?> <img src='<?=$variation->url?>' alt='<?=$variation->description?>' /> Now all looks fine in the first line. But there is some room for improvements also in this basic "get the things done" solution. I keep this for one of the next episodes, where we can dive a little bit into image debugging and / or create a more advanced version of the image watermarking function, maybe as a PW module. Thanks for reading! ? TL;DR *pageimage https://processwire.com/api/ref/pageimage/ *boostrap https://processwire.com/docs/front-end/include/ *image modules https://processwire.com/modules/category/photo-video/ *hooks https://processwire.com/docs/modules/hooks/ *hook event__https://processwire.com/api/ref/hook-event/

Hi there! I'm very new to ProcessWire, just found the system about a month ago and have been toying around with it a bit, and I'm loving everything I'm seeing! I'm coming over from the Concrete5 CMS, which I've been working with for 10 years, and one of the primary things that's so alluring to me about this CMS / Framework is that it doesn't try to get in your way. It seems like it's very much built with the mentality of providing the tools to build what you need, rather than forcing you to work around systems built for a specific purpose, and along with that, it seems like the community is incredibly helpful and friendly, which is always a big plus! One of the concepts that I'm used to from Concrete5 is the concept of Single Pages - one-off pages that are made for a specific purpose, and all of its code is self-contained, rather than part of a reusable templates. I am currently building a system that somewhat resembles an LMS - essentially needing Students, Student Records, quizzes / tests, and answers to them for each student record. The perfect example for my case is a user dashboard, to be able to view current tasks, know where to go next, etc. which won't be re-used anywhere else except on one page. From what I'm seeing with ProcessWire, it seems the base concept is that if you want a page to display on the front end of the site, it needs a .php template in the /site/templates/ directory, and even if the template is used in multiple pages, or only one, it makes no difference, and this is where it would / should go. Am I correct in this thinking? I want to make sure that as I learn ProcessWire, I get used to the standards and best practices that people have come up with, and I'm sure there's an answer to this somewhere already that I possibly overlooked, but I wasn't able to find it. Any insight on this would be much appreciated! Thanks!

I regularly use the ImportPagesCSV module and upload around 3-5 files each week. Right now none of these files exists anymore in the filesystem. Therefore I looked into the module and it uses $files->unlink() Here is a link to that line via Github: https://github.com/ryancramerdesign/ImportPagesCSV/blob/93fa3f1110be5b51b50c5f903d1d182a20565b26/ImportPagesCSV.module#L441 Maybe that helps a bit.

This does work! I'm sorry for the clearly amateur question! Thanks!

No, the layout did not include the ProcessWire namespace. I will try that. The version is 0.20.2 The namespace solved it. Was pretty sure i tested that, but must have missed it. Thanks Teppo!

That's a strange one. A couple of checks first: Does your layout file include the ProcessWire namespace? If not, you'd have to call it via \ProcessWire\Wireframe (though adding namespace is always a good idea). Which version of Wireframe do you have installed?

Given how simple FieldtypeRuntimeOnly is, it might be good to avoid the dependency in your module and just render your own markup directly. I haven't looked closely at your module but it just seems like it would make sense to keep it self-contained and avoid any fragility due to the chance that FieldtypeRuntimeOnly changes in the future.

I can't reproduce that. It's showing collapsed => 4 when I dump the field in a FieldtypeRuntimeOnly render file. This module doesn't do anything regarding inputfield visibility so I think your issue must be a general one relating to the PW API rather than specific to this module. Really all this module is doing is rendering a TemplateFile via $files->render(). One thing though... take note of the readme regarding the variables supplied to the render file: I don't know if it relates to your issue but I suggest you avoid overwriting the $field variable by choosing a different name for the field you are getting.

This works?? $data = $event->arguments(0);

Excellent, thank you @bernhard! That was exactly what I needed. I’m glad I didn’t have to manually like them to files imported in bulk with filesManager->importFiles().

This peace of software is impressive to me. Just want to share: Althttpd is a simple webserver that has run the https://sqlite.org/ website since 2004. Althttpd strives for simplicity, security, and low resource usage. As of 2018, the althttpd instance for sqlite.org answers about 500,000 HTTP requests per day (about 5 or 6 per second) delivering about 50GB of content per day (about 4.6 megabits/second) on a $40/month Linode. The load average on this machine normally stays around 0.1 or 0.2. About 19% of the HTTP requests are CGI to various Fossil source-code repositories. ... https://sqlite.org/althttpd/doc/trunk/althttpd.md The complete source code for althttpd is contained within a single C-code file with no dependences outside of the standard C library.

Interesting concept and super low power. I've always liked low power installs - I used to run our book warehouse pick-n-pack system from a android tablet wirelessly connected to a Raspberry Pi server running our warehouse software. There was a thermal label printer too, and all offset by the solar array on our roof - but nothing as teensy as the power budget of the system you linked to.

The suckless-philosophy... ❤️

RF3 got a very nice little update today ? Aggregations Often we need to calculate sums or averages of table data quickly and efficiently. RockFinder3 makes that easy as well: $avg = $rockfinder->find("template=cat") ->addColumn('weight') ->getObject("SELECT AVG(weight)"); db($avg); $cats = $rockfinder ->find("template=cat") ->addColumns(['title', 'weight']); $cats->dump(); // dump finder data to tracy $obj = $cats->getObject("SELECT SUM(`weight`) AS `total`, COUNT(`id`) AS `cats`, SUM(`weight`)/COUNT(`id`) AS `avg`"); db($obj); // dump result of aggregation What happens behind the scenes is that RockFinder3 gets the current SQL query of the finder and adds that as FROM (...sql...) AS tmp to the query that you provide for aggregation. This is the resulting SQL query of the example above: SELECT SUM(`weight`) AS `total`, COUNT(`id`) AS `cats`, SUM(`weight`)/COUNT(`id`) AS `avg` FROM ( SELECT `pages`.`id` AS `id`, `_field_title_605cab16f38ce`.`data` AS `title`, `_field_weight_605cab16f3993`.`data` AS `weight` FROM `pages` LEFT JOIN `field_title` AS `_field_title_605cab16f38ce` ON `_field_title_605cab16f38ce`.`pages_id` = `pages`.`id` LEFT JOIN `field_weight` AS `_field_weight_605cab16f3993` ON `_field_weight_605cab16f3993`.`pages_id` = `pages`.`id` WHERE (pages.templates_id=44) AND (pages.status<1024) GROUP BY pages.id ) AS tmp You can even provide a suffix for your query to do things like GROUP BY etc: $rf = $rockfinder->find("template=cat|dog"); $rf->addColumns(['created']); $rf->dump(); db($rf->getObjects( "SELECT COUNT(id) AS `count`, DATE_FORMAT(created, '%Y-%m-%d') AS `date`", "GROUP BY DATE_FORMAT(created, '%Y-%m-%d')" ));

Hi there, the idea of this module was born from the need to integrate FB API to bypass the block of reading data after the IOS14 update. FB tells us that in order to continue reading the data we have to send it via the API Convention. I wanted to publish this module finished, but I can't figure out how to do this. :( I don't know if anyone is willing to help me understand how to solve my problems. I'm trying to create a module with the Facebook SDK to send info via API. I attach here what I have done, at the moment, it is all very simple and rough. facebookSDK.zip At the moment the module works only as a link to the SDK folder and can be used to enter the credentials of the token and pixal via two variables. What I would like to do is to leave all the request to the SDK, in order to keep only the creation of objects in the page. Since the use cases are so many, I thought the best solution is to delegate to the module the connection with the SDK and keep in the page the creation of objects to be customized. Basically for the Convention API you need to make these objects UserData CustomData Event For let this module works fine, at moment, I have to add in to the page also the call to the SDK. So, in my page I have $fbSDK = $modules->get('facebookSDK'); use FacebookAds\Api; use FacebookAds\Logger\CurlLogger; use FacebookAds\Object\ServerSide\Content; use FacebookAds\Object\ServerSide\CustomData; use FacebookAds\Object\ServerSide\DeliveryCategory; use FacebookAds\Object\ServerSide\Event; use FacebookAds\Object\ServerSide\EventRequest; use FacebookAds\Object\ServerSide\Gender; use FacebookAds\Object\ServerSide\UserData; // Configuration this all $time = time(); if (isset($_COOKIE['_fbc'])) {$fb_fbc = $_COOKIE['_fbc'];} // This data is always better to have if (isset($_COOKIE['_fbp'])) {$fb_fbp = $_COOKIE['_fbp'];} // This data is always better to have $access_token = $fbSDK->accessToken(); $pixel_id = $fbSDK->pixelId(); // Initialize Api::init(null, null, $access_token); $api = Api::instance(); $api->setLogger(new CurlLogger()); $events = array(); // Specific data only if need in the object $hashEmail = hash('sha256', $user->email); // some data need to be hashed with SHA256 and UTF-8 encoding $user_data_0 = (new UserData()) ->setEmail($hashEmail) ->setClientIpAddress($_SERVER['REMOTE_ADDR']) ->setClientUserAgent($_SERVER['HTTP_USER_AGENT']) ->setFbc($fb_fbc) ->setFbp($fb_fbp); $custom_data_0 = (new CustomData()) // all these data are optional, I only include them as an example ->setValue(str_replace(",", ".", $page->pad_price)) ->setCurrency("EUR") ->setContentName("API test") ->setContentIds($skuAPI_json) ->setContentType("product_group") ->setCustomProperties(array("product_catalog_id" => "111111111")); $event_0 = (new Event()) ->setEventName("ViewContent") ->setEventTime($time) ->setUserData($user_data_0) ->setCustomData($custom_data_0) ->setActionSource("website") ->setEventSourceUrl($page->url(true)); array_push($events, $event_0); $request = (new EventRequest($pixel_id)) ->setEvents($events); $request->execute(); I would like to bring all this part into the module: use FacebookAds\Api; use FacebookAds\Logger\CurlLogger; use FacebookAds\Object\ServerSide\Content; use FacebookAds\Object\ServerSide\CustomData; use FacebookAds\Object\ServerSide\DeliveryCategory; use FacebookAds\Object\ServerSide\Event; use FacebookAds\Object\ServerSide\EventRequest; use FacebookAds\Object\ServerSide\Gender; use FacebookAds\Object\ServerSide\UserData; // Configuration. if (isset($_COOKIE['_fbc'])) {$fb_fbc = $_COOKIE['_fbc'];} if (isset($_COOKIE['_fbp'])) {$fb_fbp = $_COOKIE['_fbp'];} $access_token = $fbSDK->accessToken(); $pixel_id = $fbSDK->pixelId(); // Initialize Api::init(null, null, $access_token); $api = Api::instance(); $api->setLogger(new CurlLogger()); While keeping everything else on the page, so that it is customizable according to the needs of the moment.

wire('log')->save("shopify", "collections = " . print_r($collections, true)); You missed the second parameter of print_r which instructs to use the return value rathern than echoing. http://php.net/manual/de/function.print-r.php

A stock PW3 installation should actually be faster than PW2 – it certainly is on all of my installations. There's a lot more optimization in PW3 than in PW2. If that's not what you are seeing, then it's time to start looking for where the bottleneck is. PW3 does not have more significant overhead than PW2 except when it is compiling a file for the first time. The 30% increase numbers mentioned above sound to me like that is a request where PW is compiling a file. You can expect a request where it has to re-compile a file to take longer. But it only has to do that once, when a file changes and needs to be re-compiled. Maybe that's a common occurrence on a dev site, but should be a rare one on a production site. I'm measuring here with Chrome dev tools, ProfilerPro and my own timers using the Debug class. What tool are you guys using to measure times, and in what quantity? Before deciding something is PW3 related, I really suggest testing with a basic/blank profile without other modules installed. If you are consistently seeing any kind of increase in render times under PW3, my guess would be that something is getting recompiled on every request for some reason or another, or that there is another module involved that runs slower under PW3 for some reason. Edit--A few things to add: Debug mode is going to be slower in PW3 than in PW2, simply because PW3 is tracking a lot more stuff than PW2 did. With debug mode off there should be no difference though. Keep in mind debug mode is for development, and not something you should ever leave enabled on a production site. PW3 is more efficient with resources than PW2. PW3's boot time (stuff it does before executing your template file) is 20% to 45% faster in my testing. PW3 executes 20% to 25% fewer queries as part of the boot, and loads up to 50% fewer pages. Autoload modules become part of the boot process, so I test with no 3rd party modules installed. The file compiler can potentially add a little bit of overhead even when it doesn't need to compile, because it has to determine whether something needs compilation. But on a default site profile we're talking about maybe 10ms at the most here. If you turn off the template compiler, then that overhead is gone. While PW3 uses fewer resources on the database side, but sometimes more resources on the file system side. If you've got a slow file system, you might notice it more in PW3 than in PW2. For those of you seeing PW3 to be slower than PW2, if it's determined that 3rd party modules are not a factor, I would be curious what's happening in the template files. Perhaps there is a bottleneck in a certain API call or something that we're not aware of yet. It would be interesting to see the results of profiling the API calls in your template files using ProfilerPro or Debug::timer() calls. Mostly specific to Soma: PW2 and PW3 are identical in terms of how they use joins and indexes. Regardless of version, PW will use as many joins as it takes to execute the selector you give it. Just like you can create complex or inefficient SQL queries you can also create equally inefficient $pages->find() calls if you aren't being careful. Using PW's API doesn't mean you are somehow bypassing the database. Your find() queries still become SQL queries. So if you are working on big and complex projects, then you need to watch and profile your work. When you a come across a complex find() operation that is expensive, refactor it to be simpler or break it down into smaller parts. Pay attention to how many pages you load in memory at once. Don't use find() and children() calls without "limit" selectors when dealing with potentially large sets. With regard to indexing, PW logically indexes all the columns that are likely to be used in find() operations, but if you are querying columns in a table have no index for whatever reason (3rd party module that forgot an index, or column not commonly used for queries), you may need to add one. Most of us never need to do this, but since you mentioned "big and complex" you may be in the territory where you have to apply more consideration to these things.

The trick is to build up a string variable eg. $selector, based on the options chosen by the user and using that variable as part of something like: $images = $page->children($selector); This assumes of course that all your images are child pages of the main gallery page. You'll probably want $selector to end up being something like: sort=-camera_model, sort=resolution, sort=-size The way to build $selector can be seen in the Skyscraper's search.php file. For example, this section: if($input->get->keywords) { $value = $sanitizer->selectorValue($input->get->keywords); $selector .= "title|body%=$value, "; $summary["keywords"] = $sanitizer->entities($value); $input->whitelist('keywords', $value); } Each section like this appends more component parts to the $selector string using the '.=' notation. The $input->get->keywords refers to a variable passed from your form using the GET method. You could of course also use POST. GET will put the variables in the URL like ?keywords=word& etc. This is useful for allowing a user to bookmark or share a query link. I am not exactly sure your plans for the resolution and size selects - sounds like you want to offer sorting highest to lowest and lowest to highest? If so, you can build your selector using sort options. Take a look at the sort options on this page: http://processwire.com/api/selectors/ Once you have defined your $selector and searched and sorted the children with it, you can simply foreach through the images: foreach($images as $image){ echo $image->url ...... //etc } Hope that helps.