adrian

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

@NooseLadder - thanks so much for your help with this. So if things are working with that file_exists check removed then I think we can assume it's a windows path issue. Weird that the addfile to the zip works, but file_exists fails. I am curious about the Directory not empty warning. Does the migratorfiles directory actually get removed? Again, this seems like a windows path issue because I am using a recursive directory delete function and it works here. I really might need that windows xammp setup to get all these sorted out. But for now, I have removed the file_exists check from the latest committed version as I don't really think it should be necessary as the $files array shouldn't contain any files that don't exist anyway. Another big enhancement this morning - I think all multi-language features should now be working! @tobaco - would you please check to see if the latest version fixes all the issues you were having with multi-language page names etc?

Hi guys - well I am still a gumby at all things multi-language so maybe this is my fault, but I am working on the multi-language support for Migrator and came across this. After installing all the language related modules, I tried to change the field type of a textarea field to TextareaLanguage and got these errors: Session: Field type change failed. Database reports: SQLSTATE[HY000]: General error: 1364 Field 'data1021' doesn't have a default value Session: Error changing fieldtype for 'summary', reverted back to 'FieldtypeTextareaLanguage' Then I cound't edit the field at all due to these errors: TemplateFile: SQLSTATE[42S22]: Column not found: 1054 Unknown column 'field_summary.data1021' in 'field list' I simply added the data1021 field to the DB table and everything looks to be working fine, but I think this is a bug. Anyone? EDIT: We can continue this over here: https://processwire.com/talk/topic/5286-switching-fields-to-language-fields-produces-fatal-errors/

Another significant update this morning which corrects a major omission in critical functionality. Migrator now handles migration of template context field settings. Now to tackle these new multi-language issues

Thanks again. If nothing was logged that suggests that $valid_files is empty, or that create_zip never gets called for the json file, but I can't see how that would be possible. Would you mind playing around a little more inside that create_zip function and try to figure out the content of $valid_files when trying to add the json file to the zip. Try this after 2108: if($filetype == 'json') error_log(print_r($valid_files, true)); Also, I see that you edited your post since initially posting. Those errors you did get are strange - seems like you might be trying to export a page with no template. Do you have any ideas on those errors? Thanks again for your help with this. I hope it doesn't turn out to be some version specific bug in xammp