adrian

Glad you got it working. Just to clear things up for people searching the forums, I just edited the title of this post from the original: "How To Use A Method From Another Module In Own Module" since this is more specifically about image fields. I don't think it really is documented anywhere at the moment - definitely something that should be explained somewhere.

This should get you started: $f = wire('modules')->get("InputfieldAsmSelect"); $f->required = true; $f->attr('name', 'allowedRoles'); $f->attr('value', $data["allowedRoles"]); $f->label = __('User roles allowed to flag (use spaces to separate entries)'); $f->setAsmSelectOption('sortable', false); // populate with all available roles foreach(wire('roles') as $roleoption) { $f->addOption($roleoption->name); } if(isset($data['allowedRoles'])) $f->value = $data['allowedRoles']; $wrapper->add($f); I see you are using owzim's config helper, which I haven't used, so let us know if you have any trouble incorporating it into your module.

Hi marcus - sounds like a great addition. How about making it an ASM field that grabs all the available roles?

What Soma is getting at is that because you are in a module context, the "image field to 1 max image" setting doesn't work to convert the image field from an array to a single image, so you must use first(). eg: $bgImg = $s->section_img->first(); Here's a worthwhile read: https://processwire.com/talk/topic/1125-images-field-returning-array-even-when-max-files-set-to-1/

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