Thanks, I'll just keep an eye on this ticket and switch whenever I need to.

I assume based on your comment there isn't a good replacement for whoami until viewer is available on search? (aka I'll keep using whoami until viewer is available as an input to search)

I would argue "rename" isn't really "rename" if all linked references don't get updated BUT I also would be super-opposed to things like git history/commits being re-written (and there may be other cases I don't know of that I would be pro/con to). At some point you'd want to draw the line and I, personally, don't have a solid use case for moving the line.

I did a local test of a rename and the fact that things like what I mention ^ would be a problem are the reason I'm not renaming current (not new) users.

Correct, I may not be 100% on this but I believe they are using a regex (sorry to trivialize if this is true/untrue/complex/etc.) to do some of the linking for things like me saying @enckse here...not to mention commit messages and the like.

I think the (potential) opposition is that they'd have to process all the remarkup as well

Yep and just as sort of an addition to my previous comment and why I said that: I feel like the current Task Detail trivializes what it probably really means to support PHP 7.

I believe the idea of contribution and input changes are entirely up to the project and what they can support, that said it seems entirely off-topic for this task (imho) and the only thing I would suggest is updating the task detail at the top indicating the statements you've (@epriestley and @chad) made about prioritization and planning so there isn't a comment chain every month about this in this ticket :)

Cool, thanks!

Just as input: Versioning/Updates would be really useful if we update our ToS for our end-users and we need them to be required to review and re-sign on change

I understand bot users don't get email but I totally mis-typed one and I realized it "too late" and would love to be able to change it even if it doesn't really matter

I hit this as well - I was able to fix the handful of tasks created before setting "search" -> "true" by just re-saving those tasks.

It seems likely, as well, until php 7.1 is officially supported that you probably don't want to sign-up for some potential pain points by choosing to roll the dice.

I would like to add, to anyone browsing this and trying to get a new instance of phabricator working on php7, to not do that (since it isn't supported and is now blocked by the software itself).

I recognize as a user (and a developer myself) the situation and that, as a user, I'm just complaining and not giving solutions. I also recognize you don't want to be dual-developing phabricator on multiple fronts. We're running on arch so I'm extremely biased AND recognize that saying this isn't a workable solution but because of the "bleeding edge" php levels on arch, I would prefer focus on php7 (again, super biased and I know that isn't just going to happen).

I think what is most frustrating about this is, having fought through php 7 configuration (without opening tickets, just trying to follow other tickets and doc), after an update today I'm greeted with having to edit source now to get php 7 (unsupported, I know) to continue working...

I've applied the patch and updated by URI accordingly (removed the ssh config as well) - seems to work

I'm willing to give it a go, just to confirm before I do that what my URI would be in the UI?

svn+ssh://svn.host.name:port/srv/repo/url/path/