adrian

Another weird one That's obviously all JS - what browser are you using? Any browser console errors reported?

Thanks - that is what I thought. Weird though that it's not causing problems for anyone else I'll push an update in a minute.

Maybe it's: strpos($path, '/.') failing on Windows?

Well in that case can I please ask if you could check where things are failing. Start with checking if the "if" statement on line 35 ever validates. The maybe the value of $iter before the foreach. Then go back and check $root which is defined in the GenerateHTML.php file. Thanks for helping with this.

I am getting a little OT, but it's possible to support commas and complex data types in CSV with a proper CSV parser. PHP's native ones are not great. I make use of https://github.com/parsecsv/parsecsv-for-php in a couple of my modules. It's an older library that doesn't appear to be maintained anymore. I think there might be better ones out there, but at the time it handled everything I needed better than anything else I found. Back to the topic at hand - I am curious about a feed of 1300 pages - that could definitely take a little while to process. It's a shame it's not just addition of new pages - you could make that very quick if the xml feed entries had a date. But if you have to process them all for updates and deletions, you will be relying on the title of the page for matches. Will you just update them all, or will you compare the contents of fields for differences and process only if there has been a change?

Hey Robin - I have thought about it but I have always found that clicking Toggle All and then CTRL/CMD+F to use the browser's "Find" functionality works just fine. I agree that it would be a nice addition though, so I will have a think about it. Hey Juergen - I am wondering if maybe you're running PHP 5.3? I think it might be coming from the fact that I directly set $paths[] rather than previously defining $paths = array() Could you help me out and try adding: $paths = array(); on line 32, before the start of the foreach on 33 Please let me know if that works.

Most editors should these days, eg. Sublime and even the Tracy Console panel SublimeText TracyDebugger Console

Major revamp to Dumps / Dumps Recorder panels This has bugged me for a while - the Tracy core dumps panel is: ugly and with a forced label whether you want labels for it or not doesn't show a count of dumps next to the icon doesn't show dumps from consecutive ajax calls - each call overwrites the previous dump That is why I built the original Dumps Recorder panel, but it also had a problem: the redirect and ajax Dumps Recorder panels contained all previous dumps (those from the main page request, etc) which made it hard to see what was from what So now I have overridden the core Dumps panel with a new version that has: an optional label a count of dumps adds consecutive ajax calls so you don't miss any. I have rebuilt the Dumps Recorder panel as well. You probably won't want this most of the time, so it is no longer enabled by default on new Tracy installs, so if you are upgrading, I recommend disabling the Dumps Recorder panel by default and just enabling via the Panel Selector as needed. It no longer has a "Preserve Dumps" option, because that is now it's only purpose, so when it is enabled, it will preserve all dumps across all page / ajax requests and reloads. You can click "Clear Dumps" whenever you want, and of course disabling it will also clear the recorded dumps. I think this is a major improvement - it keeps things simple when that's all you need, but enables recording when you want to keep track of changes over multiple requests or you simply find that your bd() calls are somehow being lost / not shown - sometimes I see this when debugging modules - the dumps will be stored, but not shown - the dumps recorder will record these and show on the next page reload. Hope all that makes sense - please try it out and let me know if you find anything that you think can be improved. One other thing - I have moved the $_SESSION section from the Debug mode panel to the Request Info panel - I think that's a more appropriate location - inline with having the INPUT (post, get, and cookies) in there. On Tracy upgrades, you'll need to enable SESSION in the config settings for the Request Info panel.

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? Actually, maybe the solution here is another config setting in EmailNewUser. The setting would force automatic selection of "Force password change on next login", even if the "Automatic Force Change" option isn't checked in the PasswordForceChange module. Do you think this would work ok?

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?