adrian

Hi aren, I just committed an update to Custom Upload Names for you. It now has an option to generate a random string at a length of your specification. Please take a look and let me know if you need any assistance.

So long as you are loading the module on the front end like that, the refresh shouldn't be relevant. The refresh was only if you wanted to do the autoload, but this is much better. I wasn't think about adding the load to the page containing the form - much easier than hooking - good thinking

Ok, it all makes sense now Ideally it would be best if you could hook into the point before the form builder saves the page - not sure what that hook is - sorry. But, if you want to quickly test, the autoload = true option works, you just have to remember to refresh your modules: Modules > Refresh after you make that change to the info.json file that I mentioned above. Do that and I think the emails should send fine even via the formbuilder user page creation. It shouldn't be a huge problem to leave the module autoload because it checks to make sure that the page being saved has the user template, so it shouldn't affect any other pages on the front-end. Let me know if that works for you.

I just tested this which is how I would expect form builder is probably creating the page and it also works: $modules->get("EmailNewUser"); $p = new Page(); $p->name = "me"; $p->parent = $pages->get(29); $p->template = $templates->get("user"); $p->email = "me@gmail.com"; $p->of(false); $p->save(); So the only things I can think of are that the module is not being loaded. See here that again I am manually loading it, but if you change it to autoload in the module, you should be ok. The other thing to clarify - is the form definitely creating and saving the email address? I am not really a form builder user, but perhaps if you can explain your exact configuration I can play around with it and test at my end.

Hi Mont, Page fields are arrays so if there is only one expected result: echo $page->promoting_club->first()->title; Or if you want to list them all out, you can foreach: foreach($page->Classes as $class) echo $class->title; or you can use implode (https://processwire.com/talk/topic/5098-new-wirearray-api-additions-on-dev/): echo $page->Classes->implode(', ', 'title');

No problem installing TinyMCE here. Did you hit the enter button on your keyboard, rather than clicking the Download and Install button? There was some weird behavior with this until the commits over the weekend.

Not sure what you mean about the last rule not working. Leaving off the closing ?> in php is recommended when the entire file is php. I am sure there are more complete explanations out there, but take a read of this one: http://developer.sugarcrm.com/2011/05/06/why-we-dont-using-closing-php-tags/ However it looks like you are swapping in and out of html / php, so you will need to close the tags in this case.

For 500 errors, take a read of this: http://processwire.com/docs/tutorials/troubleshooting-guide/

Can you load up other files from the PW root folder in your browser? Please check the permission of the install.php file itself and make sure it matches the permission (eg 644) and also the owner and group of the index.php file - since you got the Get Started button to load I am guessing the index.php file loaded ok. Do you have any other sites running on that server? Any chance their could be some modsecurity or htaccess rules that are blocking the install.php file? Can you access it if you temporarily rename it to something else like test.php?

@tobaco - I am not seeing that issue, but I am missing several site modules from the list. Perhaps you should add a comment to my Github issue: https://github.com/ryancramerdesign/ProcessWireUpgrade/issues/2 or start a new one ?

Glad that got you going until a proper fix is in place. Hopefully these two posts and your link to your other issue will bump that thread for the multi-language gurus too!

Hi Ronnie, I don't know too much about UTF conversions (the curse of being a native English speaker), but could you please try changing this line from: return json_encode($this->getNew()); to: return json_encode($this->getNew(), JSON_UNESCAPED_UNICODE); OR, If you don't have php 5.4+ then you instead of the above change, you need to add this function somewhere in the MigratorWordpress file: public function raw_json_encode($input) { return preg_replace_callback( '/\\\\u([0-9a-zA-Z]{4})/', function ($matches) { return mb_convert_encoding(pack('H*',$matches[1]),'UTF-8','UTF-16'); }, json_encode($input) ); } and then use: return raw_json_encode($this->getNew()); Please let us know if that works and we'll get it updated.

Hey Peter, If there is more than one value in the page field array, then looping is likely what you want, but if the page field is set to only allow one option, then you are better off with your good friend "first": $page->course_detail_level->first()->title

@Didjee - Looks like Ryan may have taken care of most of this, but not quite all. It is an SQL settings issue - certain settings come by default in MySQL 5.6.x, but can also be present on other versions. Does adding that field (column) to the pages DB table take care of it? I'll let Ryan know, but it would be good if you could confirm that fixes things fully.

Please fill out the poll at the top of the page to help me decide on how to release this new functionality. Thanks!

Hi everyone, I'd like to announce a complete overhaul of this module - problem is that I am not sure whether to release it as an update to this module, or perhaps as something completely new, perhaps called PageProtector. UPDATE: The functionality described in this post is available as a separate module: PageProtector This new version (not on github just yet) makes it very easy for site editors to set up various password protected areas on their site, or to simply protect a new page or section while they are still working on it. New functionality Ability for your site editors to control the user access to pages directly from Settings tab of each page Includes whether to protect all children of this page or not Optionally allows access to only specified roles Ability to change the message on the login page to make it specific to this page Option to have login form and prohibited message injected into a custom template Access to the above "Protect this Page" settings panel is controlled by the "page-edit-protected" permission Table in the module config settings that lists the details all of the protected pages Shortcut to protect entire site with one click What do you all think - replace the existing module, or release this functionality as a separate version? Module Config Settings Page Protection Settings

Hey Marty, I can't seem to reproduce in today's dev version. Did you get Ryan's updates from today with improvements to the new name checker? Did you do a hard reload to update js scripts?

Hi ank and welcome to the forums. Hard to know exactly how you have things set up, but give this a go. It's untested, so there might be something slightly amiss, but should be close: <?php $pagename = $page->child->title; foreach($page->children as $child) { $headimage = $child->headimage->first(); $thumb = $headimage->size(600, 400); $pagename = $child->title; echo " <div class='section'> <a href='{$child->url}'> <div class='sectionimage'> <div class='image'> <img src='{$thumb->url}' alt='{$headimage->description}'></img> </div> <div class='caption'> <p>{$child->title}</p> </div> </div> </a> <div class='brands'> <ul>"; foreach($child->children as $childchild) { echo "<li><a href='{$childchild->url}'>{$childchild->title}</a></li>"; } echo "</ul> </div> </div>"; } Sorry for getting rid of all your echo statements - they were driving me crazy

davo, Just a quick note to say that I tested on the front-end and it works fine like this: $modules->get("EmailNewUser"); $u = new User(); $u->name = 'newuser'; $u->email = 'newuser@gmail.com'; $u->save(); Note that I am manually calling the module - that avoids the need to make it autoload on the front-end. I don't see where in your form builder hook that you create a new user ?

Sorry to be late on this, but I have made this work on the front-end and from memory, it sounds like you are on the right track with the Inputfield_id issue. Sorry, not enough time to look at things properly right now, but I think you are close

Ok, all makes sense now Your needs are different from the person I put that together for - they wanted the root parent changes, not to actually drill down to the specific page. You can get directly to the specific page with this: public function changeParent(HookEvent $event) { $pid = (int) $this->input->get->id; $event->replace = true; $event->return = str_replace($pid, $rootPageID, $event->return); } BUT unfortunately this doesn't load the images available on the page because the check to see if there are images available or not happens here: https://github.com/ryancramerdesign/ProcessWire/blob/master/wire/modules/Process/ProcessPageEditImageSelect/ProcessPageEditImageSelect.module#L129 which is before the execute method we are hooking into. So I think you'd actually have to hook directly into ProcessPageEditImageSelect::getImages which is not currently hookable. But maybe you should add the ___ to it and play around and see if you can get it work. Sorry I don't have time right now, but I think it should be doable. If you get it to work, Ryan should be amenable to making it hookable in the core.

Not sure I follow - if there are images available from that root page, it should work just fine - note the message about no image fields.

One more update - The module now applies its rules during the adding of a new page (not just editing like before). Obviously there is no affect for the "Initial Differences Protected" setting, but all other settings are relevant and now work.

$userID = wire("user")->id; as you have it in your modified version will work fine I would test your changes to the module in the admin first - if that works, then you can focus on the front-end issue.

Seems like that should work - is it not changing the parent, or is it changing it to the wrong page? Have you checked the value of $rootPageID to make sure it is what you expect?