adrian

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

I am thinking this might be a Windows vs Unix slash/path issue, but I am not exactly sure where. Does xammp translate forward slashes to back slashes for disk paths - is that why the results you just showed have forward slashes? But then if that was the problem then you'd think it would also affect the template files and images in the zip as well. Maybe it's time I set up an xampp installation on my Windows VM. Please grab the latest version from Github and try adding the following after line 2120: error_log('current:'.$file.'|new:'.pathinfo($file, PATHINFO_BASENAME)); and let me know what ends up in your log. In other news, the latest version should now solve the role issue that @tobaco was having with system created pages and also it should now work properly when attempting to migrate a site with the Home page set as the parent. You can now import Home into Home and it should work properly, allowing full migration of an entire site's page tree - at least something productive came of my efforts today

Sorry to hear that - can you please try this after line 318: print_r($allfiles);exit;

@tobaco - thanks for the feedback - obviously I need to look further into users/roles migrations. Your exported json is showing that the home page is created by a user named "cms" with no role. Looking at the created_users_id for the home page, this makes sense. I'll try to work on this shortly, along with the rest of the multi-language issues. @NooseLadder - thanks for that - I have pushed an update which I hope will fix things for you - can you please let me know how it goes.

Not sure but is that selector in a showIf dependency for one of the fields in the page's template?

Is the new page being created ok? I see that you are not defining a title for the page.

I don't think I have ever needed more than a standard mysql text field. 65,000 bytes is a lot already. Jeez, that's the same as the total RAM of my first computer Type | Maximum length -----------+------------------------------------- TINYTEXT | 255 (2 8−1) bytes TEXT | 65,535 (216−1) bytes = 64 KiB MEDIUMTEXT | 16,777,215 (224−1) bytes = 16 MiB LONGTEXT | 4,294,967,295 (232−1) bytes = 4 GiB

And the mytemplate template definitely contains a field called documents?

@tobaco, I haven't looked into the language issue fully yet, but had a quick look at the role error you are getting. For some reason your cms user doesn't have a role defined in the json file. From what I can tell, it is not possible to save a user in PW without at least having the guest role assigned, but could you please look at that user and let me know the role setup for it? Another role issue I noticed has shown up because you are migrating your entire page tree, which includes the default 404 page. The created_user_id for this page is 3 which is not actually a user. I am going to check with Ryan if there is a reason for this. Regardless, I should be able to implement a workaround for this easily. One nice thing from playing around with your JSON file is that the FieldtypeTextareas field appears to have been imported correctly - I hadn't tested any of the new Profields with Migrator yet, so this is an encouraging start

What do you see in your 1022 folder if you move the exit down to after line 317 and then again after 318? I am assuming there is something in the create_zip function that isn't working on your local install. Maybe it's the ZIPARCHIVE::OVERWRITE?

Try replacing: $users->delete($u); with: $this->users->delete($u); Also, turn on debug mode so you get some error reporting - these should be showing up.

The first error I see is: $this->$users->find It needs to be: $this->users->find EDIT: Sorry, I loaded this thread, then got distracted and was beaten to it

Thanks for the fix Ryan - the noPermisionCheck should come in quite handy in other situations too As for the "it" GET variable. If I go to: http://pwtest.dev/service-pages/?name=about with the following for debugging: print_r($k);echo $_GET['it']; foreach($k as $name) { //if($name=="it") continue; I get: Array ( [0] => it ) <br /> <b>Notice</b>: Undefined index: it in <b>/Users/ajones/Sites/pwtest/site/modules/ServicePages/ServicePages.module</b> on line <b>175</b><br /> Array ( [0] => name ) <br /> <b>Notice</b>: Undefined index: it in <b>/Users/ajones/Sites/pwtest/site/modules/ServicePages/ServicePages.module</b> on line <b>175</b><br /> {"errors":["Field 'it' is not allowed in queries"]} so $_GET['it'] doesn't exist, but it is part of the $k array.

Can you please clear your browser session data and then run an export on your xamp server and after the file has downloaded, reload the page and open up: Debug Mode Tools > Session and look for an entry like this: jsonFilename | /Users/xxxxxx/site/assets/files/1006/data.json Keep in mind the 1006 will be different.

http://validator.w3.org/check?uri=http%3A%2F%2Fanswerhub.com%2Fblog&charset=%28detect+automatically%29&doctype=Inline&group=0 Error #4

Glad to hear it's not Migrator I am running it locally and it works fine. I wonder if it's an issue with: addFile (http://www.php.net//manual/en/ziparchive.addfile.php) What version of php are you running?

Can you please try exporting a page tree that does not include Home as the parent? I think maybe there might be an issue with selecting Home as the parent. It works for me, but just trying to narrow it down. Also, are you running multilanguage page names?

Yep, that is the latest. Does exporting a different parent make any difference to having a data.json file in your zip?

@tobaco, Thanks for the json file. I will take a look at the language/role issues when I have a little more time - sometime early next week. @NooseLadder Can you please make sure you are running the latest version of Migrator - I think the fix I made yesterday should take care of the issues you are having. Although it is surprising to hear that you don't have a data.json file in your exported files.zip - I have never seen that before. Does it make a difference if you choose a different parent page when exporting?

Well how about a separate query like: $locations = $pages->get("/locations/"); foreach($locations->children() as $state) $StatesHTML .= '<option value=".$state->name.'>' . $state->title . '</option>'; } Maybe this is still getting duplicates, but I would think from your page structure, there should only be one Statename for each state, with multiple Location Names children below each Statename

Good point - sorry I didn't really think through your scenario completely I don't think there is a way for unique() to work for you in this case. I am curious how the states are referenced to the locations. Do you have a page field of states that is selected from when defining locations, or are they entered into a text field? If the former, then you already have a list of distinct states to pull from. I feel like this might be a page/template structure question, rather than a need to strip duplicates afterwards, but I think we need more info on how locations are defined to be sure. Once hack you can do is populate a simple array of state names ($state_names) as you iterate through your locations loop and then do: if(!in_array('nevada', $state_names)){ $StatesHTML .= '<option>' . $Location->Location_State . '</option>'; }