adrian

I doubt it's your fault. Behaviour of copying pagefield content is actually something I am struggling with for Migrator (and the main reason I haven't "released" it yet). The current behaviour is to automatically create the required templates and pages for any page field that is part of a page that you chose to migrate. The problem is where to put these page field pages. If they are not within the page tree that you are migrating, or if the parent they are under is not available on the destination site - what to do? I think the desired behaviour may be different depending on whether you are migrating content from a dev version to a live version of the same site, or whether you are importing content from one site into another one that doesn't already have the page field content in its structure. I hope that makes sense - even I am having trouble understanding what I just wrote That definitely sounds like the issue. It's not the importing of users/roles that created the content (Migrator handles this well), but rather the problem of trying to re-create the users that are selected in that select page field. I'll obviously have to revisit my current approach to migrating page field content, especially for scenarios like this. The problem is that if the page field pages are not under the exported parent and you don't include them, then that will result in broken page fields on the destination site. What to do ? I'll marinate on this for a bit, but I'd also really appreciate any thoughts! Macrura - if you feel like testing, I'd really appreciate knowing if everything works fine if you remove that page field from the site before you export. It should work fine with other page fields, but the linking to users must be the issue. Thanks and sorry for the hassles! EDIT: Would you mind PM'ing your exported json file so I can see exactly the structure of the page field? I am thinking that maybe an option would be for the export to contain the full page path to the pagefield's content pages and if that path exists on the destination PW site then use that. If not, then create these pages under the Home page. Hopefully this can be solved in a logical way that works in all situations.

Not sure if this is definitely the issue, but often the default RewriteBase don't work depending on server configuration. The most common requirement is to simply uncomment the first example option: Rewritebase / but you might need a different config. It should however be the same as you had it set up when running the 2.4.4 version of PW. Maybe it is something else that is causing your problem though?

There is also this module which might be useful to you: http://modules.processwire.com/modules/service-pages/

That's not what I want to hear Are you using the latest version of Migrator? Can you send through that entire error message (all 70 rows of it)? What happens if you go back to PW 2.4 - wondering if there is a difference without Lister being used to display users.

@Andrei K - welcome to the forums! Nothing should have changed re PHP or MySQL versions. I think the most likely issue will be the RewriteBase setting in your .htaccess file. Did you replace this with the new version but forget to make a required change to the RewriteBase setting for your server?

The Table fieldtype doesn't support files or images. Of course a link to an image is really just a file path so you could theoretically store these path in a table field, but you'd have no way to upload the images to the server. Depending on the size of the gallery and what information you want to record for each image, I would actually recommend using an individual child pages for each image. Otherwise, the new PageTable field might also be a good solution. There isn't much documentation on this yet because it is only available in the dev version, but it is very powerful. It is a core module in the dev version, but not installed by default. Some links for you: Gallery tutorial from Joss which uses a single images field: http://wiki.processwire.com/index.php/Simple_Gallery_System Another tutorial from everfreecreative: https://processwire.com/talk/topic/3990-another-simple-photo-gallery-tutorial/ Post from Ryan about the advantages of having one image per page for its ability to store whatever metadata you wish: https://processwire.com/talk/topic/417-extending-image-field/?p=6982 Remember that a "page" in processwire is really just a row in a database file and show shouldn't be considered as being a workaround - it is actually very efficient and effective.

Sounds like you might need to add this to your .htaccess file. There are some commented examples already in that file. RewriteBase /~username/

I don't think that is possible. From the description in the Store: But then I don't know why you would need to - images are already a multiple field type

This should help: https://processwire.com/talk/topic/339-urgent-matter-fatal-error-maximum-function-nesting-level-of-100-reached/

Reading through your question again and putting aside the parentTemplatea setting altogether, would it not be possible to just find a random parent of the page in question. I think maybe I don't still really understand what you are trying to do, but is this any help? $page->parents->getRandom(); That will get one random parent of the current page, but of course you could do this for any base page. Sorry if this is not at all related - definitely having trouble deciphering exactly what your needs are - maybe an example of your page tree structure and the pages you are trying to identify would be helpful.

Ok, so firstly, your search-form.php needs to access: $input->get->objective $input->get->status $input->get->new_old Then you need to build up the final selector to include these along with "q" I have to head out now, so don't have time for a full example, but if you look at the sksyscraper search you'll see how it builds up the selector by concatenating the pieces together like: $selector .= Not sure on your php knowledge, so in case you don't know the dot before the equal sign means to add to the last value of the variable. To troubleshoot, try testing a final example selector and once you have that working and returning the results you need, work backwards to figure out how to build if from the component search elements. I'll check in later and see how you are going.

Thanks for all the details - good to see that your form is using "get". Sorry for maybe getting distracted by that - my fault. In your form I see three select fields, all named "type" - should they be different filters? Anyway, the key thing seems to be simply that you don't deal with the type field in search-results.php. You need to make use of $input->get->type and add it to the selector that finds the matches. Does that make sense?

So where is it failing? Is your filter form really sending the search parameter "q" via the url? We need to know the name of the select field that is sending the objective filter and how that is being passed to search_form.php It might potentially be as simple as using : $input->get->objective but it's impossible to tell without seeing more of your code. Is your form being submitted (post) to search_form.php, or are you redirecting to a url like: mysite.com/?objective=xxxx (get)

Are you populating $out with something? eg: foreach($matches as $m) { $out .= "<li><p><a href='{$m->url}'>{$m->title}</a><br />{$m->summary}</p></li>"; }

I know you specifically asked for a way using a selector and that you didn't want to foreach through the templates, but I don't think that is possible and no-one has responded with anything better yet, so $tid = $templates->get("template_name")->id; $validTemplates = array(); // this array will be populated with templates that have the required parentTemplates settings foreach($templates as $t){ if(in_array($tid, $t->parentTemplates)) $validTemplates[] = $t->name; } Not ideal I know, but it seems to processes quickly and I think it gets you what you need, although I am guessing you probably knew how to do this already

Just in case anyone was thinking this module forced you to send the user's password, I just wanted to clarify that if you don't want to email the password at all, that is no problem - the body of the email is completely configurable. In the module config settings you create the message from scratch using any of the fields from the user's page however you want, so you could quite easily let your clients know their initial default password over the phone (potentially the same for each person in their team), but still have this module automatically send each user an email with their username and the link to the site's PW admin control panel. Using this approach, together with Password Force Change, you'd have a very safe way of getting out the login details for the entire team of editors and making sure their passwords get immediately changed.

@sins7ven - thanks for sharing the script! I agree with horst on this. I think this version should be much safer, although it might need some more thought. $fn = wire('input')->get->file; $pid = (int) wire('input')->get->pageid; $p = wire('pages')->get($pid); $filename = $p->logo_file->get("name=$fn")->filename; Firstly, it makes sure that pageid is an integer (so that no-one can try entering a path instead) and then gets the page object from that integer. Then it finds the file in the logo_file field that matches the name in $fn. This ensures that the file path in $filename can only be a file from the logo_file field and that it is a valid file in the PW database. You might also want to consider sanitizing the filename that is passed via get->file using something from the cleanBasename core function: https://github.com/ryancramerdesign/ProcessWire/blob/03387f8283d518e9cc405eff8f05cd6a5bf77c4c/wire/core/Pagefiles.php#L296 You could also do some checks to make sure that both pageid and file are not blank and throw an exception if they are, or if the pageid is not provided as an integer, or get->file does not match it's sanitized version - both of which might indicate attempted hacks. An even better, more secure approach might be to use child pages instead of repeaters (or the new PageTable field) and just pass the id of the page to the download script, so with one image per page, the page id is all that you would need to identify the path to the file and start the download.

Agreed - that occurred to me yesterday too. Thank you both for the feedback - changes have been committed to Github and the module has been submitted to the modules directory.

teppo - I thought through this a little more and realized that any multi field would not be a good idea as it would involve associated pages and templates for the yes/no options, so I have gone back to the checkbox, but reversed it to be a "Force password change on next login" checkbox as you suggested. However I have added a module config setting called "Automatic Force Change" and if this is checked, then the "Force password change on next login" checkbox gets automatically checked when creating a new user. I think this solves all the issues of: Confusion over the reverse checked and the strange "Password Changed" label. With the automatic force change checked, there is no extra step required when creating a new user, but there is also the flexibility for the superuser to turn this off so it has to become an active selection to force the password change. Existing users are left untouched, which is cleaner. I am pretty convinced this new approach is better in all ways but I'd like to hear any feedback before I commit the changes to Github, in particular from you teppo if you have a minute to think about it. I am attaching the new version here for testing/review. Please make sure you uninstall the old version first to make sure the old passwd_changed field is removed. If I don't hear anything back by tomorrow, I'll commit this version anyway EDIT: Removed attached version to avoid confusion since it is now on Github.

I know this is old and I am not sure if this is still the case, but when I last looked into this I actually had to do the following to fully clean up a repeater field: $current_field_id = $this->fields->get("field_name")->id; $forfieldid = "for-field-$current_field_id"; $sql = "DELETE FROM pages WHERE name=:forfieldid"; $query = $this->wire('database')->prepare($sql); $query->bindValue(':forfieldid', $forfieldid); $query->execute(); Here's a related Github issue (https://github.com/ryancramerdesign/ProcessWire/issues/368) and forum post (https://processwire.com/talk/topic/4440-deletepage-true-doesnt-delete-repeated-fields-on-230/). Note that Post #10 by yours truly describes the issue which the above fix deals with. I think this is different to the other things described. I know this has become a little off-topic now, but wanted to respond to owzim's question with some details and potential issues.

Just wanted to note here in this post that I've built a configurable module for this and also included optional support for automatically generating the password for the new user. You can read more about it here: https://processwire.com/talk/topic/7051-email-new-user/ Also, there was some discussion above about how to get the entered password in plain text, but I don't think anyone actually came up with a working solution. I found that you can hook on InputfieldPassword::processInput and then you can get the plain text password with $event->object->value

Assuming you are using TinyMCE and not the CKEditor module, take a look at some of these links: http://www.imathas.com/editordemo/demo.html http://www.tinymce.com/forum/viewtopic.php?id=13917 http://www.fmath.info/plugins/TinyMCE/demo.jsp https://github.com/rochecompaan/tinymce-asciimath-plugin http://mathmlflash.blogspot.com/2010/08/plugin-for-mathematics-for-tinymce.html I haven't used any of these, so no recommendations as to what is better, but hopefully should get you going. EDIT: You might also be able to achieve what you want by editing the valid elements on the field's input tab > tinymce advanced settings.

Hi Pete - that is exactly what I do with my front-end registration script, but this module is designed for backend creation of admin users. I have never facilitated user signup for admin accounts, but perhaps that is not a bad idea - a module that allows a user to signup for an account with their own details and then after email activation, the superuser gets an email with the new user's account edit link and then they go and make sure they are a valid user and then assign them the appropriate roles/permissions. Is that basically what you are suggesting?

This module allows you to automatically send an email to a newly created user with their username and password. It also has the option to automatically generate a password for the user upon creation. http://modules.processwire.com/modules/email-new-user/ https://github.com/adrianbj/EmailNewUser The following things are configurable: Whether Send Email option should be automatically checked when creating new user - also affects new users created via API From email address (if left blank it will use the admin email set in the config/php file Email subject Email body - includes the ability to use any fields from the user template using {field_name} codes so these can be put into the body wherever you want. It's your choice if you want to include the password in the email or not. Whether to automatically generate a password. This can be toggled on/off, but even if it is on, you can override it by simply entering a password manually when creating the new user. Ability to control the length and character sets used to make up the automatically generated password. Option to send a test email to yourself to make sure it is configured the way you expect. Because it is generally not a good idea to email passwords, it is highly recommended to use the new Password Force Change module in conjunction with this module. That way the user has to change their password the first time they login which will somewhat reduce the vulnerability of emailing the password. It can also be used for API generated users: $modules->get("EmailNewUser"); // call the module since it is not autoload on the front end $newuser = new User(); $newuser->name = 'newuser'; $newuser->email = 'newuser@gmail.com'; $newuser->sendEmail = true; // only needed if Automatic Email Send is unchecked $newuser->save(); Please let me know if you have any ideas for improvements. PS Thanks to everyone in this post: https://processwire.com/talk/topic/2981-new-user-welcome-message/ for their thoughts and ideas on how to do this.

Just discovered a bit of a gotcha - if the new user does not have "profile-edit (User can update profile/password)" permission they obviously won't be able to change their password, so just committed an update that checks for this permission and warns that it needs adding.