adrian

To be honest, I haven't had the need to use track changes yet either, although it sounds like it would come in handy if you are looking to report field level changes.

How's this to get things rolling? foreach($pages->find("id!=2, id!=7, has_parent!=2, has_parent!=7, template!=admin, sort=-modified") as $p){ echo "<p>{$p->modifiedUser->name} updated {$p->title} " . wireRelativeTimeStr($p->modified)."</p>"; }

Thank you for the thorough testing and detailed reporting - really appreciate it. I had never tried the combo of importing that blog.zip I posted and then importing some WP posts, so I just gave it a go and found it worked flawlessly, except for assigning tags and categories to the posts - there must be a conflict with those fields already being created from the import of Ryan's blog.zip This sounds mostly like your first attempt, except that for me, I didn't get the selector operator warning and the post dates were imported correctly. Can I ask what you mean by: "Page tree as before"? I am going to see what I can do about the tag/category assignment to posts problem when using Ryan's blog profile and on subsequent install attempts. Once I get that sorted, it would be great if you can test again and make sure debug mode is on to see if we can get some more info on that selector error. I am not sure why the post dates aren't importing for you, but I'll take a look at that too. Stay tuned

Try this: $discuss_logo = $item->discuss_image->size(200,200, $image_options);

Just to clarify, it is the google map itself that is not working - the issue is not specific to this PW fieldtype. Take a read of the comment by patrickjdempsey in this thread: http://forums.mozillazine.org/viewtopic.php?f=38&t=2440619

Sounds like a cool concept - I'll have to take a look

Check out the Migrator module: https://github.com/adrianbj/ProcessMigrator At the moment I still strongly recommend testing the migration to a test PW installation before running the import to your production install, but it has all sorts of options for migrating content from dev to live, including a new feature during export which allows you to export only those pages that have changed since a specified date/time.

Minor, but important fix just committed to prevent domdocument from adding docytype, html, and body tags to RTE fields.

I have actually always just used what Soma suggested here: https://processwire.com/talk/topic/3992-how-to-check-if-a-module-is-installed/?p=39141 $modules->get("Your Module"); and it always seems to work, but then I don't really understand the need for the getInstall() method.

A little self help tip Right click on the button and choose Inspect Element and then see what css is applied to the button. As for grouping inputfields, check out Field type FieldsetOpen: https://processwire.com/talk/topic/176-fieldsetopen-fieldsettabopen-%E2%80%93-what-is-it/

Hi Ralf, The only thing I would say is make sure you trust your site content authors/editors before giving them TextColor control. Things can get very ugly very quickly

Looks really nice! I know your name is videokid but one of my pet peeves on websites is auto playing videos and audio. Turning that off would be my only suggestion!

Sorry, not sure how I missed that If you right-click > inspect element on the slider you'll see it is using css from: /wire/modules/AdminTheme/AdminThemeDefault/styles/main-classic.css so try including that as well. EDIT: PS I forgot to welcome you to PW

Despite the name "image", I am guessing it's "Maximum Files Allowed" setting is set to: 0 If it is set to one, then what you are doing should work, unless you have a $p->of(false) in there somewhere which would make the field behave as an array again. Either way, try this and it should work: $socialphoto->image->last()->description = 'Oh haaay';

Thanks @totoff, We have both made a few enhancements in the last couple of hours, so be sure to grab the latest versions of both modules. There are still a few things to iron out, but it's starting to look really good - hopefully in the next couple of days we can get the final tweaks sorted. Back to real work now

Seems like you are missing this: /wire/modules/Inputfield/InputfieldDatetime/InputfieldDatetime.css

Maybe I am not understanding properly, but in the template Access options you can check "Add Children" while leaving "Edit Pages" unchecked. I do this all the time to allow users to create new articles, but not edit the main article page.

We all go through this. "Pages" really are the best way to set up select field types. Here is some reading to convince you: https://processwire.com/talk/topic/2296-confused-by-pages/ https://processwire.com/talk/topic/5899-select-how-to/?p=57652 https://processwire.com/talk/topic/2297-creating-a-simple-select-please-check-for-accuracy/?p=21428 http://wiki.processwire.com/index.php/Select_Field I actually think I am missing the most important post - maybe someone else will find it and contribute. And, if you finding creation of these too laborious, try out this module: http://modules.processwire.com/modules/process-page-field-select-creator/

Yeah, I didn't know about how to make a configurable module back then

You can provide the error like this: if(!class_exists('Imagick')) { $this->error(__("This module requires the php imagick extension, but it is not installed")); } You could use this in the install routine of the module. I am not sure how to check for ghostscript. A hacky way would be to include a tiny PDF with your module and run the thumbnail generator on it. If the thumbnail is created, then it must be available. If not, return another error. The cropbox setting is important because PDFs can have a crop applied to them and if you don't set this, the thumbnail you generate will show the entire contents of the page, not just what is visible in the PDF. The colorspace_rgb is just to convert colors to RGB. The IM delegates settings I linked to are not something you can do with the module, but I think they are worth noting in your readme. Without those changes, some colors can turn out pretty fluorescent. Of course many thumbnails will look just fine depending on the colors used. Just an FYI - I created a similar module a long time ago that I haven't ever got around to finalizing for release: https://github.com/adrianbj/ProcessPDFImageCreator The main difference with this one is that it creates large preview images for every page of the PDF and then relies on PW to create the thumbnails as requested from these large images. It's not beautifully coded, but you might find something of interest in there. The reasons I never released were because it can be slow to count the number of pages in a PDF (which I wanted to store) depending on what other libraries are available on the server, and also the generation of images for a document of a couple of hundred pages can take a long time and I never got around to setting up something so that this is done in the background after page save.

Sorry I quickly ready your title and not really the description. It's actually really easy, but I think the instructions here: http://processwire.com/api/fieldtypes/repeaters/ are slightly wrong in that they say to save $page. This works: $socialphoto = $p->social_photo->getNew(); $socialphoto->save(); $socialphoto->date = '2013-05-16'; $socialphoto->image->add('http://localhost/pw/site/apitest/test.jpg'); $socialphoto->pinned = 1; $socialphoto->save(); So the things I changed are: Using $p instead of $page as it's not good practice to overwrite $page as it refers to the current page I am saving $socialphoto and not $page/$p You already figured this out, but you need to save straight after getNew() to be able to add items to the repeater I am using a valid date format - maybe your format will work if that is how you have the field configured - I have never really tested those configs Hope that helps.

This is what you need: https://processwire.com/talk/topic/5397-assigning-fields-to-repeaters-with-the-api/?p=52123

I have just committed a couple of updates that take care of an image filename issue when using the Wordpress import, and more importantly it now completely honors the modified user and modified date values from the original source, whether from Wordpress or another PW installation.

Nico - yeah, I get what you meant now - I thought you were referring to the Parent Page setting during import. I was actually just looking at the category and tag field input tabs and seeing the parent set to: /trash/1297_blog-test-3/ Categories Which as you say, is exactly why they aren't working when you run an import, then trash the entire blog page tree and import again. I should be able to to add a check in though to replace the parent if it has a status that flags it as being in the trash. I think that should work fine.

Ok, I just tested the "Replace" option and it doesn't solve the tags/categories issue, but if you manually remove those two fields from the post template and then delete them, the next import works perfectly with tags and templates assigned to posts as they should be. I will try to figure out why and see what I can do to avoid the need to do this.