adrian

@tobaco - please try the latest version - I have made a lot of fixes and I now get a fully(?) working import of your json file! Firstly, please run the export on your original site again first as I made a couple of fixes there. Then test on a clean PW install and use the REPLACE option so that your import will completely replace the existing pages from the default PW profile. Please let me know if all the content appears to be populated as you expect - there are lots of fields with empty values in the json export, but I am not sure if that is correct or not, so I'll need your input on that. There are still a couple of issues: Using the replace method a second time results in out of memory errors - I think it's the recursive deletion of the content from that repeater field I have temporarily disabled importing content for image fields inside repeaters as that is causing errors with your import. I am pretty sure images in repeaters worked fine in my previous testing, so I am not sure where that problem is yet. Thanks again! PS The latest version handles installation of all required language modules and gracefully warns of missing language packs and lets you install them as needed. PPS - if you are doing lots of testing and need to be able to revert to a fresh install regularly, it pays to fire up PHPMyAdmin and create a clean copy of the DB after you have installed PW (or perhaps after you have also installed all your required modules) so that you can simply drop the actual DB and create a new copy from the backed up copy. You might be already aware of this approach, but it's a huge timesaver when testing things like this.

For sending one message to one user at a time with a download link should be fine via PHP mail(), however, to reduce the potential spam score of the message, it is often preferable to send via a properly configured smtp server, which is where these modules come in: http://modules.processwire.com/modules/wire-mail-smtp/ http://modules.processwire.com/modules/wire-mail-swift-mailer/ I can't see any real reason to use an external service in this case.

Just wanted to add that I have the same problem on PW 2.4 release and 2.4.5 - it happens every time I change a field type to it's Language version. The only fix seems to be to manually create the dataxxxx field in the DB.

Unfortunately, the built-in search on this IP.Board forum is not very good. We all use Google site search: site:processwire.com/talk "redactor"

Hi Soulsliver - just a quick heads up - this has been discussed before: https://processwire.com/talk/topic/1964-redactor-wysiwyg-editor/ I don't remember the outcome, but you might be interested in reading through that thread.

Might be a stupid suggestion, but has he tried clearing session data from FF - I would think that should do it.

@Ronnie, I should also mention that you do not need to import the blog.zip file. You can use Kongondo's Blog module (http://modules.processwire.com/modules/process-blog/) as the base, or just import your WP xml and manually create the templates to suit your needs. If you decide to use the Blog module, here is a screenshot of the MigratorWordpress config settings that are required:

@Ronnie, Sorry about that - it was a simple fix - please try the latest version on Github and let me know how it goes for you. You might be still be affected by an outstanding multi-language issue but hopefully I can have the fixed soon. @tobaco Still have some issues with the language error and also trying to improve the Replace option - need to sort out recursive deletion of existing pages to work better, but I have fixed a bunch of issues around reporting/automatic installation and proper configuring of Inputfield types that are needed by the imported fields - for example, the icon select field now properly detects the need for installing InputfieldSelectMultipleTransfer and then uses it once installed. This should work for all input field types now.

Hi Ronnie - I am taking a look at this now - it is possible I broke something with the MigratorWordpress in my recent changes to Migrator. I see that you also posted over in the Migrator thread, so I'll respond there when I have an answer/fix. EDIT: Fixed in latest version on Github

Joss, I think MigratorWordpress is pretty close to handling this out of the box - I will need to add a function that scans links from embedded thumbnails to large images and have those added to the PW page as well as the thumbnails which should already work. Then you'd just need to make sure the gallery classes and lightbox scripts are available on your PW site so that the the RTE embedded thumbnails are styled correctly.

Joss - this is something we should be able to handle with the Wordpress migrator - how are your galleries set up? A particular plugin? At present it handles images embedded into the WP RTE - these get imported to a PW images field and embedded back into the post. Anyway, let us know how your galleries are set up and we'll see what needs to be done to make the migrator work.

I should remember to just always look at the PW source before asking a question Putting the following right after I delete does the trick. Still it seems clunky to have to do this - is there something I am missing? $item->status = Page::statusDeleted; I take that back - I don't think it works at all EDIT: Can anyone see why the delete method has to throw an exception when a child page is not deleteable. Why not just issue a warning and continue with the next child?

Hi everyone, I know that: $this->pages->delete($parent_page, true); mostly works, but the problem is when one of the child pages is not deletable - you get an error and the script terminates. So I thought I'd write a custom approach to delete pages by order of number of path segments, so that children are always deleted before their parents, like this: // create empty page array $res = new PageArray(); foreach($pagestodelete as $item) { // temporarily add pathsegments property to items $item->pathsegments = count(explode('/',$item->path)); $res->add($item); } //sort based on their level in the page hierarchy so we can delete children before their parents $items = $res->filter("sort=-pathsegments"); foreach($items as $item){ if($item->deleteable()) { $item->delete(); } } This seems like it should work, but the deleteable() check is not excluding pages as it should, so I am getting a can't be deleted error. Also, even though all the children of a page have been deleted first, I still get the "Can't delete Page $page because it has one or more children" error. Maybe I am going about this all wrong, but my brain has stopped working now! Thanks very much to anyone with any ideas

Might be simple, but just because you can doesn't mean you should

Very simple but effective forum module for PW: http://modules.processwire.com/modules/discussions/

Thanks again for testing. I should have mentioned to try on a clean install. I believe the "This page may not be deleted" message is referring to various system pages. The replace method deletes all children of the Import Parent Page before creating them again. Append or Overwrite doesn't do this. This is not an issue when migrating page trees below home, but if you choose home, then http404 and all the pages under Admin are selected, so obviously I need a check to deal with system pages that are not deleteable to prevent the error. I'll also look further into the icon_select error - I saw this a few times too - for some reason that page field is not being fully configured during the import, even though the other page fields are importing perfectly. I am glad to see the 196 pages imported though - that looks like the full set I don't really have any time for this for the next few days, but hopefully I can get these things sorted out after that.

@tobaco - that is one serious test case of an import file It's been a mission, but I have narrowed down the problem to the "content_variants" repeater field. If you use the Edit Imported Content option and remove that field from the list, it imports everything else just fine. See image of page tree Migrator normally works just fine with repeater fields, but I see that you have a page field in the repeater field's template, which is something I haven't tested before, especially together with the muit-language element. Not sure exactly what the issue is yet, so I need to investigate more. For now, I'd appreciate it if you could confirm on your end that the import works if you omit that repeater field during the import, just so I know we are experiencing exactly the same results. You will need the latest version of Migrator from github as I had to set PHP's max_execution_time because your import was so complex. Thanks for continuing to help out with this - getting real life tests like this is very valuable. @kongondo - thanks for offering. You are right, this thread is a behemoth - I will start a new one as soon as I am ready to release, but for now to test: Grab the module from: https://github.com/adrianbj/ProcessMigrator and install Make sure debug mode is on Run the module (Setup > Migrator) Choose Export Choose a Parent Page - to keep things simple, maybe something like the default PW's About page Export Check that the downloaded zip file contains a data.json file Let me know if you get any path related errors like @NooseLadder If you're feeling energetic, comment out line 335: //unlink($zipFilename); Run again and find out the id of the assets/files folder where the zip is stored. It should match the id of the Migrator Admin > Setup > Migrator page id, but some reason @NooseLadder is seeing it in one of his normal page id folders. Seems like it's a windows/xampp issue. Thanks so much!

Details tab of the RTE field > TinMCE Advanced Config Options > Third Party Plugins

@tobaca, I just tested the json file you sent me last week and got the same error. If that is the file you are still using, then that is the reason. You need to export again with the new version of Migrator so that the json includes the new multi-language information. Could you please try that and let me know how it goes. If it still doesn't work, please send me your newly exported json file. Also, I have a think about pointing to an already uploaded file. @NooseLadder - that is definitely strange - it is making me think that: $this->page->filesManager()->path() is somehow not working for you because it doesn't make any sense that this is not pointing to Migrator's admin page id. Anyone else out there running xammp on Windows who feels like testing this ?

I have just finalized support for all Profields field types: Table, PageTable, Multiplier, and Texareas Please check out the latest version and test away. I think this completes enough functionality now that I am ready to release this to the modules directory once I get some feedback to verify that multi-language functionality and the Profields additions are working well. The official release will probably still be "alpha" for a little while, but hopefully getting it in the modules directory will get some more people testing!

Sorry - I haven't actually implemented your blog profile on a site yet, so I forgot about that! In Wordpress regular bloggers can't change the author - it requires an editor (or maybe admin, I don't remember) level permission setting.

One nice thing that Wordpress has is the ability to change the author of a post from the person who is creating it and logged in. Maybe an author PageField that allows you to select from other PW users that have a blog author role, or something along those lines?

I think the key thing is permissions on the assets folder - make sure that is writeable.

Glad to hear the migratorfiles temp folder is being deleted as expected. I am also not sure why 1022 contains some images. The numbered folder that migratorfiles should be saved to is the one associated with the Migrator module page. If you browse your page tree: Admin > Setup > Migrator > edit that should show ?id=xxxx The id should be the folder where migratorfiles is being created. Do these match, or does 1022 really belong to another page in your site's tree?

Looks like I have the same thing going on: https://processwire.com/talk/topic/6790-switch-to-language-field-type-errors/ I just did some more testing and discovered the problem appears on: PHP 5.3.28 MYSQL 5.6.13 but not on: PHP 5.4.30 MYSQL 5.1.73-1