Leaderboard

Two or three things come to my mind directly: If there is no unique ID within the feed, you have to create one from the feed data per item and save it into an uneditable or hidden field of your pages. Additionally, you may concatenate all fieldvalues (strings and numbers) on the fly and generate a crc32 checksum or something that like of it and save this into a hidden field (or at least uneditable) with every new created or updated page. Then, when running a new importing loop, you extract or create the ID and create a crc32 checksum from the feed item on the fly. Query if a page with that feed-ID is allready in the sytem; if not create a new page and move on to the next item; if yes, compare the checksums. If they match, move on t the next item, if not, update the page with the new data. Code example: $http = new WireHttp(); // Get the contents of a URL $response = $http->get("feed_url"); if($response !== false) { $decodedFeed = json_decode($response); foreach($decodedFeed as $feed) { // create or fetch the unique id for the current feed $feedID = $feed->unique_id; // create a checksum $crc32 = crc32($feed->title . $feed->body . $feed->status); $u = $pages->get("template=basic-page, parent=/development/, feed_id={$feedID}"); if(0 == $u->id) { // no page with that id in the system $u = createNewPageFromFeed($feed, $feedID, $crc32); $pages->uncache($u); continue; } // page already exists, compare checksums if($crc32 == $u->crc32) { $pages->uncache($u); continue; // nothing changed } // changed values, we update the page $u = updatePageFromFeed($u, $feed, $crc32); $pages->uncache($u); } } else { echo "HTTP request failed: " . $http->getError(); } function createNewPageFromFeed($feed, $feedID, $crc32) { $u = new Page(); $u->setOutputFormatting(false); $u->template = wire('templates')->get("basic-page"); $u->parent = wire('pages')->get("/development/"); $u->name = $feed->title = $feed->id; $u->title = $feed->title; $u->status = $feed->status $u->body = $feed->title; $u->crc32 = $crc32; $u->feed_id = $feedID; $u->save(); return $u; } function updatePageFromFeed($u, $feed, $crc32) { $u->of(false); $u->title = $feed->title; $u->status = $feed->status $u->body = $feed->title; $u->crc32 = $crc32; $u->save(); return $u; }

Using the uncache has nothing to do with the function calls. Uncaching is usefull in loops, at least with lots of pages, to free up memory. Every page you create or update or check values of, is loaded into memory and allocate some space. Without actively freeing it, your available RAM gets smaller and smaller with each loop iteration. Therefor it is good practice to release not further needed objects, also with not that large amount of iterations.

Small update video below. There are again many changes behind the scenes. Multiple instances of "Gridbuilder" can now exist on the same page. More "in-memory-actions" (JS) means less need to press the save button. But normal PW templates are still the base of everything. Images can be dropped directly onto a grid_image template. See video. http://theowp.bplaced.net/upload/pics.html Thank you.

You can also just use: $this->wire('page') $this->wire('mail') etc inside the hook function.

Sure, I'll allocate some time to it, thanks for keeping this up.

@jmartsch Yes, it's intriguing. But if I understood it correctly, it's for the admin, not the front end display. Back end builders can be great and I've always liked the PW appreach. They allow designers to control design and editors to control content. That's not the same though as what has really taken off over the last couple years in WP world. Which is a truly WYSIWYG front end builder which is also not ideal for many situations but is ideal for certain situations. Not saying PW necessarily needs something similar.

Gutenberg is.. okay. It's getting mixed reviews https://en-gb.wordpress.org/plugins/gutenberg/#reviews. The trouble is, it allows the user to do too much. It's trying to sit in the middle ground of a page builder and an editor. I think giving the user everything even if they don't need it isn't inline with ProcessWire. Things like being able to make columns etc. I actually much prefer Statamic's implementation with it's Bard field - https://docs.statamic.com/fieldtypes/bard

There was an issue with "inputfieldButton" in PW 3.0.109. Ryan fixed it yesterday, I pulled the fix en now the issue is resolved. https://github.com/processwire/processwire-issues/issues/653

I think the most likely situation is that you haven't created any template files to match the templates of the imported pages. If you are importing a WP blog, then you need something like blogs.php and blog.php in your /site/templates/ folder. You can create these manually yourself, or you could use the blog module http://modules.processwire.com/modules/process-blog/ depending on your needs.

http://processwire.com/api/selectors/#or-groups

In case of images you can let them upload what they want, but ensure that it is in highest possible quality. For the output you define width x height, quality and even output format (jpeg), if they use png were not appropriate. ?

Tasker is a module to handle and execute long-running jobs in Processwire. It provides a simple API to create tasks (stored as PW pages), to set and query their state (Active, Waiting, Suspended etc.), and to execute them via Cron, LazyCron or HTTP calls. Creating a task $task = wire('modules')->Tasker->createTask($class, $method, $page, 'Task title', $arguments); where $class and $method specify the function that performs the job, $page is the task's parent page and $arguments provide optional configuration for the task. Executing a task You need to activate a task first wire('modules')->Tasker->activateTask($task); then Tasker will automatically execute it using one of its schedulers: Unix cron, LazyCron or TaskerAdmin's REST API + JS client. Getting the job done Your method that performs the task looks like public function longTask($page, &$taskData, $params) { ... } where $taskData is a persistent storage and $params are run-time options for the task. Monitoring progress, management The TaskerAdmin module provides a Javascript-based front-end to list tasks, to change their state and to monitor their progress (using a JQuery progressbar and a debug log area). It also allows the on-line execution of tasks using periodic HTTP calls performed by Javascript. Monitoring task progress (and log messages if debug mode is active) Task data and log Detailed info (setup, task dependencies, time limits, REST API etc.) and examples can be found on GitHub. This is my first public PW module. I'm sure it needs improvement

Hello PW-Community! I have been working with Repeater-fields for years without coming across this problem: On a recent website-project I use a TextareaLanguage inside a Repeater-field. When I switch the language from default to english, it still shows default. Now I moved the same TextareaLanguage-field to child-pages instead and it works like expected. Is this a new bug, I need to report, or am I missing something? I work with ProcessWire 3.0.107.

From the API side it is still valid and working code. I don't think there is one best way to go. This tutorial shows one possible approach. There are many different other approaches possible. But at least it shows the basics of implementing a REST API. You can also have a look at https://modules.processwire.com/modules/rest-api-profile/ which is the most recent approach I'm aware of.

No. Thank YOU!

We did some more testing and found that the problem seems to stem from the fact that we use Matrix Repeaters from Ryan's ProFields extensively. If we remove pages that have those fields we can migrate ok. What would a good workaround to this be? We are trying to use this to migrate template and content changes between 3 different environments. Without Matrix repeater support we can't really migrate the bulk of our content.

Tough question ? Have you seen this module? Edit: or this one as another related alternative:

Actually, I have been pondering making this more targeted. Let me gather thoughts and I'll either PM you a proof of concept or post more about it here.

Yes - as an example: drwxr-xr-x 9 ajones staff 288 Aug 6 09:36 wire Since you playing around this panel and given your experience the Diagnostics module, I wonder if you have any thought about the Status and Notes that are being returned? Also, have you looked at the Filesystem Files option?

Another new site only recently finished (so there still might be bugs :) http://www.ethicalby.design/ Ethical by Design is my new personal project. I've been running a podcast called the Machine Ethics Podcast: about the social impact of AI. Over the last few years I've learnt alot and I'm now hoping to help businesses learn about or implemented AI responsibly. Branding done by Nick Willsher, and the site was designed and coded by myself. Hoping to spin this one out into a more configurable site profile for the community soon.

Ha, true. I'm future proofing it. Will have a blog up there soon too.

If you are on a Mac, I can strongly recommend ff Works for encoding anything. It uses FFmpeg, which you can use via command line for free, but with a nice GUI. ?

Hello, can you try this: if ($input->get("tags")) { // If GET ?tags= exists... $currentTags = $input->get("tags"); $currentTags = $sanitizer->text($currentTags); // tags=furniture|mirrors $selector = "stock_detail_tags.name=" . str_replace('|', ',stock_detail_tags.name=', $currentTags); $products->filter("$selector"); // Filter products by the tags $pageTitle = str_replace('|', ' > ', $currentTags); if (!count($products)) throw new Wire404Exception(); // If no returned data then return 404 } To get AND inside query, you need to repeat query parameter (target) inside selector (example: 'tags=foo, tags=bar'). Regards.

@horst That would be great! I'll send you a PM ? thanks

Have you heard of storage quota? ?

Yeah, without a template.php file ProcessWire doesn't know how you want the admin template rendered - what fields do you want to output where and in what structure and with what CSS. Remember that PW doesn't output anything on the frontend by default - which is why it's so flexible rather than fighting against the system.

Would anyone be interested in having an option to make bd() and d() calls output two versions - one with debugInfo on and one with it off? I am finding that I often want both because sometimes the debugInfo version is useless, but then sometimes it contains really useful info not available without it, eg @horst's new image info: https://github.com/processwire/processwire/pull/117 Any thoughts on this?

Just to follow up on this - if you still feel like converting it to pure JS, I'd been keen to maintain that new version. I don't have the need or motivation to do it right now, but I can imagine that I may want it in the not too distant future. It doesn't sound like the Drupal version will end up being converted, but at this point in the development of the module, I think that's ok. If it receives any new killer features I'd be happy to port them over myself. Let me know if you're still on board. Thanks!

Get ready for a face palm ? On line # 145 public function __processInput(WireInputData $input) { the method processInput() is missing one underscore at the beginning and should be public function ___processInput(WireInputData $input) {

Simple and nice. Caught a little typo there ? Also, you might want to match the height of the bottom contact form elements, or re-arrange them. The msg textarea is quite small...

You need to set the type of the repeater matrix.... ie: $new->repeater_matrix_type = 1; and save the item before adding files. And you don't need to add the new item to the field after that, it's already added.

I just pushed the update to support multiple forms on one page. Unfortunately it's not perfect, because Nette Forms have some issues here ? But at least it works for my scenario...

This is the shortest method using implode(): if($page->authors->count) echo $page->authors->implode("; ", "<a href='{url}'>{title}</a>") . ".";

Hey @horst n @pwired How could you forget @bernhard's blog post? https://processwire.com/blog/posts/building-custom-admin-pages-with-process-modules/? @TheProcessWireLearner Welcome to the forums! Regarding PHP itself: https://www.tutorialspoint.com/php/php_constants.htm I like recommending this, as reading these tutorial pages is enough for anyone to get started, you do not need to know too much more PHP in order to achieve a lot with ProcessWire. I also recommend keeping an eye on: https://processwire.com/talk/discover/unread/?&amp;view=condensed in order to learn from others.

This can now be done with owner selectors (http://processwire.com/blog/posts/processwire-3.0.95-core-updates/) $tagsThatHaveBeenUsedOnPosts = $pages->find('template=tag, tags.owner.template=post'); Where tags is the name of the field on the post template that holds the tag pages. Also, for any given tag page you can check how many post pages reference it with $page->references('template=post')->count(); https://processwire.com/blog/posts/processwire-3.0.107-core-updates/#what-pages-point-to-this-one

Actually over five years old, but may contain some useful snippets:

Hello, Here come a few pointers: payment integration: http://omnipay.thephpleague.com https://www.payrexx.com/en/pricing/pricing/ https://processwire.com/talk/topic/14808-now-my-client-wants-to-add-ecommerce/ https://processwire.com/talk/topic/14511-e-commerce-tutorial-with-processwire-snipcart-your-thoughts/ member restriction: for backend: https://processwire.com/talk/topic/11499-admin-restrict-branch/ https://modules.processwire.com/modules/textformatter-soundmanager/ Subscription management https://processwire.com/talk/topic/16363-recurme-–-processwire-recurring-dates-field-custom-calendar-module/ AJAX front end editing for building playlists & "likes" while PW has frontend editing support: https://processwire.com/blog/posts/front-end-editing-now-in-processwire-3.0-alpha-4/ you might find that rolling out your on frontend solution is more versatile in your case so maybe you want to take a look at this one http://intercoolerjs.org/ or you might want to do it all in the admin: https://processwire.com/blog/posts/building-custom-admin-pages-with-process-modules/ or both frontend AND admin ? related: https://processwire.com/talk/topic/7913-podcast-profile/ https://processwire.com/talk/topic/12752-pw-podcast-theme-for-podcasts/ Hope this helps.

Hi Guys, Here's is our most recent website built in collaboration with the Design studio DITHO from Cologne, who designed and coordinated all the process. For now the website is only in German, but there will be a English version soon. https://bedrohte-ordnungen.de/ "Bedrohte Ordnungen" (Threatened Orders) is the display of an ongoing research by the University of Tübingen. Best described on their own words. Here on a hopefully accurate translation Here's a nice showcase video made by DITHO: This is a quite complex website. It's also quite heavy on images, videos and CSS animations, so old computers might struggle a bit to process it. All the website is dynamic and inside PW, including those animations. This is probably the most interesting part of how the website was built, since all the animations were created by DITHO themselves in ProcessWire thanks to a system that I created for them using a repeater field. You can have an idea through these screenshots: The content blocks of each case represent a question each and repeat throughout all the presented cases. Each question has a main content and most have also a hidden block that can be opened by clicking a button. They are created in PW using the very recent FieldGroups https://processwire.com/blog/posts/processwire-3.0.73-and-new-fieldset-types/: The only two third party modules used were AdminOnSteroids by @tpr and the very useful ColorPicker by @Soma. There would be more to talk about, but I don't want to extend myself too much. Hope you guys like it! Just a shout out to DITHO to say again how much fun this collaboration has been

There's no way to test a migration beyond just using it. That's why I feel the downgrade functionality is so important. It enables you to quickly iterate on things missing. Also keep migrations small and focused on a single concern. Personally I don't even worry about backing up my database just for running a single migration. I'm using CronjobDatabaseBackup, which does a backup every day or so and I've not restored once of of them by now. There's not really to much, where you would destroy something not quickly fixable via the admin backend. For more involved changes, where lot's of pages are affected I also like to split things up in multiple migrations, which I can run manually – checking things after each migration. After a few initial migrations written the potential of bugs will also considerably drop for everything "standard". E.g. creating a field with a FieldMigrations is essentially just setting some properties. The hard stuff is already taken care for. If you make errors there it's a matter of deleting the field and rerunning the migration and everythings fine again.

Thank you nik, for that code. I am using it and it works quite well. Only thing that needs to be changed is the while from while (count($results) > $limit); to while (count($results) = $limit); Otherwise it loops 1 more time than it should.

In case anyone is interested in trying out some of the things I was talking about in previous posts here, the latest dev branch has a field import/export function. You'll see it in the lower right corner of Setup > Fields. It enables you to copy and paste any fields across any PW installations. Locally, I also have this working for templates (with fieldgroups), though that part needs a little more work so it's not yet committed. I also have fields, templates and fieldgroups mirroring every change to JSON files, as an option that can be enabled for those that want to version these things with Git and what not. That part also isn't yet committed to dev, but will be soon. However, I figured the copy/paste function probably had the largest use potential. It makes migrating field changes (or creation of new fields) quite a simple task. Next up on the commits will be the same thing for templates (with fieldgroups). (note I didn't take these screenshots together, so they aren't referencing the same fields).

> We use a user interface here for exactly what a user interface is meant for. Agree - however... > I would consider myself very lazy and remiss in my responsibilities if I expected people to use text files (YAML or otherwise) as the primarily method of configuratio I don't think anyone has proposed or suggested that? We're proposing a supplement/alternative, not a replacement. At least I would never suggest that, and I don't think that's what rajo was trying to imply. Ryan, do you have any thoughts on what I mentioned a couple of times earlier - changing the API internally to use a command pattern for changes to the data model? If every change to the data-model had to be submitted to a command processor in the form of an object, and those objects could be serialized, and assuming the command processor was hookable, that would make it trivial to implement all kinds of synchronization / change management / logging / recording modules. The problem with manipulating schema directly, is you can't only tell whether something changed, not how it changed or why - you are already working around this fact by introducing things like change-tracking internally in the objects, which need to know what changes were made. For example, when a field gets renamed, there are methods to capture that change and work around it's side-effects. When dealing with schema, I find it safer to have a centralized facility through which detailed records of change pass through - rather than manipulating individual aspects of the schema independently here and there. Template changes and Field changes, for example, are closely related because they are components of the same schema model - yet these changes are completely unrelated at the API level. A command facility could provide a central API point where all schema-related changes would be exposed, even future (and even third-party) changes would pass through it, so for example a synchronization module could work with future/third-party extensions to the data-model...

You are not already screwed if your writable files aren't executable or don't represent files that can blow up the site. Obviously, the intention is that nobody else can write to the writable files, but the reality is when designing a system we have to plan for the worst. Your environment and my environment may be well secured, but I try to think about the bigger picture out there where there are a lot of insecure environments. Security is #1 when it comes to ProcessWire. What are secure permissions and what are not is dependent on the server and not something we can detect. A security best practice is to get everything important out of any writable files on the file system and not have any single writable files that could take down the whole system. Meaning, I think it's acceptable for cache files, image and other independently served assets to exist as writable files, but the files we're talking about here are definitely out. Another reason we can't detect this stuff is because there are plenty of hosts running phpsuexec and the like where apache runs as the user and everything is writable by default. This tends to be okay, so long as there isn't also a copy of WordPress somewhere on the account. Basically, what are the right permissions for a given site comes down to the server, environment and host, and not ProcessWire. If someone is able to write something to some file on your account, that does not imply they can access the DB. That "someone" is usually an automated script and not a real person, or it's one of your account neighbors on a shared webhost. One of the things that regularly falls in my lap (for better or worse) is to fix hacked WordPress sites. Rarely has the DB been touched, while most of the writable file system has to be quarantined. I disagree. There is a direct connection of field schema to the data represented in the DB. Template files are not coupled to fields like that because you are talking about your code, not the system. You have to make your changes independently regardless of where they are stored. Changing a field doesn't automatically change a template file. But changes to fields are an end-point in terms of how they reflect on the database. I've run out of time for today so have to stop. But I want to be clear that PW is not going to regress to storing this stuff on the file system. I recognize there is a benefit to some developers in having files they can version control or migrate independently. I personally would find the drawbacks to far outweigh the benefits (I have to support this project for a large audience), but understand why some find it desirable. Like I've mentioned, I would consider in the future mirroring the data to files that you can version control and selectively migrate in the admin. I believe that would bring the benefits of what's been discussed here, without the drawbacks.

At some point, I'll setup fields and templates to maintain mirror copies of files on the file system for those that want to version control them that way. They are in the database for very good reasons, but that doesn't mean that they can't be on the filesystem too. It's just that the database is the better default place for them to live and be maintained from for the vast majority. I don't consider writable files particularly trustworthy in the grand scheme, so the master source would always have to be the DB, but the mirror files could certainly be monitored, versioned and migrated at the developers discretion. I have no problem with that so long as we're not letting the file system lead. Something to add here that I think gets overlooked is that PW is not just a development tool. In the majority of cases, the development phase is just a very short blip in the overall timeline of the project developed with ProcessWire (whether a website, application or whatever it is). While we put a lot of focus on the development tool aspect of PW, the big design decisions are made for the entire lifecycle, not just the development phase. CMSs have to be written for large scale realities and diversity across hosting providers, varying amounts of security and expertise levels. While files here seem beneficial from one perspective, that does not translate to a net benefit in the larger context. In fact it translates to something rather undesirable in the larger context. Having important data in writable files on the file system is something you try to avoid with a CMS. While they are a necessary evil in some cases, if you can keep writable data in the DB, it's going to result in stronger security over a broad installation base and over a broad time period. These writable files are often the weakest link on shared hosting accounts. They can be perfectly secure, but there's little doubt the DB is safer. When it comes to data that needs to be editable, I consider the DB a much more trustworthy storage mechanism for important data across a large set of installations. I'm stating the diverse reality of our big picture context and not any individual's server. Some of us are running on servers where it would make no difference at all from a security aspect, but that's not something we can count on. Outside of the situations mentioned in this thread, I think most would not find it desirable to have the field and template data that disconnected from the content it represents. I can imagine some real headaches with schema getting disconnected from the data. When I backup my DB, I like to know that I've got everything necessary to put it back together without having to chase down multiple files with multiple tools, not to mention possibly files in different versions. I don't want to open the door to having having schema files that are not consistent with the data that they are supposed to represent. Data loss is always a possibility with schema changes and should always be accompanied by a confirmation. Automation by movement of schema in files (whether by git or SSH, FTP, etc.) is problematic for a lot of reasons. The issue described about one person's changes overwriting another's may be a potential real world case, but is a non-issue for most of us because we don't migrate those kinds of changes at the DB level, nor do I recommend doing that. I understand that there are challenges for a team of developers having multiple versions of schema, or developers that want to migrate schema changes to a live server in an automated fashion rather than re-playing those changes themselves. I actually think less automation is ultimately a safer solution here, even if not as convenient for some. Though I'm still very enthusiastic about continuous integration projects and doing anything I can to support them. But I do not support moving storage away from the DB as our primary storage for these things. I understand using the file system may seem like a smart choice in certain contexts (and I don't disagree on them), but in the larger context it's not a wise choice. I'll do my best to find ways to mirror the data to files for those that might want this or may benefit from it.

if ($page->isTheDamnHomePage == 1) { echo "Welcome Home"; } Sorry, that's not a real one. I blame it on Friday afternoon and a lack of sleep...

I had the need of iterating through a lot (and I mean A LOT) of pages by template, and was also having memory problems. With this amount of pages it was becoming really annoying to do it few at a time, so I came up with a solution that doesn't need a wireArray. With this I could iterate over more than 50.000 pages with the same template on a website with more than 100.000 pages by bootstrapping PW from the command line. I just had to set a time bigger limit to PHP with set_time_limit(), and everything went fine and without interruptions. while (1) { $p = wire('pages')->get("template=my_template, id>$id"); // get page with id bigger than previous if(!$id = $p->id) break; // assign current page's id to $id or break the loop if it doesn't exist // do stuff using $p as the current page wire('pages')->uncacheAll(); // clean the memory (with $p->uncache() doesn't work. why?) }; edit: actually, using the command line I don't think set_time_limit() is even needed.

@mvolke the module I'm working on synchronizes structure only - Templates, Fields and Fieldgroups. It stores captured model operations in JSON files. I currently have no plans to synchronize content (Pages) though it may prove to be necessary at some point - because Pages are used for so many things, certain Pages may need to synchronized, for example options for drop-downs. I'm having Ryan take a look at the module now, and his initial reaction was positive - I think we can make this work, and I think it'll work well. You would think that, but if you look at the ProcessWire codebase, the entire meta-model, with all possible operations, is encapsulated and supports hooks - so it is actually perfectly feasible to implement this in ProcessWire. As proof of concept, I already have all Field operations captured and repeatable. Because this is implemented at the lowest API level, it is actually independent of controllers and user-interface - that is, if you were to build your own admin modules that (for some reason) make changes to any part of the meta-model, those changes would be correctly captured and would be repeatable, independently of any admin UI. There is still substantial work to do on this module, but I would say it's about half-done at this point, and there are no major roadblocks to completion - the fundamental idea is proven and works, so it's a matter of building it out completely.

1) Migrations I had the same problem during my work with Processwire. If you have a team working on a Processwire project where everyone has his own dev server then you need to be able to version the "structure" you put into Processwire and keep it in sync with the template files. I found it to be important to strictly distinguish between structure and data. In 90% of the cases this means templates and field can be seen as structure and pages would be the data. In my current project I tried to use the concept of migrations with Processwire utilizing the phpmig library. If you strictly create all of your "structure" with migrations and never with the Backend UI then it works perfectly, your structure is always in sync with the template files and you can put both in your favorite VCS. To give you an example of how this works: https://gist.github.com/webholics/6191779 2) Structure vs. Data I'd like to add more thoughts to the problem of mixing structure and data in CMSes. This is not a problem only Processwire has, but most CMSes do this (in my opinion) wrong. If your main target user group are developers, it should be possible to keep those things separate in order to enable professional workflows like continuous integration and TDD. This is only possible if you define the structure in code or in config files and not in the database and via a backend UI. It is always the case that template files and structure are strongly depended on each other. One CMS - I'd like to mention here for inspiration - which implements this concept perfectly is Bolt (http://bolt.cm/) . They use YAML files to configure the database models. Bolt then tries to keep them in sync with the database. Maybe it helps to have a look at how they did it.

The two one would have to consider are: Page Fieldtype -- keeps track of an ID from the pages table, if you choose to use the "parent" as the criteria for selectable pages. It doesn't add anything to the pages table, it just keeps track of an ID already in there. Repeater Fieldtype -- This one actually generates pages as you mentioned (and it's the only I'm aware of that does). Any continuous integration tool would probably want to exclude these two, or at least the Repeater one, until version 2+. I think it fits the commercial option well. My plan is to add JSON import/export to templates and fields very soon (very much like what's in FormBuilder). But this is just a quicker way of doing it manually (copy/paste vs. doing the work), it doesn't have the scope of a fully automated deployment tool.

Thanks for your post. What you are doing looks right, except that you can skip creating the Pageimages field. PW would rather do that internally. So this is the entirety of what you should do (after you have your $page object): <?php $page->images->add("path or URL to image"); $page->save(); If you are doing this from a template file (as opposed to a shell script or admin module), you have to turn the output formatting off first, as you saw. This is to ensure that you don't accidentally add runtime-formatted content to a page and save it. By "runtime-formatted", I mean entity encoded, markdown, etc. This example might better explain it: <?php $mypage = $pages->get(123); echo $mypage->title; // value is "Products & Services" $mypage->setOutputFormatting(false); echo $mypage->title; // value is "Products & Services" Now lets say that you did this instead: <?php $mypage = $pages->get(123); $mypage->title = "Great " . $mypage->title; $mypage->save(); If ProcessWire let you save that page, the 'title' field would now have this value the next time you viewed it: Great Products && Services Basically, PW only wants to save content in an unformatted "clean" state. It throws that error asking you to set output formatting OFF in order to protect against you corrupting your content. So to follow up from the first example, this is what you should do if you are doing this import from a template file: <?php $page->setOutputFormatting(false); $page->images->add("path or URL to image"); $page->save();