adrian

You're missing the line ending semicolon d($config); So it looks like "Config Data" is the culprit on your setup. I don't really know why it's so slow for you, and I don't really know how to improve it. Anyone else seeing that? If others chime in with a similar experience, I'll see what I can do, but I think for the moment it's probably best to just disable that and use d($config); as needed. I used to be all about _blank links, but these days I actually find them annoying because they give you no choice. A normal link lets you choose - I have three-finger / midd-click setup for open in new tab. If you are finding it that annoying though, I'd be happy to add a config setting to make all those PW Info panel icon links optionally open in a new tab - just let me know.

Hi @Robin S - excluding repeaters for a minute for the sake of clarity, it is already possible to have multiple videos on the one page, either in multiple fields, or within a texarea field, so images in the images field could be from multiple videos. I think I assumed that the dev would always grab the thumbnail for a video by name, rather than it's order in the images field, but I don't really know how this is being used, so hard to know. Maybe others can chime in because as I mentioned I don't think I have actually haven't ever used this module - I built it for request here in the forum.

Hi @AndZyk - this was actually just fixed yesterday. Please update and let me know if you still have any problems.

Hey @szabesz - I am surprised you are seeing such a dramatic difference in load times for the PW Info panel with those 3 sections enabled. I just tested on two of my servers and got these results: Server 1 Those sections enabled: 28ms Those sections disabled: 22ms Server 2 Those sections enabled: 6ms Those sections disabled: 3ms So for me, there really is no noticeable difference in load times. But we have seen discrepancies like this before. I remember when kongondo had really slow load times with the three objects in this panel, but it didn't affect you at all. Could you maybe determine which one of these three is causing the main slowdown? If it's "Config Data", then I would suggest just disabling that and using the Console panel and doing: d($config) whenever you want that info.

Hi @eelkenet - I haven't used this module in quite a while and actually never personally used it with repeaters, but I can definitely see why you'd prefer this behavior. Thanks for having a go at implementing this. I think that while this behavior is probably preferred by most users, I agree that making it optional is best, especially because this could be a breaking change for existing users. Looking forward to a PR - thanks!

Sorry about that - I wasn't seeing that because I had an older, updated install that already had those options stored in the settings database. New version just committed fixes it. Thanks again!

Just Not suggesting we should go the VueJS route at all, but here's an interesting "admin" panel built with Vue: https://github.com/iview/iview-admin Check out the demo - SPA admin panel.

If I was actively developing a site, I would take the time to fix any plugin dependencies - you are missing out on so much by being on such an old version. I have updated many site from 2.3/2.4 to 3.x with minimal problems. Sometimes errors pop up that look bad, but only take a few minutes to fix. Just my 2cents worth!

Hey everyone - don't forget to read the version of this excellent post on Medium: https://medium.com/icf-church-developers/our-first-processwire-website-fab741e09707 Create an account and "clap" for the article - you can clap up to 50 times - let's see if we can get @noelboss's article on the Medium homepage!

Hey @Robin S - this seems to break the "create a new field" option from the Template editor. It tempts you with a new "Save and Add New", but without clicking the "Add & Close" button, the new field won't be added to the template.

Do you mean a new item in an existing repeater field? This post shows how to do that: https://processwire.com/talk/topic/6435-cant-figure-out-how-to-create-a-repeater-through-the-api/?do=findComment&comment=62987 Is that what you are wanting?

Try this: $repeaterItem = $page->multi_locations->eq(0); $repeaterItem->of(false); $repeaterItem->title = "tryout"; $repeaterItem->melder = $melder; //etc for other subfields $page->save('multi_locations'); This will change the values for the first item in the repeater field. You can use eq(n) or first() or last() depending on your needs. That is for updating an existing repeater item, but if you're creating a new page, then you need to add a new item to the repeater: https://processwire.com/api/fieldtypes/repeaters/ and also read this post: https://processwire.com/talk/topic/6435-cant-figure-out-how-to-create-a-repeater-through-the-api/?do=findComment&comment=62987

Maybe of use? https://github.com/shancarter/Mr-Data-Converter

Ok, you asked for it. The main Dumps panel is now better at reporting bd() calls from obscure places, like other modules, and within Tracy itself. These improvements are fairly well tested, but please let me know if you notice anything it's not reporting that it should. I also added a new "Modules Refresh" option to the PW Info panel. This is not only a useful shortcut on the frontend, but because it returns you to the URL you were on, I actually prefer it to using the "Modules > Refresh" link on the backend as well. I am definitely open to more discussion on this, but at the moment I don't really see a good solution that will work across all panels - information is presented in many different ways in the different panels, so I think we would need to target this to the ones that really need search/filtering.

I just tested with Mail Interceptor and it's catching the email just fine. Would you mind debugging the sendNewUserEmail() function - see if it's being called at all and where it is failing?

Is this site online? Can I take a look?

When I try that I get this error: Exception: Can’t save page 0: /admin/access/users/adrian5/: Call $page->setOutputFormatting(false) before getting/setting values that will be modified and saved. [roles] on line: 500 in /Users/ajones/Sites/ecoreportcard/wire/core/PagesEditor.php So, it's pretty clear that you can't turn outputformatting back on before saving (line 9). Do you not see that error in the Tracy console output?

Glad that sorted things out. I could possibly make it optionally autoloaded on the frontend, but I figure that loading it manually like that is an acceptable approach - any strong thoughts on this? Interesting - is this site upgraded from an old PW version before these settings were available, or is it a new install? I wonder if that's the reason, but also wonder if it's something that the PW System Updater should have taken care of when you upgraded - maybe something to bring up with Ryan? Either way, it's good to know. I am no longer relying on these settings - all I am doing now is adding "symbols/puctuation" if selected, and using a higher min password length if it's set higher than the 12 which I am forcing as a minimum.

Don't forget that you need: $modules->get("EmailNewUser"); Are you using that and it's still not working? As for the minlength thing - I get the feeling that maybe you're using a version of PW without those newish settings? This is what I see.

The "http" may be optionally prepended to any property accessed from $config->urls (including those you add yourself). https://github.com/processwire/processwire/blob/57b297fd1d828961b20ef29782012f75957d6886/wire/core/Paths.php#L49

@MilenKo - take a look at the "Jumplinks" section of the Hanna Code docs: https://modules.processwire.com/modules/process-hanna-code/ That is what Ryan uses for the ProcessWire blog. I think that is what you are looking to do.

Ok, new version committed. I am now forcing more complex password generation. Using the settings from the "pass" field just weren't working well - often not complex enough for the complexity validation, but should be good now.

Actually, I think there is a bigger issue at hand - setting the password generator to less than 8 characters results in "too weak" from the PW password validation, so I am going to force the number of characters higher for the automatic generation. After all, this is only meant to be a temporary password so probably no real need to worry because users will be copying/pasting anyway. I'll commit an update shortly. Hopefully this will deal with your issue anyway, although it would still be nice to know why you are getting "1".

Hi @jmartsch - I can't seem to reproduce this - it always returns the correct value from the "pass" field's settings. I tried an API send and a Re-send message and they both returned 10 correctly. In my case it is set to 10. Any chance your pass field is set to 1, or it's not named "pass". What happens if you do: d($fields->get('pass')->minlength); in the Tracy Console panel?

@FrancisChung - I agree, although I would go with JSON over XML given the choice.