adrian

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.

Thanks for the report. Not sure why the categories are not being assigned to your posts. I am getting mixed success with this - on a clean install it always works, so I am wondering if it's an issue with the fields already existing. Have you played with the Import Type options? I wonder if maybe using "Replace" might work? As for the dates being today - is that the modified date or the created date? The created date works for me, but I still need to fix the modified date - unfortunately when PW saves the page, the modified date is instantly changed. Quiet mode saving works for the created date, but not the modified date. I might need to do this using SQL. Thanks for helping us to debug this.

I think Nico is working on a few more tweaks to this as we speak. Firstly, MigratorWordpress is not designed to give you a fully functioning blog in that it doesn't create a template to render your posts. You could use the template from Ryan's blog profile though and depending on names of fields it will work, although I haven't compared these to be certain. I just tested Nico's new version with a recently exported XML from the current version of WP and it works perfectly. All the tags and categories were created, the page fields created, and they were assigned to each post correctly. The only current issue I had was some issues with html and body tags making it into the body field of the post (which affect the viewing in edit mode), which I think Nico is working on now. One thing to be aware of is the "Parent Page" setting when importing. If you are testing and trashed a previous import, this will load up that original page from the trash by default. I might need to consider doing a check to make sure this can't happen. Also, out of curiosity, are you selecting your Home page as the parent, or a child of this? My successful test this morning was to a child page - eg: Home > Blog

Firstly, if you want timepicker support, you'll need to use option 1 or 3 for: $field->datepicker https://github.com/ryancramerdesign/ProcessWire/blob/03387f8283d518e9cc405eff8f05cd6a5bf77c4c/wire/modules/Inputfield/InputfieldDatetime/InputfieldDatetime.module#L24 Then to see if they are being loaded, just view the page source of your page once it's loaded in the browser. If those scripts are not there, you can do this: $config->styles->add("/wire/modules/Inputfield/InputfieldDatetime/InputfieldDatetime.css"); $config->scripts->add("/wire/modules/Inputfield/InputfieldDatetime/InputfieldDatetime.js"); $config->scripts->add("/wire/modules/Inputfield/InputfieldDatetime/jquery-ui-timepicker-addon.js");

Make sure these are getting loaded: http://pwempty.dev/wire/modules/Inputfield/InputfieldDatetime/InputfieldDatetime.css http://pwempty.dev/wire/modules/Inputfield/InputfieldDatetime/InputfieldDatetime.js and if you ever want the time picker as well: http://pwempty.dev/wire/modules/Inputfield/InputfieldDatetime/jquery-ui-timepicker-addon.js

Looks great! A few suggestions if I may I think you should note somewhere is the requirement for imagemagick, ghostscript, and the imagick extension. Also, do a class_exists check on imagick and fail with a nice error if it isn't available. Also, you may want to add these lines to your code: $imagick->setOption("pdf:use-cropbox","true"); $imagick->setColorspace(Imagick::COLORSPACE_RGB); Also, if you find that the colors in the image are not matching those in the PDF, this gives instructions on the changes that need to be made to your imagemagick delegates file: http://www.lassosoft.com/CMYK-Colour-Matching-with-ImageMagick

The easy way out would be to generate an RSS feed of PW pages: http://modules.processwire.com/modules/markup-rss/ http://modules.processwire.com/modules/markup-rssenhanced/ and push them to FB, Twitter etc using any number of services: https://dlvr.it/ https://hootsuite.com/ or my current favorite - IFTTT https://ifttt.com/recipes/search?q=rss+to+facebook&ac=false https://ifttt.com/recipes/search?q=rss+to+twitter&ac=false

totoff, Thanks for the feedback. I have just taken a look at the test wordpress xml file Nico and I were testing with and compared it to one I exported from a different WP blog and there are differences related to tags and categories. The test xml we were working with definitely imported both tags and categories correctly and assigned them to posts with an ASM select field perfectly, so I am sure we can get this sorted out. I will probably continue the discussion with Nico via PM, but hopefully we'll get back to you in the next couple of days with a solution. As far as I know you are the first person to test the WP import functionality so apologies for it not going fully as expected.

Thanks for the report. I have pushed another update that makes the automatic link rewriting honor the template/page restrictions. I think this is beneficial as I can see users wanting to have all functions of this module's only applied to a specific section of their site - maybe a blog or news articles section or the like.

It's a built-in PW field in the Pages DB table, along with: modified_users_id created modified status sort etc...

Turns out the issue with the site map page is not due to the rewriting of links and is actually an issue if you try to render that page from another page, completely independent of this module. I am using render() when the "Load" option is selected, hence the problem. I will still see if I can find a way around this, but for the moment I have set the load option to ignore the site-map page (instead, it defaults to redirect). I have pushed this latest version with the custom URL rewrite option to Github and updated the modules directory. Let me know how it goes for you.

Is this any help: http://modules.processwire.com/modules/custom-page-roles/

You could try Nico's new Wordpress Migrator module: https://processwire.com/talk/topic/4420-page-list-migrator/?p=62349 https://github.com/NicoKnoll/MigratorWordpress I would thoroughly recommend trying first on a test PW install to make sure everything works as you expect.

Well I have a version for you to test. It has a new option called: Rewrite Links and a companion "Rewrite Format" in the config settings. This way you can determine how the urls will be rewritten. I have tested with: /{$page->name}-{$page->id}/ and /{$page->id}/ I attached this version here as I don't want to push it to Github yet. It mostly seems to be working fine, but there is a problem when loading the default PW sitemap page. The recursive function for generating the page links is causing some major problems, so please don't try that. Let me know if you think this approach meets your needs though and I'll figure out how to fix the bug and maybe consider a more efficient way to do things - I never planned this module to have this functionality, so there might be a better approach. EDIT: Please keep in mind that I mostly agree with Pete - long friendly URLS are a much better default. I think the name-id combo isn't a bad idea because it creates a permanent link even if the page name changes, but the id on its own seems like a bad idea for a default URL. The module's original goal was just to allow for shortlink alternatives, but not replacing the default link.

Check out the RewriteBase options in the .htaccess file. My guess is that you need to uncomment the first option.

I have added a new option called "Changes since" in the export dialog. This is very basic at the moment and put together quickly, but it allows you to specify a date/time which will limit the exported json to only content that has changed since then. It's certainly not the most efficient approach in that it will export the entire page, even if just the content of one field has changed. I don't expect this should be much of an issue, but it might seem wasteful if you have a page with a lot of images or files, but you only changed one small text field, because it will copy all those images/files again. Unlike most fields, image/file fields have created/modified fields in the DB tables, so I should be able to improve this fairly easy - something for the next version

Well you might have already sorted it out, but it's hard for us to help without seeing the section of code that contains the getRandom(). This should work: echo $testimonial_image_page->images->getRandom()->url; If it doesn't and you get the same error, then please check to make sure that the template of these pages has a field called "images".

Thanks for the report - I have fixed this bug and pushed it to Github. Let me know if it works for you now. I agree with Pete about not generally wanting to have links go to ID based URLs though. My module is just meant to be an easy way to provide a shorter link, or perhaps a human readable link with the ID appended, like: http://www.mysite.com/article/this-is-the-full-title-1058/

Thanks Soma, That is certainly cleaner and simpler Only thing I needed to add back in was: $f->datepicker = 3; And in case someone is wondering about the 3: https://github.com/ryancramerdesign/ProcessWire/blob/03387f8283d518e9cc405eff8f05cd6a5bf77c4c/wire/modules/Inputfield/InputfieldDatetime/InputfieldDatetime.module#L24 const datepickerNo = 0; // no datepicker const datepickerClick = 1; // datepicker on click const datepickerInline = 2; // inline datepicker, always visible (no timepicker support) const datepickerFocus = 3; // datepicker on field focus I ended up in one of those situations where I was trying to add attributes to match the generated source of a working datetime field, rather than figuring out exactly what PW needed to set them itself. Can I blame it on the fact that it was 1 am

Actually thanks to the genius of WillyC, that is pretty easy. Well I guess it's really Ryan's genius, but Willy's post has been a classic for quite some time! $pages->addHookAfter('Page::path', null, 'hookPagePath'); function hookPagePath(HookEvent $e) { $page = $e->object; $e->return = "/$page->id/"; } That will rewrite all your links, but you'll still need my module to make the links actually work. I am actually thinking this code might be a nice optional addition to my module. Of course you can put a conditional "if" to only return the id for particular templates or whatever if you need. EDIT: There actually appears to be a conflict between the two - stay tuned - I'll take another look at this tomorrow

I guess I don't really know exactly what you want. That module will allow you to link to any page using its ID. Are you want to have internal links in an RTE field be ID based? If that's what you want you could create a simple text formatter module to change the links. Sorry, I am probably missing your point still. Could you explain your scenario in a little more detail. I am sure there is a way to achieve what you are looking for.