adrian

@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>'; }

Not much more to say really From the docs: $a->unique() Return a new WireArray that is the same as $a but with no duplicate values. So you can get an array of pages using any PW selector and then remove any duplicates using unique()

I am sure teppo will have a log reset button done for you in no time, but you could always use PHPMyAdmin to remove all the rows from the process_changelog database table.

Did you see my updated post with second screenshot showing the profile page in modesta? Maybe there is something weird on Windows?

This is expected behavior for TinyMCE. If you click the HTML button and cut/copy/paste everything in there it will work fine.

Here's my Profile page:

You might want to have a look at this alpha module from Soma: https://github.com/somatonic/BlocksContent There is some discussion about it here: https://processwire.com/talk/topic/4189-flexibility-in-page-design/?p=45437 You might want to browse further back in that thread too. One other possibility might be the new PageTable field type which allows for adding multiple content blocks (you can define multiple templates) that can be sorted by the user, so you could easily have a separate Add button for each of your content types - I think this could be pretty effective actually. There isn't any real documentation for PageTable yet, but you can start reading here: https://processwire.com/talk/topic/6417-processwire-profields-table/page-2#entry62890

You shouldn't have to do this unless you are worried about the login screen which will always use the default theme (if available) since the theme is controlled on a per user basis.

What about $Locations->unique(); http://cheatsheet.processwire.com/?filter=unique

Ok, just to follow up. I have fixed the issue with the error when using the "Edit Imported Content" option - stupid oversight on my part when I added a cleanup routine in a recent update. Should be fine now I can't replicate the error around roles so it would be great to have your exported json if possible. I also tried to look at the language page names issue, but when I tried to leave the default name blank I get an error saying that it can't be blank, but I think I must not be understanding this. Could you please outline the steps to set up a site with multi-language page names with a blank default name so I can test this. Thanks again for your feedback with this.

Not very helpful I know, but it's working for me on 2.4.5 - I was running the initial 2.4.5 from a few days ago and just updated to the very latest commit and still working fine.

Oh I see, so your selector is relative to PageA and PageB as the current $page ? In that case this should work when run from PageA or PageB: foreach($page->children() as $c){ or foreach($page->children("template=basic-page") as $c){ Do the "Child Pages" ever get loaded by their URL? If so and because they have the same basic-page template, you need to do something else to prevent them for looking for child pages. You could simply do: if($page->numChildren()>0){ foreach($page->children() as $c){ } Or perhaps it would actually make more sense to have a separate template for the PageA and PageB parents? Lots of options really

Well I think this should work: foreach($pages->find("template=basic-page, parent!=/") as $c) That will get all pages with basic-page template but without home (/) as their direct parent. Of course this won't work if you end up with further levels of child nesting. But right now, Page A and Page B should be excluded by this.

Sounds a little confusing - all pages, except Home, are child pages of something, so it all has to be relative to the parent page you're interested in. If you know the parent you can do: foreach($pages->get("parent=xxxxxxx")->children() as $c){ Maybe if you provide the page tree structure for us we can help figure out an efficient way.

tobaco - thanks for the comprehensive report. I have tested the module with standard language support, but never with "Languages Support - Page Names". Sorry, multi language stuff is not something I ever use, so I am a bit ignorant of it I'm afraid. Is it common practice for the field for the default language to be empty by default? Not sure about the roles issue - creating new users and roles this is a relatively new feature for Migrator - I'll need to see if I can replicate the error you got. Would it be possible to send me the json file from your export so I can see how the role was defined during export? I'll look into the Edit Imported Content issue - again that is a relatively new feature and I think some more recent changes might have broken that - hopefully should be an easy fix - just a session variable issue.

NooseLadder - the link to the module the horst provided is designed primary to migrate page content and as a result it also grabs changes to fields and templates that are used by these pages. You can use the "Changes Since" option during export to grab all the changes to your site since that date/time and things should work as expected. The one thing thing that might seem confusing is that if you only make changes to template or field settings, you still need to export a page/pages that contain these templates/fields to capture these changes. Mindplay's work in progress module might also be useful here: https://processwire.com/talk/topic/2117-continuous-integration-of-field-and-template-changes/ although his is only about field/template changes. Personally I can see using both options depending on the needs. I still don't consider Migrator release worthy, so you should definitely test the import to a test PW installation before trying it on your live site. I do hope to get it finalized sometime in the next few weeks or so..... There are some small outstanding issues (like template context field settings) and also I need to test support for all the new pro fields which I haven't done yet. One thing I really need is help testing it

I can't tell for sure what the problem is, so I think you should try to simplify things down and debug each variable to figure out where things are going wrong. Bring it back to this: foreach($page->children("category=$input->urlSegment1") as $preview){ echo $preview->title; } Things to check are that the name of the category field is correct. Remember this must be the name of the field that is used in the template on the current page and not the name of the parent page that houses the child categories. Also try echo'ing $input->urlSegment1 to make sure it actually contains the name of the category you are looking for. If not you can firstly replace this with a hardcoded category name to make sure your selector is working, then track down why $input->urlSegment1 is not being populated. Hope that helps to get you sorted.

Sorry, when you say: do you mean that the rss feed itself is not updating, or that IFTTT is not sending the changes to FB?

Well Ghost gets great reviews: https://ghost.org/ It's free if you're selfhosting. But then again, you could also bootstrap PW into the site and use k's blog module still

Is this a trick question http://modules.processwire.com/modules/process-blog/ http://modules.processwire.com/modules/blog-profile/

Just a quick reply to let you know that it's already possible to upload an image to processwire from an external URL using the API. It is as simple as: $page->images->add('http://www.mysite.com/images/image.jpg'); Of course there is more work needed for doing this from the admin. This post might prove helpful: https://processwire.com/talk/topic/417-extending-image-field/

Sorry - you're right - I was kinda wondering why your question was in this thread - I didn't think it would make a difference if it was an ordinary images field or a CropImage field, but it does I am sure apeisa will get back to you shortly on this.

Default View set to grid works here and the toggle at the top right of the field when editing a page also works just fine. There were some updates to this functionality introduced in the dev version fairly recently, but that was to do with when there was only one image. I don't think anyone has ever reported the default view not working before.