adrian

Ok @jmartsch, getting through these: Not sure how to handle this - the label changes from "Send" to "Resend" once the user has been published. I don't otherwise store a record of the email being sent. Sure it's possible, but I think it might get unnecessarily complicated. Do you have any thoughts for how it could be implemented well? EmailNewUser respects the "Automatic Force Change" option in the PasswordForceChange module which ensures it is automatically checked when a new user is created. Does that work for you? I am hesitant to override that setting if it's intentionally unchecked. What do you think? Thank you - that is a new bug - because the password was populating the pass fields, rather than being generated on publish. Now it will generate if nothing is already set, which is the case when re-sending the welcome message. Thanks - there are two things going on here. I broke this when I moved all the hooks yesterday from ready() to init(). I have fixed this now, but the other thing is that you are missing this: $modules->get("EmailNewUser"); // call the module since it is not autoload on the front end I just tested with your code with this on top in Tracy's console and it's now working fine. Please test the latest version and let me know how you go.

Hi @jmartsch - looks like those recent changes broke a few things - sorry about that, but thanks for testing. Taking a look now.

Ok, I have committed a new version which fixes the two bugs that @jmartsch reported. As mentioned above, I have also revamped the password generator - it now populates the password fields while you are creating the user and the generated password matches the options defined in the PW "pass" field's config settings. The only one I can't match is the complexity factor, but so long as you stick to the default (or lower) it should all be fine - thanks to @Robin S's Password Generator (https://processwire.com/talk/topic/17406-password-generator/) for some inspiration Please let me know if you notice any problems with this new version.

Wow, thanks for noticing that issue when manually entering and deleting a password - I had never come across that before. The reason that "before" hook doesn't work for is because the InputfieldPassword::render() method uses addClass('InputfieldPasswordComplexify'), so you are removing it before it's actually added. I have achieved the same thing though with a str_replace on an "after" hook - not as elegant, but works fine. You actually got me thinking about the whole approach to automatically generating the password and I thought it might be better to actually populate the fields when creating the user, rather than leaving them blank and populating when publishing the user. I am going to PM you my current dev version to take a look at as see what you think of this new approach. Thanks again for your help/feedback with this!

There is a "Rename on Save" option in the config settings. If you check that and then write a small API script to loop through all the pages that have images that need updating, it should do the trick.

Hi @jmartsch - glad you are finding it useful. I can't seem to reproduce any of the problems you are having What version of the module are you running? Line #54 isn't that line in the current version, although it's only one off, so maybe it's a misreporting? Do the various fields show when you have the automatic option check in the module config settings? Also, what is it that you are dumping on line 72 that is returning "FieldtypePassword" ? One thing to try here - can you change the: public function init() { on line 48 to: public function init() { } public function ready() { Yes, it is making the init function empty and converting the current init() function into a ready() function. Please let me know if that helps.

As @kongondo said that module, while being very useful if you want as easier way to manage entry and formatting of phone numbers and their component parts, it won't do what you want. Actually I am starting to think that what you are looking for is a way to format/convert phone numbers that are entered into a textarea/body field into clickable links, rather than having a dedicated phone number field. Is that correct? If so, then that could actually make a useful Textformatter module.

That's probably a question for @ryan - I doubt he ever expected someone to install Uikit and remove the default theme. It sounds like he is planning on making Uikit the default sometime soon, but not sure his plans for the other themes - what will be included / installed by default? But I definitely agree that there needs to be some checks added to make sure if there is no default theme installed, that at least one of the modern ones is used, rather than falling back to an old one which most new PW users have never seen.

Thanks very much for figuring that out @Robin S - I certainly wasn't testing with a newly created/unsaved page. I have committed your fix. Cheers!

OK, I tested your code and it works fine here, although I am confused what you are doing with $email - you define it and never use it. Also, I assume you are replacing the two instances of me@email.com with valid email addresses you can check? The one thing here that might be off - you are submitting the form to another page (I think): http://localhost:8888/signage-B/form-response-1 - is this a valid PW page, or just a PHP script? If it's just a script, you need to bootstrap in PW (https://processwire.com/api/include/) so that script has access to wireMail() etc. Does that make sense?

Doesn't matter - it just needs to be the name of one of the fields in the form that will be sent and available via POST. Again, check the Tracy Request Info panel to see what has been POSTed.

Looks good at my end - thanks.

Sorry, of course you're correct - I have a local version with some minor changes, but nothing that would affect what you are seeing. I am not sure where to go from here - I have tried with your module settings and repeater field settings and not getting any errors and repeater items are being created just fine. The only thing I can think of is that my test site is multi-language, but I would think that would be more complicated, not less Any chance you could help debug where and why it is trying to change the name of the repeater - I don't think it should be doing that at all and I am certainly not seeing it here.

I think the most likely thing is that nothing is getting processed. You are checking for: if (isset($_POST['submit'])) { but you don't have a field named "submit" - take a look at the Request Info panel in Tracy under Input POST and you'll see an entry for "send", but not submit. You can also add a bd('test'); call as the first line inside the isset and you'll see that nothing will show up in the Dumps Recorder panel in Tracy, because nothing in there is being processed.

Ok, so as you said, now it must be an issue with the code in your form. Can you post that?

Ok, so that sounds promising. What happens if you run that Console panel code without the Mail Interceptor activated. Does the email get sent?

Hey @Robin S - I am using your code and module settings. The one thing I did notice when I imported your module settings though is that you are using an older version and I have a feeling that might be the reason. Please try updating to 1.0.2 and let me know.

Ok, great to see that working, although I am still not sure why it didn't work on the Frontend, or has that solved itself also? But back to the original topic - this result shows that your email is successfully being prepared and sent by PW - now it's just a matter of why it isn't actually going out. I admit I didn't properly read the early posts, but if you are using WireMailSMTP, did you use the TEST option there to test your settings?

Sorry, I don't know what you mean - can you post a screenshot and explain please? I think you definitely have some AJAX issues, but I have no idea what at the moment. Any chance this site is live somewhere I could take a look? Not that it should matter, but do you have the core SessionHandlerDB module installed? Also, what happens if you reload the page after submitting the console mail code - does the Mail panel show up populated then? Or, what about putting that code in a template file and loading a page with the template - does the main Mail panel show then?

FYI, in case it's not obvious, it's a file compiler issue. Something to do with the line breaks. I have come across this once before. It's a pain, but an easy fix.

Thanks @tpr and @gmclelland for all the updates. Just updated and got this:

Ok, it looks like your AJAX panel might not be working. Are you running PHP 5.3? If so, the AJAX panel won't work. If you are running 5.4 or greater, please check "backend" in the "Show Debug Bar" section and load the main admin page tree view and let us know if the AJAX panel shows up there.

Ok, the latest version of Tracy should fix those errors. Please update and let us know if the AJAX version of the Mail Interceptor shows the email as expected.

Ah - thank you. You must be using an older version of PW before there was support for $urls. My fault - I should have used the older and more compatible $config->urls. I'll post a fix shortly, but in the meantime, I think if you just disable the SnippetRunner panel, everything should work ok.

Ok, it looks like you have seeing a bug there that is causing problems with the AJAX bar - we need to solve that and then hopefully you should be good. Can you please send a screenshot of the error when you hover over the SnippetRunner panel please? And also those from the "2 errors" panel. Also, can you please let me know what version of Tracy you are running?