We don't plan to support that. See T5474.

We may provide something like a bin/backup export command in the future which writes a single export file to disk, although this would have some difficulty interacting with custom configuration files, and you'd probably have to read the documentation to learn about it (some related discussion in T7148).

We can not write configuration like mysql.host into the database, because we need it in order to connect.

I'll improve the documentation for this to specifically mention conf/local/local.json, but this stuff is basically already documented, and the document is the top hit on Google for me for "phabricator migrating to a new host" and similar terms, even in an incognito window, so I don't think there's much we could do to better surface it.

Local config is mostly local so that attackers who compromise administrator accounts can not escalate by adjusting config.

@cspeckmim, can you and/or other users experiencing this issue confirm that D12182 fixes it without causing hangs?

We don't have enough information to reproduce this issue. See:

Closing for lack of feedback.

Haha, no problem. Thanks!

I don't realistically anticipate us ever pursuing this. It's a very low priority and its priority is likely to decline over time as RSS continues to decline.

This use case is obsoleted by Harbormaster (T1049).

• For the "keep track of inlines" use case, T1460 is in the process of landing.
• For the "make it easier to persist something beyond the lifetime of this review" case, there's now the "+" menu on every page which will let you file a task quickly, and you can get a "mention" backlink by mentioning the revision name (like D123). This isn't perfect, but this need doesn't seem to come up often enough to really motivate providing a tailored action for it.

See T3353 for discussion of code vs text diffs.

In theory, we should also configure these providers:

For this use case, I mostly think it should be a lot easier to preview Diviner documentation. You could maybe imagine a command like:

Did you find and read this article?

Now that we have large file support, a better approach is probably:

This stuff seems to work reasonably well, now. Some followup work is described here:

The redirects we handle manually are always only GET so we shouldn't run into problems with that.

Since D12151, we don't follow "Location:" headers for these requests. If the response comes back with a 3XX code, we look for a "Location:" header, explicitly verify that the URI it specifies is OK (permitted by the outbound rules), and then repeat the process with the new URI. We abort after following too many redirects or encountering a loop.

I'm going to consider this resolved and close out the associated HackerOne issue, but let me know if there's anything I missed or you think any part of my assessment is off.

This is definitely a T5791 thing.

This should be resolved in HEAD. Sorry this took so long to address!

Presuming resolved, but let me know if that didn't actually fix it. D12116 has some more specific discussion.

See T4434 for recently completed objects.

Oh, and the attacks mentioned above remain live:

After D12168, D12169 and D12170, I feel like we've reasonably mitigated this attack. The remaining vectors are:

Yeah, that looks great to me. Specifics of the done/draft state aren't a big deal.

So "Unpublished Draft" means both:

Unpublished "Done" is should be the same, but is broken in JS.

Cool, works for me.

You can use this as a workaround in this case:

D12169 mostly mitigates DNS rebinding:

See some discussion in T7660.

Mostly, it makes the code simpler because it doesn't have to check whether it needs to add a new row or not when adding comments, and doesn't have to check whether it needs to remove a row or not when removing comments.

That is, if you make an inline comment and I check it off as done, no one but me can see that checkmark until I comment on the revision, update it with a new diff, or take another major action. All of the stuff I checked off publishes all at once at that time, as a single "epriestley marked 13 inlines done." event. Until then, when you and I look at the same inline, you'll see it unchecked and I'll see it checked.

Oh, the actual checkmark itself can be unsubmitted though. Presumably that should be communicated differently than the comment as a whole being a draft.

Yeah -- we actually have four states:

If this takes longer than like 20 minutes for me to implement I'm just going to give up since it's so rare, but the proposed interaction does seem better to me.

• I don't think this panel is very useful in general and would support removing it or burying it.
  • • However, I have some anecdotal evidence that other users do find it much more useful than I do.
  • Ignoring @generated files is reasonable but should wait for T784.
  • T5658 has a patch to prune old/crufty revisions from this view.
  • Other types of magic don't seem worth the performance cost and/or implementation complexity to me.

@generated files.