adrian

Yeah, this is a little painful. I use the same approach in Tracy. I think it might be better if Ryan replaces that json detection code with the following which seems to be the most common approach to problem. /** * is the provided string a valid json string? * * @param string $string * @return boolean */ public function isJson($string) { json_decode($string); return (json_last_error() == JSON_ERROR_NONE); } PS - actually maybe this isn't useful at all with this issue, but in general I think he should be using a function like this for determining if a string is JSON.

Maybe something useful in this thread? https://answers.microsoft.com/en-us/msoffice/forum/all/mailprotectionoutlookcom-is-rejecting-my-mails/5a6bb9e0-062c-44e0-8a60-d79959bc003e

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