I'm just going to merge this into T10448, this task doesn't have anything not already covered there.

• DiffusionCommitQuery has had the "good" version for a while.
• We're nuking Releeph at some point.

both forms are marked as edit..
but when edit a task of the bug form it opens the form of the standard task

T12089 has a narrower description with some screenshots, I think the behavior got flipped by accident.

At least one user over email (and I think @epriestley also) mentioned the light highlighting of full lines is hard to distinguish / understand as full change in diffs. I'll look more into these issues before next release is cut.

59s is ridiculous. :(

I think @jboning was working on moving Phabricator to new hardware last year, but I don't know where that ended up. Once that happens, we can get you clustered for performance.

You're right, works fine for me against a Phacility test instance. Huh.

And also T7664.

This sounds like T8588 offhand, unless you can reproduce against Phacility hardware.

We're going to need complete reproduction steps. Preferably against a Phacility test instance so we can rule out environmental causes.

The "Ambiguous Leaders" section in the docs should more or less cover this, and using bin/repository thaw to promote your favorite node to leadership is probably the easiest way to resolve it. This pathway to ambiguity is fairly mundane compared to what the documentation imagines, though, and both clusterize and that UI warning could point toward bin/repository thaw --promote. I'll make these more clear.

First thing to check is if your DB configs are in /conf/local/local.json, I went through the same issue, because my mysql configs where in /conf/custom/myconfig.php and for some reason newer versions of phabricator do not evaluate PHABRICATOR_ENV properly. So basically run

Thanks, not intentional.

I can't reproduce this either. Here's:

Alright. If we don't hear back from you in a few days we'll close this since we can't move forward on it, but you're free to file a new task when you're ready to move forward.

I'm using a VPS but don't have the facility to easily clone it as is and can't risk it being broken anymore than is now. I will get a small instance setup which reproduces the problem (using ansible to roll out so should be straightforward), that probably won't be until in the week, right now I'm working around it by mirroring and pushing to another remote temporarily.

I can't reproduce this, and I suspect it was fixed some time ago during changes related to T6027.

Oh, one final note:

I've collected some guidance more formally in T12085.

FWIW this affected us as well, we switched from cloudflare back to cloudfront and hit this snag. The default settings do not forward Host header, we had to add that ourselves. Didn't need to change anything else, though - it seems that cloudfront performs loose SSL validation and is OK with the certificate/host mismatch. (Maybe it at least requires the host to match the origin domain - not sure.)

I've also made these additional changes, not directly related to the original request:

I think this is mostly guidance I neglected to issue, sorry about that.

Thanks! D17162 should clean this up.

These changes are now available in HEAD of master, and should be available on stable after Jan 13. master is also safe to upgrade into right now, although some T11114 stuff may churn later this week.

All evidence points to this and T9548 being the same task, right? I'm just going to merge them.

I believe there's more to it than just the bundle2 setting that causes it to not work. It still breaks for me even with devel.legacy.exchange=bundle1:

I have restarted httpd. I try to disable some chrome extension. Now it works.

Move all cards in this column to <another column>

That would be very useful for us as well.

I also can't reproduce this locally or on a Phacility test instance.