adrian

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.

Just make sure $page->created is returning the format needed by the function by doing: date("Y-m-d H:i:s", $page->created);

+1 for DOMDocument over regex

I have had some personal communication with Ryan about this and it seems to be an issue with MySQL 5.6 (although arjen does debunk that is one of his posts), but I had the problem on a server with 5.6, but as soon as I rolled back to 5.5 it went away. Regardless this is something that does need to be fixed sooner than later because 5.6 will start getting more common. Can's fix is the current best option though and works perfectly.

Not really sure if this helps your problem or not (I think maybe not), but is your server in a timezone 14 hours away from QLD? If you need to convert from that to QLD time, you can use a function like this: function convert_time_zone($date_time, $from_tz, $to_tz){ $time_object = new DateTime($date_time, new DateTimeZone($from_tz)); $time_object->setTimezone(new DateTimeZone($to_tz)); return $time_object->format('Y-m-d H:i:s'); } then call like this: $qld_time = convert_time_zone($page->created, 'Other/Timezone', 'Australia/Queensland');

Hey teppo, Thanks for the thoughts on the checkbox issue. I agree that unchecking "password changed" does sound weird My reasoning for going this way was because I was wanting to avoid the need for an additional step (checking the checkbox) when creating a new user. I thought, maybe incorrectly, that anyone using this module would want to ensure that all new users are required to change their password when they first login. My approach to setting up admin users is to send them all the same initial password and ask them to change it immediately. I wonder if a better approach might be to use a dropdown select that is a required field when setting up a new user. It could be called "force password change" and have a blank default and then "yes" and "no" options. It's still an extra step when setting up a user, but at least this way I can ensure the superuser doesn't forget to do it. Any thoughts on whether this would be a more logical setup? Thanks for the reminder on the license - I actually haven't been good with that for any of my modules - mostly because of ignorance/trust with these sorts of things. I'll take care of it shortly and also check my other modules and do the same. PS Minor fix committed this morning - I woke up realizing that I had hardcoded the path to the profile page EDIT: Do you, or anyone else, know why I can't set the collapsed state of the pass field via the API? I can do it with other system fields, but not this one. You'll see in my code two commented blocks where I try to set it to open before the redirect and then set it to collapsed after they have changed their password.