adrian

Hi loook and welcome! Have you seen this posts on PW and nginx? http://processwire.com/talk/topic/5733-official-nginx-support/ http://processwire.com/talk/topic/275-processwire-on-nginx/ Maybe something there will help you get going.

I love managing linux servers, and I have wanted to run a linux desktop for a long time, but Adobe has been the stumbling block for me. Illustrator is the main issue, but InDesign and Photoshop are also key things I can't really do without. It's a shame really because I think there are decent linux alternatives for just about everything else.

Ok, I have fixed another round of bugs, including one weird one getting an "Unknown column 'field_images.modified'" error when importing a page tree into a brand new install before ever having viewed a page on the site. Getting off track, but the issue was due to the need to trigger getDatabaseSchema on the images field which adds the modified and created DB fields. The things I've done is add optional support for migrating createdUser/modifiedUser and created/modified datetime for pages. I am using quiet save which is supposed to support createdUser, modifiedUser, and created, but it isn't supporting modifiedUser for me at the moment. I might resort to SQL, or I might decide it's actually best to just change the created versions and leave the modified to change to the user running the import and the current time. On the user migration - if a user doesn't exist it will be created and assigned its roles from the source installation as defined in the JSON. Also, if the needed roles aren't available, they will be created too. Let me know how it goes for you!

Hi leroj, Should be no problem at all.

Hey Ryan, I just came across this issue on the latest dev version - presumably with stable as well. I ended up going with your fix for now, although for anyone stumbling across this, the Yes and No need to be reversed in the ternary operator.

You can use commas like that. Sorry, I was looking at the returned selector and was thinking you were using that in the url. I would still do as apiesa says and just load the url initially in your address bar directly and see if you are still get the tilde/underscore issue. Have you tried the returned selector in a normal template file, or in Nik's Selector test module to make sure you are actually getting the results you expect?

No problem - I wasn't much help Always disconcerting when a db spontaneously loses data - good luck with the sleuthing!

Is there any chance that some of the files in the PW wire folder could have been deleted? You could try replacing the entire wire folder with a fresh copy - that might be a good place to start? Sorry, hopefully someone else will have a better idea

Hi Jennifer, It sounds like the repair worked on the tables. The member function error on $user->roles makes me think you have a session issue - maybe? Have you tried emptying your assets/cache folder? Really not sure, but maybe worth a try. Can you access the admin, or is the entire site down?

Vineet - it's all about variable scope. $pages (or any of the other PW variables) can't exist inside a function like that. You need to use: wire('pages')->get or define $pages = wire('pages') at the start of your function and then you can use: $pages. Nevermind - sorry, apparently I didn't actually read your post Looks like renobird's suggestion should be spot on!

This post from Soma, might be a great place to start: http://processwire.com/talk/topic/3634-down-uploads-on-a-per-user-policy/

leoric, I think we are all struggling to know exactly what you mean without knowing your page structure fully. In your first post you say to want to get the page's parent from the search results. The problem is that your results may find pages with different parents. The only way to get the parent is to do that on one page. Perhaps you need to rethink how your search works. Would it perhaps be better if the initial search term actually only looked at the category field for each page? Another possibility would be do have a multiple option search like the skyscrapers demo (as noted above). There are lots of options, but perhaps if you can detail out your site structure a little better, using actual content examples, like the shirts idea, we'll be better able to help.

Turns out I really broke some keys things when I added the import actions functionality (for append, overwrite, replace). I need sleep now and won't be able to get to this again for at least a day, maybe two. So, the most stable version right now is probably: https://github.com/adrianbj/ProcessPageTreeMigrator/blob/019e006833ad970263533516aa7615b8c87af573/ProcessPageTreeMigrator.module Of course this doesn't include the fixes for the PHP warnings that teppo found, nor the directory writing checks etc. Anyway, I'll post again when the import actions additions are working properly.

Hey Marty, anything for you Do you mean automatically or manually on a regular basis? Manually will be no problem at all - that is what this is designed to do (once I get a for more of the REPLACE kinks sorted out). If you want automatic replacement, I am sure we could use a cron job to handle both the export and import - the key thing would be to save the zip on the server, instead of downloading it to local machine. Then get the zip from the destination server and trigger the import. All sounds do-able. That said, if it is just content we are talking about and no fields or templates would change, then I wonder if an import from a web service feed might not be a better approach - this could even bring across new images. I'll sleep on it!

Hey Ryan, A couple of quick suggestions for the debug mode tools PDO queries section. First one should be simple - force queries to wrap so they aren't truncated. I know they are still there and can be viewed in the page source, but would make life easier still. Along with break-word etc, I actually quite like how it looks with white-space: pre; as well, although it does make for a long page The other thing might be more difficult - any chance you could decode the bindValue of the variables so we can see what is actually being queried. I haven't looked to see how/when this debug table is built, so maybe this isn't possible, but it sure would be helpful!

Thanks again teppo - awesomely helpful! So I think I have taken care of everything from your reports: If there are no template php files in the import, then the message is not displayed to avoid confusion. Write permissions are now checked on the destination templates directory (if there are template files to be imported), before anything happens and the user is alerted so they can fix and start again. Also fixed the extra forward slashes I have fixed the line 1403 errors for repeaters - that error only occurred when there were no entries for a repeater on a page which is why I hadn't seen it before. I am not getting the line 1026 error at all, so please let me know if that one still shows up for you. Fixed the line 1038 error - now the module will work without the page field's Template of Selectable Pages set. Along with this I have also put a limitation on automatically migrating content for page fields - it won't automatically export the entire page tree if a page field's Parent of Selectable Pages is Home (id#1, just in case the name was changed), and also only if the Parent of Selectable Pages is set - so, it won't potentially try to migrate pages from all over the page tree, which might happen if some is using Template, or even worse a Custom Selector or Custom PHP option. Not sure why you are getting that integrity constraint violation. I know I have broken many a PW install while testing this module, so maybe if you could start with a fresh one and let me know, that would be great. By the way - I tested that files.zip with "Append" and it works as expected without errors, so I do think something is likely amiss at your end, but please let me know what you find. Actually, I have managed to replicate something similar to this - it's amazing what you can sometimes miss due to the way you are doing something. Anyway, I am on it - it is related to the addition of the new REPLACE option, but I am having trouble tracking it down fully tonight, so it might have to wait another day or until I can find some more time, but I'll post again when that is fixed. In the meantime, so long as you delete the About tree from your install before importing, that zip should work! Great thought on the issue of a failed import and the cleanup idea. Ideally I'd love for there to be no reason for a failed import, so maybe better checking for potential conflicts before anything happens is the easiest way. Undoing changes / cleanup might be tricky! Really appreciate hearing that this has saved you lots of time - I would love this to be a "must have" PW module once some more kinks are ironed out. Thanks again.

I love it when I stumble across an old piece of wisdom on a Saturday morning Just wanted to note that there is a small mistake in Ryan's example. You need to remove "->type" from the second line, so full working example is: $field = $fields->get('your_page_select_field'); $inputfield = $field->getInputfield($page); $options = $inputfield->getSelectablePages($page); https://github.com/ryancramerdesign/ProcessWire/blob/03387f8283d518e9cc405eff8f05cd6a5bf77c4c/wire/modules/Fieldtype/FieldtypePage.module#L308 Thanks again Ryan!

Thanks for fixing my sloppy code Also, here is a great article on ternary operators: http://davidwalsh.name/php-shorthand-if-else-ternary-operators Anything you think you might be sacrificing in PW by not using templating syntax, is more than made up by the abilities of simple everyday PHP. Ryan also wrote a good article here: http://processwire.com/api/why-php-syntax/

Hey teppo, Thank you for the testing. I can replicate that same export error. I hadn't come across it before, but looking at your export JSON, I noticed that the page field you included has a parent_id of "home". I never anticipated that. The module will actually find all page field parent/child trees and add them to the export, so if for example you had a pagefield that linked to a categories/category tree, then it would grab that info, export it and import it on the new site, even though it is not directly under the parent you chose when exporting. I think the module actually handles this scenario quite well (despite the error which is an easy fix) - so if you do choose home, it won't try to export the entire home tree, but it will use the children of home on the new site, once you do the import, which is what happened for me when I imported your JSON. Does that make sense? EDIT: Actually that 1038 error is because your page field doesn't have a "Template of Selectable Pages" set. I have always been testing with page fields with both "Parent of ..." and "Template of..." defined in the Input tab. I'll have to make sure there aren't any further complications here. The message about importing template files should be hidden in this case, since it is clear you used the copy/paste approach. Obviously template files (*.php) can only be migrated with the "Save" output format. I'll take care of hiding that when it's not appropriate. Now for the confusing one, the errors with repeater fields. I haven't had any issues with those in quite some time now so I am curious on the exact setup. Would you mind testing one again and send me the errors you're getting and also the JSON, and if they're not being included in the export, perhaps you could sketch out their structure. One thing I am curious about on the repeater front - what option are you choosing for "Components to Export"? I have been doing almost all my recent testing with "Everything", so I am wondering if that might have something to do with it. I notice that none of your page fields have any content. Thanks again, really appreciate this! BTW, I have attached an export of a page tree that shows repeater and page fields working, along with images and RTE embedded images. Be sure to import "Everything" and choose "Replace". It should go into any parent, but I have been testing mostly with Home as the import's root is "About". It will replace your About (if you have one) and also install a US states page tree for the state selector field. There are a couple of repeaters at the bottom of the gallery child page. files.zip

Another pretty major update today. Here's the list of changes: Friendly error handling when modules/fieldtypes aren't installable on the destination site which also prevents any actions until you install the required modules. Support for migrating page data for all (hopefully) custom fieldtypes. I have tested with cropImage, MapMarker, Dimensions, and Phone. Let me know if you find one that doesn't work. Also, if you are playing around with MapMarker, be sure to make the changes shown in this PR: https://github.com/ryancramerdesign/FieldtypeMapMarker/pull/4/files - seems like it might only affect very recent devs of PW and hopefully Ryan will commit that change soon anyway. New Import Types: Append, Overwrite, Replace. Explained fully in the module, but the key new functionality is replace, which effectively allows you to edit the content in a section (Page Tree) of a site (say on your dev server), including changes to field settings, which fields are in the template (including repeater fields and their subfields), and the page data in the fields, and all these changes will be replicated on the destination site. This is very new, so let me know if you find something I have missed. Remember, there is one happy customer already .... But I am looking for more If you want a quick demo, don't forget you can try installing Ryan's blog profile as a child of your Home using the zip attached to this post.

Just wanted to add that I am experiencing this issue too. Seems like it is the same as reported here: http://processwire.com/talk/topic/2518-repeater-fields-via-api-it-has-no-parent-assigned/ Only difference I notice is that unlike teppo's report on his gist linked above, what I am finding left over is actually the "for-field" page, rather than the "for-page" page. As soon as I delete that page entry from the DB, everything works again as expected. Obviously this needs to be automated as part of the repeater cleanup. Thanks for looking into it Ryan. EDIT: Actually I am getting even more confused with this at the moment - a delete($parent_page, true) actually deletes a lot more repeater information than an admin delete of the same $parent_page, even after emptying the trash - which leaves behind the pages containing the actual repeater field content). I guess in reality, the for_field page should stay there unless you're actually wanting to delete the repeater field. All I want to do is delete all the pages and the pages that contain the repeater field content on those pages. I'll keep experimenting

Hey Wanze, You're right for sure. I got thrown because I though it was just API related, but it actually seems like a bug between MapMarker and the latest version of PW. I looked back at a couple of sites that are working fine and MapMarker has always defined those as '' and not 0 and they have always been float fields. Not exactly sure what changed where, but this definitely fixes it. I'll submit a pull request for Ryan. Thank You!!

Hi everyone, Here's something I have been battling with. I am trying to create a new page via the API with a template that contains a MapMarker field. The template also contains two other custom field types (phone and dimensions, which are both fine). The problem comes down to the fact that the lat and lng subfields of the MapMarker fieldtype are floats. So, when you try to save the page, you get the following error: Warning: 1265 Data truncated for column 'lat' at row 1 which makes complete sense. Here is the generated SQL: INSERT INTO `field_map` (pages_id,data,lat,lng,status,zoom) VALUES('1494','','','','0','0') It's getting the zeros correct for status and zoom, which are integer fields. So, the way around it is to set those subfields to zero before saving. So, this works: $basic_page = $templates->get("basic-page"); $wp = new Page(); $wp->parent = $pages->get("/about/"); $wp->template = $basic_page; $wp->title = 'testme'; foreach($wp->fields as $pf){ if($pf->type=="FieldtypeMapMarker"){ $wp->$pf->lat = 0; $wp->$pf->lng = 0; } } $wp->save(); But I want to come up with a solution that will allow creating a page with any custom field that might use float sub fields. I even thought about setting the values of all fields and subfields to 0 before (to be overidden later), but can't even do that because it seems impossible to find out the subfield names until a page is created with that template - am I missing something obvious here? Then again, I feel like this is PW should handle properly in the core. I am not even sure I know why it is trying to set the values of fields on page save if they weren't specified anywhere. Any thoughts? EDIT: I am beginning to think this is actually an issue in general with MapMarker as I can't create new pages in the admin either - I'll investigate further.

Chiming in quite late here and to be honest haven't read things thoroughly, but my RedirectIds module might be of use for giving your clients an easy url over the phone: http://modules.processwire.com/modules/process-redirect-ids/ It means you can give them: mysite.com/videos/1356 where that number is the PW ID of the page. You can choose to have that link redirect to the normal full PW url for the video, or stay on the numbered url and just load the page content - simple config setting in the module. Not sure if this is your best approach, but thought I'd throw it in the mix.

@verdeandrea - you can't use commas with this module. Take a look at the instructions page again: http://processwire.com/talk/topic/1654-module-pages-web-service-servicepages/ Note that unlike regular ProcessWire selectors, multiple field=value sets are split with an ampersand "&" rather than a comma ",".