| # |
Apr 13th 2021, 22:47 |
JJ15 |
No. That's not what I want. |
| # |
Apr 13th 2021, 22:43 |
JJ15 |
nvm I think this should do the trick https://github.com/smerrill/vagrant-rsync-back#vagrant-rsync-back |
| # |
Apr 13th 2021, 22:41 |
JJ15 |
So any files generated by cake.php are not visible locally. And I don't really want to make a 2 way binding because in the past I've lost work through accidents on the vagrant machine. |
| # |
Apr 13th 2021, 22:40 |
JJ15 |
Trying to find a way to run bin/cake.php locally. I can ssh into the box and run bin/cake.php from there but the rsync seems to be 1 way and doesn't replicate locally. |
| # |
Apr 13th 2021, 22:40 |
JJ15 |
I have a local copy of my application that is rsynced to my vagrant machine. Running bin/cake.php locally fails because the database exists on the vagrant machine not locally. |
| # |
Apr 13th 2021, 22:39 |
JJ15 |
Anybody have any experience using vagrant? |
| # |
Apr 13th 2021, 22:22 |
 phantomwatson |
When time is limited, sometimes we have to be content with simply knowing what the fix is and leave the unraveling of the deeper mysteries for another day. Which is often more frustrating than cathartic. :S |
| # |
Apr 13th 2021, 21:04 |
kevin.pfeifer |
its definitely nothing globally applicable to PHP 8.0 - just checked it with my app |
| # |
Apr 13th 2021, 20:40 |
greg138 |
Compare the PHP8 ini file to the 7.4 one? |
| # |
Apr 13th 2021, 20:28 |
kevin.pfeifer |
or something changed in php 8.0 for mailing which i don’t know of |
| # |
Apr 13th 2021, 20:27 |
kevin.pfeifer |
either you have some custom php.ini in 7.4 which hasn’t been adopted/converted/copied to php 8.0 |
| # |
Apr 13th 2021, 20:26 |
phantomwatson |
And if I run it explicitly under PHP 7.4, the problem goes away. Cool (and thanks for pointing that out!) but _what the hell_. |
| # |
Apr 13th 2021, 20:25 |
phantomwatson |
7.4 and 8.0 are both used on this server. This domain was and still is on 7.4, but at some point recently the system default version of PHP was bumped to 8.0. Thaaaaat seems likely related. The command-line script is running under PHP 8. |
| # |
Apr 13th 2021, 20:22 |
greg138 |
There hasn't been an update to your version of PHP? |
| # |
Apr 13th 2021, 20:20 |
slackebot |
<5bc58feffd2948f09c8dc9051b9630db@muncieevents.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1d649385e3049e4e717ba26f27a73f0a" Content-Transfer-Encoding: 8bit Message-Id: <E1lWPSX-00001A-Hh@server.cberdata.org> Date: Tue, 13 Apr 2021 16:16:29 -0400 ...``` |
| # |
Apr 13th 2021, 20:20 |
phantomwatson |
I don't see anything malformed about that, but it's still being received like this: ```... To: graham@phantomwatson.com Subject: Upcoming Week in Muncie: Tuesday, Apr 13 X-PHP-Originating-Script: 1000:MailTransport.php From: Muncie Events <automailer@muncieevents.com> Return-Path: automailer@MuncieEvents.com Sender: Muncie Events <automailer@MuncieEvents.com> Date: Tue, 13 Apr 2021 20:16:29 +0000 Message-ID: |
| # |
Apr 13th 2021, 20:19 |
slackebot |
multipart/alternative; boundary="1d649385e3049e4e717ba26f27a73f0a" Content-Transfer-Encoding: 8bit"``` |
| # |
Apr 13th 2021, 20:19 |
phantomwatson |
So at the point where headers are being fed into PHP's `mail()` function, this is the `var_dump()` of the `$headers` string: ```string(375) "From: Muncie Events <automailer@muncieevents.com> Return-Path: automailer@MuncieEvents.com Sender: Muncie Events <automailer@MuncieEvents.com> Date: Tue, 13 Apr 2021 20:16:29 +0000 Message-ID: <5bc58feffd2948f09c8dc9051b9630db@muncieevents.com> MIME-Version: 1.0 Content-Type: |
| # |
Apr 13th 2021, 20:18 |
phantomwatson |
Automatically, I mean. |
| # |
Apr 13th 2021, 20:18 |
phantomwatson |
If I understand it correctly, it's being yanked out of `app_local.php`. |
| # |
Apr 13th 2021, 20:08 |
greg138 |
I'm curious where the return path is coming from. |
| # |
Apr 13th 2021, 20:03 |
phantomwatson |
Oh, there's a daily and a weekly version of the emails, but both have the same issue. |
| # |
Apr 13th 2021, 20:02 |
greg138 |
And your screen shot before has "Today in" as the subject, not "Upcoming Week in". They are both exhibiting the issue? |
| # |
Apr 13th 2021, 20:02 |
phantomwatson |
Set in `app_local.php`. |
| # |
Apr 13th 2021, 20:02 |
phantomwatson |
The return-path is being pulled from the `Email.default.returnPath` configuration option, I think. |
| # |
Apr 13th 2021, 20:00 |
greg138 |
Hmm, you're not setting the return path anywhere, yet it's in the "bad headers" (ones with a space before them). |
| # |
Apr 13th 2021, 19:59 |
kevin.pfeifer |
how about enabling output buffering and checking if something prints somewhere? |
| # |
Apr 13th 2021, 19:58 |
phantomwatson |
Good thought, but `app_local.php` looks fine. Nothing before `<?php`. |
| # |
Apr 13th 2021, 19:58 |
greg138 |
But the spaces are coming before the header *name*, not the value. |
| # |
Apr 13th 2021, 19:57 |
kevin.pfeifer |
since your using the Configure classes here do you have some spaces in your `config/app_local.php` probably? |
| # |
Apr 13th 2021, 19:57 |
greg138 |
We must be getting close... |
| # |
Apr 13th 2021, 19:56 |
phantomwatson |
I could try ditching the `Mailer` class system and sending emails just with `new Email(); ... send()` to see if that works, but that's not ideal, and I'd like to figure out what suddenly broke these messages. |
| # |
Apr 13th 2021, 19:55 |
slackebot |
Week in Muncie: $date") ->setViewVars([ 'events' => $events, 'recipient' => $recipient, 'settingsDisplay' => $this->getSettingsDisplay($recipient), ]) ->setEmailFormat('both') ->setDomain('muncieevents.com'); }``` |
| # |
Apr 13th 2021, 19:55 |
phantomwatson |
But nothing about the `Mailer` class code looks unusual. ```public function weekly($recipient, $events) { $this->viewBuilder()->setTemplate('weekly'); $date = (new FrozenTime('now', Configure::read('localTimezone')))->format('l, M j'); $this ->setTo($recipient->email) ->setFrom(Configure::read('automailer_address'), 'Muncie Events') ->setSubject("Upcoming |
| # |
Apr 13th 2021, 19:53 |
phantomwatson |
Nope, the ones that work just create an `Email` object and then `->send()` it. |
| # |
Apr 13th 2021, 19:52 |
greg138 |
You said there's emails sent from your site that work okay? Do they use the same Mailer class? |
| # |
Apr 13th 2021, 19:41 |
kevin.pfeifer |
well then i would look for some strangely encoded strings or whitespace before `<?php` in your custom Mailer.php |
| # |
Apr 13th 2021, 19:41 |
phantomwatson |
But I don't see anything in my Mailer class code that seems unusual, or which deviates from what's in the docs. |
| # |
Apr 13th 2021, 19:39 |
phantomwatson |
The plot thickens. These emails are only bugged when I use a `Mailer` class, but not when I just create a new `Email` object and `->send()`. |
| # |
Apr 13th 2021, 18:56 |
phantomwatson |
Actually, crap, that may have just been an artifact of how I was generating debug output. :( `print_r($headers); echo "\nMESSAGE BELOW\n"; print_r($message); echo "\nEND OF MESSAGE\n";` generates ```Content-Transfer-Encoding: 8bit MESSAGE BELOW --1c2e6618b5d00c393f7043526a0b5fdf Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit (actual content)``` |
| # |
Apr 13th 2021, 18:50 |
phantomwatson |
_But_, the source of the message that the recipient receives _does_ include this double line break: |