adrian

Sounds like you are really close - I was lazy with the <a href='/articles/ That will go back to the root of your site. You can just change that to: <a href='/sitename/posts/

I know horst will have some great advice shortly, but for now, have a read of this: https://processwire.com/talk/topic/6667-jpegoptimimage/ This module also uses the an exec command and also names the files differently. My first post there notes the issue with images being left behind and mentions that you can extend Pageimage::isVariation to deal with these. I know that horst has been working on some standard naming conventions to make this all a lot easier - again, I am sure he'll enlighten you shortly

This is what you are looking for - some of teppo's handiwork https://processwire.com/talk/topic/6556-module-textarea-markup-inputfield/

Glad you sorted it out - hope the rest of your PW goes more smoothly

Hey Max, Try this in your template for the articles parent page: foreach($page->children as $article){ echo "<a name='".$article->name."'><h2>".$article->title."</h2> <p>".$article->body."</p>"; } That will create the posts one after the other with the title and body and with an <a name> tag that is the fragment identifier. The to link directly to a specific article it would simply be: www.mysite.com/posts/#post-name To create these links in your teaser section you might do something like this: $articles = $pages->get("/articles/")->children("limit=4"); echo "<ul>"; foreach($articles as $article) { echo "<li><a href='/articles/#".$article->name."'>".$article->title."</a></li>"; } echo "</ul>"; That should work just fine!

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