adrian

If you google that error there are a few possible php.ini settings that might help. Certainly not an issue specific to PW. If you're still having trouble after trying some of the google advice, then this is a question for your host.

Macrura is correct - PW needs mod rewrite. Don't give up so easily on the 500 error - there are lots of possible causes of this and lots of easy fixes - you just need to figure out which one is the issue with your particular hosting environment. If you have tried all the rewrite base options, including matching it to the path of your site on the server, then you might next try: #SetEnv HTTP_MOD_REWRITE On http://processwire.com/talk/topic/1962-cant-reach-admin-page/?p=49524 Or this: http://processwire.com/talk/topic/2439-htaccess-issue/?p=39674 If that doesn't work, take a look through these search results: https://www.google.com/search?q=site%3Aprocesswire.com+500+error&oq=site I am sure we can help you figure it out.

What you're looking for is: inputfieldClass The easiest way to figure these things out is often to use your browser dev tools. I actually didn't know this initially, but a quick right-click > Inspect Element on the select field under Inputfield Type, revealed the name of the select as: inputfieldClass

I can't replicate the comma issue here either, but I am guessing it is something to do with the number formatting settings on their OS or in Safari specifically. I have a couple of solutions for you try with your customer. In InputfieldPhone.module on Lines, 75, 80, 84, 89 can you try the following. Firstly, add: pattern="[0-9]*" to each of the input tags. If that doesn't work, try changing the input type from "number" to "tel" tel makes most sense here, but according to: http://www.w3schools.com/html/html5_form_input_types.asp it isn't supported by any browsers yet. Sounds like it might avoid the issue anyway, because the lack of support at least means that Safari won't think it's a number and try to add the comma. Let me know if either of these work and I'll make the changes to the module.

Glad to hear, but why not upgrade those old installations to 2.4 ?

On the permissions question, there are several modules that extend these capabilities in PW: http://modules.processwire.com/modules/page-edit-per-user/ http://modules.processwire.com/modules/page-edit-field-permission/ http://modules.processwire.com/modules/page-edit-per-role/ http://processwire.com/talk/topic/5354-usergroups-module-in-development-groups-page-based-permissions/ Hopefully something in there will be useful for you.

On a roll - after a chat with Joss, I have added a new option on export that allows you to select any additional required helper files such as .inc, .css, .js, etc. These selected files will be packaged in the zip for the migration. This option is only displayed if you choose "save" because obviously not relevant to "copy" where it's only the JSON that can be exported. Note that there is no need to select normal template files as these are still included in the export automatically.

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/