maybe by 2050 email will work most of the time for most people

I use a crappy email client

The actual diff is further down and rendered correctly for me, at least -- that's just how we currently render "added one line to the middle of a 500 line document" right now:

No, that's this stuff from T7643#179240:

I got a super long email from Phriction today, is that also an EditEngine freebie?

(assume you mean to post this on a different Phabricator)

Anchor tags got cleaned up in D16083.

This report doesn't include reproduction instructions and doesn't clearly demonstrate a problem: all of the screenshots are explicable through user error.

Here is a string of 2048 unbroken "M" characters:

Oddly, in the prior case where mail was mangled for a user on their install but similar mail was not mangled here, the unmangled mail I received was encoded in "8bit", which tends to suggest that this might be an MTA problem rather than an "8bit" problem, per se. But changing the encoding away from "8bit" might be the only real lever we have to fix the MTA.

The trigger for the behavior is likely just "long lines of text", we had an earlier report of something similar occurring inside an inline comment snippet (but it could not be reproduced on this install).

It's possible that adjusting phpmailer.smtp-encoding (say, to binary or base64) might fix this.

The webmail client allows me to view the raw mail. It's malformed as well.

bin/mail show-outbound --id <id> --dump-html shows the mail fine.

Particularly helpful would be to write some comment on this task which reproduces the issue for you, then tell me which client you're using.

Can you try this?

This will vanish for free when we move to EditEngine, or it could be special cased before that by either:

@davidism You probably don't want to be posting full memory core dumps publicly.

@hach-que can you disable php-apcu from the phabricator install, or do you mean to comment it out in the php/php-fpm config?

Can confirm this on another instance with the same package versions as what is reported in original post (Arch).

We don't officially support localization, though you may use it if you feel adventurous.

In T11047#179388, @grindhold wrote:

maybe it would be an option to at least identify lethal arguments for commands and warn the user if he enters some. like rm does when typing rm -rf / without --no-preserve-root.

maybe it would be an option to at least identify lethal arguments for commands and warn the user if he enters some. like rm does when typing rm -rf / without --no-preserve-root.

In T11112#179360, @eadler wrote:

Not only this, but multiple Herald rules can conflict.

In T11112#179356, @epriestley wrote:

(...) I think these are fairly self-evident (...)

Not only this, but multiple Herald rules can conflict.

I think I figured this one out: it's actually because more than 100 rooms are being filtered. The (`id` < 367) part is being added by pagination code, but won't activate if a user is in less than 100 rooms.

We should fix these, but I think these are fairly self-evident and I think fixing them isn't trivial since I recall declining to fix them the last time I was in this code.

This is solved with D11688, but it needs to be turned on globally (at the moment it's a per call option, which was added so that internally our custom unit test runner wouldn't deadlock).

This should be resolved at HEAD of master. To get it to work you may need to update and then go through the password reset process again.

I think maybe there is a bug here also though with EditEngine. @epriestley ?

./bin/auth

I saw this today, we just created a new panel

Great, glad things are working now. Thanks for confirming the fix!

It looks like that fixed it. I just tried it with one task, moving it into a subproject board, and then back out.

In T10586#179056, @storrgie wrote:

@valentinul can you please let me know what exactly you modified in your php.ini?

@valentinul can you please let me know what exactly you modified in your php.ini?

T10402 is the "check client/server agreement about HTTPS" task.

Configuring the Preamble script is important for reverse-proxied configurations (you probably need to set REMOTE_ADDR up as well), and required for many things - which is why it is part of the install guide.

Wow, thanks for your fast and precise answers!! Using the file

We ran into this on a recent install - the fix was to configure the Preamble script to tell Phabricator it was being accessed over HTTPS (else it filtered out the HTTPS notification server) - check to see if "Connected" or "Disconnected" at the bottom of the notification popup (menu at the top of the screen - see this install). If you just get a grey bar at the bottom without either, you're hitting the same case where the client doesn't think it has a valid notification server.

https://hub.docker.com/r/hachque/phabricator/

is not supported by this install

I will try that now and get back with you

This was likely fixed by D16052 (June 5th). Can you reproduce the issue at HEAD?