adrian

For an outlook.com email address, I use this successfully. Do these work for you?

PS - when you have found the field in question, check out the Field settings in the RequestInfo panel to see if there are any textformatters showing there that are null or empty or something.

Have you tried: bd($textformatter, $field->name); so you can see which one at the end there is returning null? If you know the field affected, you might be able to check which textformatters are assigned to the field and find the problem that way.

Probably not enough ? Glad you're finding the API Explorer and Adminer useful. I use them both all the time. Sorry about that issue with the File Editor panel - just a stupid typo! It should be fixed in the latest version. Please let me know if it works for you now.

Someone else once mentioned that he didn't get the console errors in the response tab - turns out he didn't have "Disable Cache" checked on the Network tab and apparently that made a difference. I always have it checked because Chrome caching drives me crazy but this might be a helpful hint for others.

It looks like there is a PHP error message breaking the JSON - in your dev console click on the image upload ajax call (Network tab) and go to the response tab.

Hey @diogo - nice work! One thing I noticed is that it is loading quite slow for me. Several quite large images on the homepage.

Also, on https://processwire.com/docs/fields/dependencies/ you have a couple of links to the form builder module, but these are linking to http://modules.processwire.com/modules/form-builder/ instead of the new https://processwire.com/store/form-builder/

@ryan - not sure how many of these there are, but I think there are possibly lots of broken links from the PW admin to the new website, for example: The "how to use this" 404s.

@ryan - unfortunately the reply nesting / order of comments on the blog posts has been messed up during your import to the new site which makes things hard to follow. it would be great to get these reimported in the correct order and with the correct parent comments.

That makes sense - thanks. Emails are sent just fine. I registered a mg.mydomain.com domain with Mailgun and if I use that in the module settings without dynamic domains, then everything works as expected. I think it's simply because of the "value" parameter that is set in the WireMailMailgunConfig.php file. Actually speaking of the config settings, I think most of those checkbox settings should really have a value of "1" if they are to be checked by default, rather than the name of the field. Also, not sure what you think of the current approach to defining those module settings, but personally I prefer this approach (https://github.com/adrianbj/CookieManagementBanner/blob/master/CookieManagementBanner.config.php) if you want a separate file. No big deal either way - just seems cleaner to me.

@novajones001 - as far as I know, there are no books on the PW API - it sounds to me like you're not even talking about the PW API specifically. Are you sure you're in the right place ?

Hey @Macrura - admittedly I haven't looked into this dynamic domain stuff much, but from what I can tell, I don't think it should be checked by default. With my setups it prevents emails from being sent. What do you think?

Good news that solved that issue, but the way wire mail is called in the module is still problematic and needs fixing.

It's probably because that module uses: new WireMail() https://github.com/ryancramerdesign/LoginRegister/blob/7e6395393d46f9fba3a6769cc2ce85d4e495b8a4/LoginRegister.module#L677 rather than: wireMail() or $mail->new() Docs here: https://processwire.com/api/ref/wire-mail/ That causes PW to use its core email sending, and prevents wireMailSMTP and other mailing modules from working. I think this is a critical bug in this module which needs attention. Can you please report here: https://github.com/ryancramerdesign/LoginRegister/issues

@abmcr - great that you've fixed it up, but I think it would be helpful to submit a PR to @Pete so that everyone will get this new version. Please note that this module doesn't currently send proper 503 maintenance mode headers which is why I always use the protected mode module for this. Perhaps you could take care of adding the 503 stuff to this module as well?

You'll want to hook into ProcessLogin::afterLogin Sorry, no time for an example, but hopefully that will get you going.

@abmcr - I have a little more time right now, so if you want to fix this module instead, take a look at these two commits to @Pete's Email to page module: https://github.com/Notanotherdotcom/ProcessEmailToPage/commit/50acc8df55b69690c50c7aa31e439405e182d0ed https://github.com/Notanotherdotcom/ProcessEmailToPage/commit/e149fb7abf49a6bb31a4c8885051323528f5e19d He uses a similar syntax in that module to this one, so the required fixes will be the same.

You can always use the maintenance options in the Protected Mode module.

Glad Admin Actions was useful for you, but just keep in mind that I was actually referring to the new Admin Tools panel in Tracy. Also, regarding the 'Copy Content to Other Field' in the Admin Actions module - did that actually work for the map data? I haven't tested it with multivalue fields, but if it worked, that's great. If it didn't, then it is something I should enhance it to do at some point.

This is really beyond the goal of this module, but glad you found a solution in that other module.

@ryan - just found another "Internal Server Error" on the new website for you: https://processwire.com/search/?q=%24page( You can get to this by typing: $page( in the live search and hitting Enter

Just in case you weren't aware, the second approach of $page('headline|title') already works. It was documented in a blog post some time ago, but I can't seem to find it at the moment. It even works like $pages('template=basic-page') etc. Basically variables that act like a function. The other option we have which I had actually forgotten about is: $page->headline_OR_title

Hey @ryan, Just wanted to say a big thanks for making all those API examples on the home use the same approach, eg $page and $pages, and also for changing the image and save ones so they will work without errors. Thanks for listening to the community on this and sorry if it seemed we were hassling you ? Just one possible suggestion, although I am really not sure if this is a good idea or not. What do you think about: $page->headline_OR_title or: $page->{'headline|title'} or: $page('headline|title') instead of: $page->get('headline|title') For some reason these just seem to fit better to me when it comes to accessing a page's field values because I think of "get" and "find" as being more about getting a child/children of the page with a selector, rather than output a field or property of the page. Maybe it's just me though ? Did you have any thoughts on the idea of a sandbox console for users to play with?

@modifiedcontent - I have added that new "Delete Module" option to the Admin Tools panel. It will handle deleting modules when there are fieldtypes connected to the module and also when there are other modules that require the module you're trying to delete. I haven't tested it with a "broken" situation like you are describing and it actually probably isn't what you want because it will automatically delete the connected fieldtypes, so there will be data loss, so this is probably not what you want. Actually, now that I think of it, maybe the "Change field type" Admin tool will help you convert to the leaflet fieldtype?