Leaderboard

This module integrates Swift Mailer mailing library to ProcessWire, providing support for three different "transports" or methods of sending email: SMTP, Sendmail and Mail (essentially PHP's native mail() function). WireMail is email-related base class for ProcessWire. See this post by Ryan for the details. Important thing to note here is that a) it's brand new, so as of this writing you'll need a fresh dev version of ProcessWire to use this and b) it makes integrating new ways of handling email-related tasks very easy. Getting started You can download or clone the module from GitHub: https://github.com/teppokoivula/WireMailSwiftMailer/. Using this module is as simple as downloading / cloning it to your modules directory and installing it. If you're going to use SMTP or Sendmail features, insert correct SMTP credentials / Sendmail command to module settings first. Third transport, Mail, is included simply because it's a native feature of Swift Mailer; if you're going to use it, I would suggest against installing this module. ProcessWire's native WireMail implementation handles this part just fine. Basic usage Sending emails should be done using wireMail() function -- if you use mail() directly, you're going to bypass ProcessWire's email handling features entirely. Main difference between mail() and wireMail() is the order and number of arguments: $number_of_recipients = wireMail($to, $from, $subject, $body); For more information please take a look at README. This module is released under GPLv2 (just like ProcessWire itself) with the exception of included Swift Mailer library, which is copyright © Fabien Potencier and released under the MIT license.

Just committed a fairly major update to support full migration of files and images, including rewriting of the src tag to match the ID of the new page for images embedded into RTE fields. Additionally, the module now also migrates the template .php files. Files/images/template files and the json structure/data file are exported in a zip file which is then imported into the destination PW install. So, you can now select one parent page during export and it will migrate the following content for all child pages of the selected parent: All standard field types, including RTE, and decoding of links modified by the PageLinkAbstractor module and abstracting again on the destination PW install. File/Image/CropImage fields including the actual files/images/thumbnails and all other variations Repeater fields and all their required fields, templates, and all content, including files/images Page fields (and the pages, templates, and fields that make up their selectable pages) Multi-language versions of all field content Templates (including Access, Family, URL and other settings) and the template .php files. It even grabs the appropriate file if you are using the "Alternate Template Filename" setting. NB the templates directory on the destination PW installation must be writable for these to be imported. So, you could build sections of content on a local dev PW installation, export it, and then with a couple of clicks import everything into the live PW installation. Some outstanding issues that I hope to get to shortly: Need to support images inserted from a different page into an RTE field Rewrite any references to page ids, eg $pages->get(xxxx) in template .php files so they will be converted to the correct id on the destination installation. Need to look into the new core link abstractor that was added to PW 2.4 and see how to handle those links compared to the PageLinkAbstractor module. I still want to add finer control for determining exactly what components will be exported and imported. Generally needs lots more error checking for things like making sure required languages are installed on the destination PW install etc Need to add checks so that existing template php files are not overwritten (or give the option to choose) Might need to override PHP max_execution_time and other settings for larger exports and maybe chunk out zipping of all images to prevent memory issues on larger exports. In its current state it is handling almost all my needs, but I would really like to have this robust enough for anyone to use, so if you have time please do some testing for me - THANKS! At the moment, please only use it on two unimportant test PW installs!

Lots of people have been asking for a way for ProcessWire to support sending of email, outside of just using PHP's mail() function. I haven't really wanted to expand the scope of ProcessWire that deep into email sending, but I have been wanting to setup a way so that people could override how emails are sent, with modules. For people that are interested in making other ways of sending email in ProcessWire, I've setup a new module base class called WireMail, and a new function called wireMail(). The wireMail() function will use whatever WireMail module is installed. If none is installed, then it will use PW's default WireMail implementation (based on PHP's default mail function). The wireMail() function replaces all instances of PHP's mail() function in ProcessWire's source. It works in a similar way as PHP's mail() except that supports a few different usages. Standard usage would be this: // to, from, subject, body wireMail('user@domain.com', 'ryan@runs.pw', 'Mail Subject', 'Mail Body'); Another usage would be to give it no arguments, and it'll return whatever WireMail module is installed for you to use yourself. If no WireMail module is installed, then it returns ProcessWire's WireMail. $mail = wireMail(); $mail->to('user@hi.com')->from('ryan@runs.pw'); // all calls can be chained $mail->subject('Mail Subject'); $mail->body('Mail Body'); $mail->bodyHTML('<html><body><h1>Mail Body</h1></body></html>'); $mail->send(); Since all of this stuff is only on the PW 2.4 dev branch at present, I'm posting this primarily for people that are interested in creating WireMail modules. For instance, I know that both Teppo and Horst (and perhaps others?) have put together such modules and ideas, so this is all aimed at coming up with a way for those ideas to be easily integrated into PW by way of modules. To make your own WireMail module, you simply create a module that extends WireMail and provide your own implementation for the send() method. Of course, you can go further than that, but that's all that is technically necessary. I've attached an example module called WireMailTest that demonstrates a WireMail module. When installed, it is used rather than PW's WireMail. This WireMailTest module includes lots of comments for you in the code of it, and you may find it helpful to use it as your starting point. WireMailTest.module For you guys developing modules, please throw any questions my way and I'm happy to help. Likewise, let me know if you think I'm missing anything important in the base interface that the modules are based upon and we can update it.

Just in case that someone happens to read this topic, introduction of WireMail base class by Ryan now makes it possible to build custom email handling modules. Swift Mailer module introduced here has also already been converted to WireMail module.

Hey Marty, I'll take a stab at this. There are a few issues as I see things: The Max Image Dimensions setting: "..... does not affect any images in the system, or images added via the API." but you have noted that already. From your explanation it sounds like the images are already installed. You could resize everything using the API, but then you'd end up with the original sized one as the main image still, but will the sized variation available - I don't think this would help much. So if you upload using the API, you'll need to do the resize yourself. Of course the $image->size() method in the PW API will add the .XxY suffix to the filenames. So I have a couple of scripts for you. This first one allows you to install an image using the API and have it resized to match the Max dimensions settings. This assumes your images field is called "images". I don't think this specifically helps you since you already have the images installed, but I wanted to post this in case it helps someone else. Read below for the next version which I think does what you need. $cp = $pages->get("/"); $url_to_image = "http://ian.umces.edu/images/ian_banner.png"; $cp->images->add($url_to_image); $cp->of(false); $cp->save("images"); $pagefile = $cp->images->last(); $imagesfield = $cp->fields->get("name=images"); $filename = $pagefile->filename; $pagefile2 = null; if($imagesfield->maxWidth && $pagefile->width > $imagesfield->maxWidth) { $pagefile2 = $pagefile->width($imagesfield->maxWidth); unlink($pagefile->filename); rename($pagefile2->filename, $pagefile->filename); $pagefile->getImageInfo(true); // force it to reload it's dimensions } if($imagesfield->maxHeight && $pagefile->height > $imagesfield->maxHeight) { $pagefile2 = $pagefile->height($imagesfield->maxHeight); unlink($pagefile->filename); rename($pagefile2->filename, $pagefile->filename); $pagefile->getImageInfo(true); } I think this code should do what you need. Obviously the first line sets the $cp to the home page, so you'll need to adjust as necessary. After that it runs through all the image fields on that page and resizes the images to match the values in the Max Dimensions settings. Let me know how you go with it. $cp = $pages->get("/"); $cp->of(false); // required for a single image field foreach($cp->fields as $imagesfield){ if($imagesfield->type == "FieldtypeImage"){ foreach($cp->$imagesfield as $pagefile){ $filename = $pagefile->filename; $pagefile2 = null; if($imagesfield->maxWidth && $pagefile->width > $imagesfield->maxWidth) { $pagefile2 = $pagefile->width($imagesfield->maxWidth); unlink($pagefile->filename); rename($pagefile2->filename, $pagefile->filename); $pagefile->getImageInfo(true); // force it to reload it's dimensions } if($imagesfield->maxHeight && $pagefile->height > $imagesfield->maxHeight) { $pagefile2 = $pagefile->height($imagesfield->maxHeight); unlink($pagefile->filename); rename($pagefile2->filename, $pagefile->filename); $pagefile->getImageInfo(true); } } } } Both examples are quite verbose and I am sure could be optimized quite a bit, but should get the job done. I did some testing and they both seem to work just fine.

GitHub: https://github.com/adrianbj/ProcessMigrator This module has gone through lots of iterations with lots of new functionality each time. It is now a fully fledged content migration tool. *** Please be sure to read the GitHub ReadMe to find out what it can do now as most of the posts in this thread are no longer correct regarding its functionality Once it is release worthy, I'll create a fresh thread with all the details. This modules allows export, sharing, and import of page lists via JSON files. It takes care of replicating all the pages, as well as creating any templates and fields that are needed. I have defined "Page Lists" as page trees (parent and children) that store selector values for a Page fieldtype. An example would be a list of countries that would be used to populate a countries drop-down select field. The fields might include: Country Name, 2-digit code, 3-digit code, number code. I would like to suggest a place where we can post json files to be shared and updated - maybe a dedicated github repository? Start of a repo of lists ready to import is now available: https://github.com/adrianbj/ProcessWirePageLists It might handle migrating other simple pages trees as well, but it should not be considered a tool for migrating general pages as it does not handle associated files, nor does it handle fields which store arrays. Probably lots of other things it doesn't handle either It now handles migrating all (I think) field types, including repeater fields, page fields, all Profields fields, multi-language versions of fields etc. The only omission is the actual uploaded files and images in file/image fields. WARNING: This should be considered an Alpha module - please don't use this on a live site at the moment and be sure to back everything up before testing. Would appreciate any feedback on the concept, the code, and the idea of a shared and community edited resource of these files. Also, would love to hear what page lists would be good to share. Here are a few quick ideas: States (separate files for each country) Measurement units Languages Religions Race Academic subjects (chemistry, biology etc) Publication types (book, journal article, newspaper article, newsletter, thesis etc) Car makes and models Anyone have a better idea for a name, or how to better describe "Page Lists"?

PW Images Manager (beta) Just a weird little screencast trying to show how it works. (out of date a little, tags now use a textfield for easy copy/paste) This module allows you to manage images from one central repository. You create a root page "/images/" where you can then add categories and images as pages. From there the new admin page created "ImagesManager" will show categories and images added in a ajax data table, from where you can see and search/filter all images, upload and create new categories and edit images too. Every image will also show an image tag generated to copy into a textarea. This tag looks like this: {image=/path/to/image/imagename/, width=200}The width=100 is the thumbnail size used to output the image.You can also have additional segment to contain classes: {image=/path/to/image/imagename/, width=100, class=align_left}Or you can enter the id directly: {image=1033, width=100}Once inserted into a textarea field it will get parsed when saved and loaded automaticly. It will store an abstract id tag in Database and convert it back to the image HTML tag. So after first save you'll see the image inserted in a Wysiwyg and be able to resize and place it as usual. Once it's inserted somewhere Images Manager will show a search link with the pages containing the image (you can configure the fields int the module setting). You can change the image or move it to a different category, it will still work and show the correct image. This also works with multi-language fields.You can still also use the regular insert image dialog in TinyMCE and chose image from those pages. And it will start keeping track of those as well (they're the same after all). You can use those central images pages also with page fields to reference them single or even whole categories, search them with API and do what you like. Images Manager will also parse the page render on front-end and replace any found image tags with the HTML code. It will also look for a description on the image and output it as alt tag. If you want to have multi-language description you can add a `image_description` TextLanguage field to the image page template and have images parser use them. Along with this module, you can also install the `PageListImageLabel` module to add thumbnails to the image pages in the tree. To get it working you need to have the basic setup: 1. Create new `image` field with input setting to 1 max image 2. Create new `image` template and add `title` and the `image` field created before 3. Create a 'image-category' template with only title and allow the `image` template and `image-category` as child pages under family settings. 4. Create a `image-root` template with only the title field for the root of the images tree. Allow only `image-category` as child page under family settings. 5. Create the root page with the `image-root` under the home page as "/images/" 6. Done. The structure of the image repository looks like this /images/ /cagetory1/ /imagesxy/ /category2/ /image2/ /image3/ Now you can use the ImagesManager to add categories and images. But you can also still use the page tree to add new stuff as usual. The root path, template names and fields are configurable in the module settings. How to install the module: - Download the contents of this repository and put the folder renamed as "ImagesManager" into your site/modules/ folder - Login in to ProcessWire and got to Modules page and click "Check for new modules". You should see a note that the two new module were found. Install the "ImagesManager" module. - A new admin page "ImagesManager" should appear in the top menu. - You may configure the option on the module screen to suit your needs. Download at github https://github.com/somatonic/ImagesManager Thanks and enjoy.

I didn't know this one Shortest way to echo a variable only if populated (using pw fields of course ): echo $page->field?:''; and: echo $page->field ?: "field is empty"; // echoes field content echo $page->empty_field ?: "field is empty"; // echoes "field is empty" or even: echo $page->field1 ?: $page->field2 ?: "they are all empty";

MultiPage Editor is a module that takes any valid ProcessWire selector and shows you all matching pages. You can edit all fields from one page, thus being perfect for bulk editing things like product pages or lists. It works best when selecting on template, because all pages will have the same fields. How to install: Download from: https://github.com/weworkweplay/ProcessMultiPageEditor Place the file ProcessMultiPageEditor.module in your /site/modules/ directory. In ProcessWire admin, click to 'Modules' and 'Check for new modules'. Click 'install' next to the 'MultiPage Editor' module (under heading 'Process'). Following that, you'll see a new menu option for this module on your Admin > Setup menu. Please note that the module currently only shows FieldtypeText-fields. This is something that probably needs some work.

This is already old news to many of you here, but I finished writing up the full announcement today so figured I should post it (click the link below). Numerous upgrades and refinements make ProcessWire 2.4 our most friendly and powerful version yet! ProcessWire 2.4 is focused on listening to the feedback from of our users and answering with the best CMS experience for web designers/developers and their clients. Read the full announcement. For those upgrading from a previous version of ProcessWire, please read all of the upgrade instructions. Hope that you enjoy this new version! A huge thanks to Avoine for sponsoring the Field Dependencies feature new to ProcessWire 2.4!

Great progress! I haven't tried the new features yet (maybe this is covered already) but it might be handy to have it spit out a list of any template files it moves. That would be to remind us to manually move over any include files or other resources those files depend on.

No problem at all. I learned some things along the way Speaking of which, here is a much more concise version of the script using the ImageSizer approach I picked up from Soma at some point: $cp = $pages->get(1157); $cp->of(false); foreach($cp->fields as $imagesfield){ if($imagesfield->type == "FieldtypeImage" || $imagesfield->type == "FieldtypeCropImage"){ foreach($cp->$imagesfield as $image){ $ImageSizer = new ImageSizer($image->filename); $ImageSizer->resize($imagesfield->maxWidth,$imagesfield->maxHeight); } } } As for the memory issues. If it's just max_execution_time that should be an easy fix. If it is also memory related then you might come up against a barrier, no matter where you set the limit if you have too many images. You might need to do it in batches, which you could automate by simply adding a check to see if the dimensions of the image already match what they are meant to be. That way on each batch you'd skip by those that have already been resized. I think that might be a decent approach, but maybe someone else will chime in on this. You also might be better off bootstrapping PW from a php file and running that from the command line.

@adrian: I browsed through the plugins just today, wondering if (and how) some of those should be implemented. Not sure yet, but there's undeniably a lot of useful stuff there and it'd be shame not to put any of those in use. One could always use wireMail() to return instance of WireMailSwiftMailer and it could, in turn, return instance of SwiftMailer.. though admittedly that's not so different from instantiating it yourself

As they say on television "it's not you, it's me". My memory limit and max_execution_time on MAMP needed boosting. With this project I'm hoping to batch import perhaps 350 artists (nearly 4000 images) with Ryan's module so I think I need to work out a way of getting the images smaller beforehand. If I get this job I might need some paid help Thanks very much for your help Adrian.

@Radek... It's amazing how you take care of this language pack. Thanks

This is fantastic teppo! I don't necessarily think you should (as it may make the module unnecessarily complex), but do you have any plans to implement any of the SwiftMailer plugins like Decorator, AntiFlood, and Throttler? I use these for sending out bulk emails to subscribers. I think perhaps in these cases it is simpler if we just include swiftmailer separately in the appropriate template/module code, but thought I'd raise it in case you have any ideas along these lines.

wow ! thanks Teppo

So, I've been seeing some email-related topics around here and actually had quite a few struggles of my own with this very subject myself lately. Thing is that sending email should be easy, but it's not always that; especially for those who have to work on multiple, low-price (and regrettably often low-quality) platforms that may or may not provide proper mail servers.. or prefer to host their services themselves and still want to avoid setting up and maintaining a mail server. Hosting a mail server can be real pain in the ass when things don't work like they should, not to mention that most people have very little knowledge about DNS entries etc. this requires. Anyway, long story short: yesterday I started thinking that wouldn't it be sweet to have a layer of abstraction within ProcessWire for sending email? Of course one could still use PHP mail() -- there's no way and no sense in even trying to stop that -- but using a common gateway would definitely bring in some extra value. This layer I'm talking about could by default use built-in PHP mail() but also make it possible to override it, thus allowing multitude of options that PHP mail(), being bound to Sendmail / it's alternatives, can't offer without additional server-side software (such as Nullmailer.) By making sending emails hookable it could also enable all kinds of interesting tricks to be done when mail is sent -- such as writing a custom log file, sending another email to someone else, updating local content (I'd imagine that this could be useful for building newsletter platform, for an example) and so on. Since words tend to fail me at times like these, I put together a quick proof of concept of what I'm talking about here, accompanied by one example of what could be achieved by doing this: A very simple yet functional Mailer class Two commits on top here list all the changes I've made in my PW fork to make this work -- including the fact that I've altered some default modules to use $mailer->send() instead of mail() SwiftMailer module, again very simple but fully functional (though only tested with Gmail SMTP) drop-in replacement for PHP mail() So, what do you folks think of this? Please keep in mind that this is just a suggestion and I'm not saying that this is the right path to take especially considering that it would add another API variable -- it just felt like best option here and I couldn't think of cleaner way to achieve it.

In ImagesManager I used to create a new PageImage before adding it so it will get resized according to max width settings. $im = new PageImage($page->images, $url_to_image); $page->images->add($im); https://github.com/somatonic/ImagesManager/blob/master/ImagesManager.module#L527

Thanks kongondo, so I got myself an account on GitHub now and posted the issue: https://github.com/ryancramerdesign/ProcessWire/issues/383

Yes, but it is free membership. The advantages of filing at Github are: 1. Ryan will definitely see it 2. Changes can be tracked 3. Progress can be followed. I am not saying that Ryan will not pick it up from here; but there are chances that he can miss it too. On the other hand, a verified bug can also be filed on your behalf by someone with a Github account in these forums. Finally, you don't have to be a dev or module contributor to join Github

Hi there This may be what you are after: http://modules.processwire.com/modules/service-pages/

Far out! When I get a spare hour I'll give this a go.

Ryan, I would like to have the possibility not to use only the Emailaddress but also the Recipients Names with the TO-array. Actually it accepts only a single emailaddress or an array with emailaddresses, but no names. When building that on my own I would have to break compatibility. Don't like that. Could we not use something like: public function to($email) { if(!is_array($email)) $email = explode(',', $email); $this->mail['to'] = array(); // clear // check for key-value pairs containing name=>email if(array_keys($email) !== range(0, count($email) - 1)) { foreach($email as $n=>$e) { $this->mail['to'][$n] = $this->sanitizeEmail($e); } } else { foreach($email as $e) { $this->mail['to'][] = $this->sanitizeEmail($e); } } return $this; } // also within the send() function we have to check if we have array with name=>email or string only with email I'm not happy with my code example. A better way is much appreciated, but I really would like to have that possibility. ---------------------------------------------------------- - EDIT ---------------------------------------------------------- Now after some testing I came up with this code what seems to be better: public function to($email) { if(!is_array($email)) $email = explode(',', $email); $this->mail['to'] = array(); // clear foreach($email as $n=>$e) { // check for associative key-value pairs containing name=>email if(is_string($n)) { $this->mail[$type][$this->sanitizeHeader($n)] = $this->sanitizeEmail($e); } else { $this->mail['to'][] = $this->sanitizeEmail($e); } } return $this; } And in the send() function we need to loop like this: $numSent = 0; foreach($this->to as $n=>$to) { $to = !is_string($n) ? $to : ( $n . ' <' . $to . '>' ); if(mail($to, $this->subject, $body, $header, $param)) $numSent++; }

I'm pretty sure that wouldn't be an issue - that's why it's configurable EDIT: Other than probably having to log back into the admin after you change it.

Unless I'm somehow missing your point here, inputfield doesn't matter when working over API. Insert values and save the page, that's it: $page->of(false); $page->page_field = $pages->get('name=my-page'); $page->page_field = 1; // etc. $page->save(); For more examples take a look at this post.

Got first version of SwiftMailer implementation working locally, should be able to push to GitHub after some testing. Ryan has, once again, made things too easy for us..

Well, that makes sense. To be honest I didn't think of that. However, this gives you the choice of what to install and what not. It's a small difference. Thanks!

A couple of options from Soma for achieving this: http://processwire.com/talk/topic/3159-hide-settings-tab-in-page-edition/?p=31126 http://processwire.com/talk/topic/4680-block-access-to-settings-delete-and-view-tabs-for-page/?p=45734

I will upgrade to the latest MAMP here soon and see if I can reproduce it. You've got me wondering if there is some incompatibility with that version of MySQL (5.6.14). Though if it were widespread, you'd think we would have heard about it more than once.. and maybe we will. I'll keep an eye out and do some testing here too.

Yep, It creates all required templates and fields using the settings from the original version. It won't re-create or modify a field if it is already existing, but it will add an existing field of that name to the required template. I did think about separating the metadata and content - went with the lazy option to start with until I get some feedback on what changes to functionality might be good. At the moment, the first item is the parent, parent template and child template info. The second is the field info. The rest are the data.

Greetings, What makes ProcessWire so excellent is the ability to do all kinds of work at the API level, so that you can essentially create a custom admin for your projects. Editing a page is of course a crucial part of any custom admin. NOTES: Of course, you must cutomize this to your project. Also, in my code I am editing the page directly inside the page itself. In other words, you display a page as usual, but inside it you have your edit code, as well as code to save the page after editing. The other option would be to link to another page just for editing. Editing does get rather involved. Below is a technique I've used. I'll break editing down to several steps, then later I'll put it all together as one. Here goes... Step 1: Isolate Who Has Editing Rights You don't want anyone who can view the page editing it! I use code like this to limit editing to people with either an "editor" or "superuser" role. We open it here, and close it later in Step 6: <?php if ($user->isSuperuser() OR $user->hasRole("editor")) { Step 2: Set the $page Variables (Except Title) to Hold Edited Values Take inputs received from a submitted form and use those values to replace current $page values. For this example, I am only using two fields to keep it simple. And they are text fields. We hold off on setting the title, since that needs special handling: <?php if ($input->post->title) { $page->set("first_name", $sanitizer->text($input->post->first_name)); $page->set("last_name", $sanitizer->text($input->post->last_name)); } Step 3: Edit Title Field, but Only if the Title is Unique, Then Save the Page You need something like this so you don't get an error if the title you apply to the edited page collides with the title of an existing page. The code below confirms that the title is unique and allows you to set the title, and only then save the page: $thistitle = $page->title; $matchedtitle = $input->post->title; $checktitles = $pages->find("parent=/[path]/[to]/[parent]/, title=$matchedtitle|$thistitle"); $titlecount = count($checktitles); if($titlecount < 2) { $page->of(false); $page->set("title", $sanitizer->text($input->post->title)); $page->set("name", $sanitizer->text($input->post->title)); $page->save(); Step 4: Refresh URL Think about it... If while editing this page we changed the title, the URL you are on is no longer valid. Here's a simple bit of Javascript to handle this. The code below also closes out the conditional set in Step 3: $refresh=$page->url; ?> <script type="text/javascript"> window.location = '<?php echo $refresh ?>'; </script> <?php } Step 5: Handle the Scenario When the Page Title Collides In Step 3, we edited the page title because it passed the "unique" test. But what if it fails that test? We would move to this section of code, where a message lets the user know there is a problem. A bit of Javascript helps make the warning fade in so it is more noticeable: else { ?> <div class="admin_error_box"> <p>Sorry, there is already a page using this title: <?php echo $input->post->title?>!</p> <p>Please enter a different title in the form.</p> </div> <script> $(function() { $('.admin_error_box').hide().fadeIn(3000); }); </script> <?php } Step 6: The Edit Form We need a form to capture the submission of edits. It would look the same as your page-creation form, but would have to be pre-populated with the current values of the page, which will also change upon submission of the form. The last bit of code closes out the check on user roles set in Step 1: <div class="page_create_form_box"> <p class="form_heading">EDIT THIS PAGE USING THE FORM BELOW</p> <form action="<?php echo $page->url ?>" method="post"> <ul> <li><label class="label_class" for="title">Page Title:</label> <input type="text" class="input_class" name="title" value="<?php echo $page->title ?>"></li> <li><label class="label_class" for="first_name">First Name:</label> <input type="text" class="input_class" name="first_name" value="<?php echo $page->first_name ?>"></li> <li><label class="label_class" for="last_name">Last Name:</label> <input type="text" class="input_class" name="last_name" value="<?php echo $page->last_name ?>"></li> </ul> <button class="admin_submit" type="submit" name="submit">SAVE EDITED PAGE</button> </form> <?php } ?> Step 7: Putting it all Together Now let's put all of this code into one continuous routine. <?php if ($user->isSuperuser() OR $user->hasRole("editor")) { ?> <?php if ($input->post->title) { $page->set("first_name", $sanitizer->text($input->post->first_name)); $page->set("last_name", $sanitizer->text($input->post->last_name)); } $thistitle = $page->title; $matchedtitle = $input->post->title; $checktitles = $pages->find("parent=/[path]/[to]/[parent]/, title=$matchedtitle|$thistitle"); $titlecount = count($checktitles); if($titlecount < 2) { $page->of(false); $page->set("title", $sanitizer->text($input->post->title)); $page->set("name", $sanitizer->text($input->post->title)); $page->save(); $refresh=$page->url; ?> <script type="text/javascript"> window.location = '<?php echo $refresh ?>'; </script> <?php } else { ?> <div class="admin_error_box"> <p>Sorry, there is already a page using this title: <?php echo $input->post->title?>!</p> <p>Please enter a different title in the form.</p> </div> <script> $(function() { $('.admin_error_box').hide().fadeIn(3000); }); </script> <?php } ?> <div class="page_create_form_box"> <p class="form_heading">EDIT THIS PAGE USING THE FORM BELOW</p> <form action="<?php echo $page->url ?>" method="post"> <ul> <li><label class="label_class" for="title">Page Title:</label> <input type="text" class="input_class" name="title" value="<?php echo $page->title ?>"></li> <li><label class="label_class" for="first_name">First Name:</label> <input type="text" class="input_class" name="first_name" value="<?php echo $page->first_name ?>"></li> <li><label class="label_class" for="last_name">Last Name:</label> <input type="text" class="input_class" name="last_name" value="<?php echo $page->last_name ?>"></li> </ul> <button class="admin_submit" type="submit" name="submit">SAVE EDITED PAGE</button> </form> <?php } ?> My apologies for any problems with the formatting of the code above (please use your editor to assure proper tabs). Notes: - If you include checkboxes or other field types in your page, the editing is a bit more involved. - If you have image fields, you would have separate actions connected with those. For more information on handling image fields in custom forms, take a look at this: http://processwire.com/talk/topic/3105-create-pages-with-file-upload-field-via-api/ That should get you started! Follow up if you have more questions! Thanks, Matthew