Presuming resolved until we hear otherwise.

Someone in IRC hit this on stable and I haven't seen more reports on master, so I'm going to bring the changes over.

We can just query that as a setup check, although I don't recall too many issues with it recently.

maybe also DB's max_connections?

I believe this is fixed in HEAD of master now. Let me know if things look good on your end and I'll cherry-pick the fixes to stable?

Here's my general plan of attack here:

@epriestley : Alright then, Thanks.

You can manually edit conf/local/local.json instead of using bin/config set.

@epriestley : Ouch! - Alternatively since all of you are already on it. What git commit can i revert to quickly fix this? (Note it was a clean clone i am trying to re-setup)

Sniped!

This is somewhat involved to untangle because the old logic was actually wrong and had a small chance of executing a page incorrectly.

Ah, okay, that's actually consistent with what I'm seeing -- I think I repro'd the web version. You do sometimes need to restart the web thing to get this flow to work fully (we run some special, more-helpful checks during setup, which is only run after restart), but I believe it doesn't matter in this case since the setup checks are a little buggy.

maybe I need to restart?

It does work from CLI, not from web.

let me try again since I've gotten sleep. 8)

@chad, I'm having trouble reproducing the patch from P2007 not working. Here's what I did:

thx

Specifically, my plan here is:

I was ultimately able to reproduce this, but it took some work and the instructions above definitely weren't sufficeient:

Alright, let me see if I can get anywhere with this.

I've tried a whole bunch of different post requests (after setting those config values and restarting apache) but I haven't been able to get that garbage yet.

First, let's sort of limit the direct damage this misconfiguration causes by changing this line in PhabricatorUserLog->initializeNewLog():

Ah, nice! I'll write up some guidance on adding a setup check for this shortly.

Alright I was finally able to reproduce it. Calling unset($_SERVER['REMOTE_ADDR']); in the preamble didn't actually end up causing it, which is a bit strange. The only way I could get this to occur was to explicitly set $_SERVER['REMOTE_ADDR'] = null; in the preamble.

No clue what this was, haven't had issues recently. I think config may have become simpler in the last couple years.

FWIW, in our case the bug was also triggered by logging in for the first time (for this account) using LDAP.

Welcome to PHP! This will familiarize you with PHP! PHP is a special language!

Phabricator can be configured with a "preamble" script, for making certain environmental adjustments to deal with loadbalancers. This is described in Configuring a Preamble Script.

I just had this problem as well. Turns out I had a typo in preamble.php. A more descriptive error would be nice, but with this task open at least the cause is easy to find :)

@epriestley no i dont have any relationship with core Sandstorm, I'm a user and a fan of both apps. I'm just a student who wants to make life easier for the end user , and you create as much repercussion about it, I want to help phabricator and all other tools that I believe I send this text.

I followed up on this in #sandstorm on Freenode but this isn't officially sanctioned as far as anyone there knew. They're not particularly happy about this either, but obviously there's little anyone can do about users going vigilante with evangelism.

Oh, you've just been spamming tons and tons and tons of projects with the same message:

I noticed you posted the exact same message that you posted here to Drupal, with the same spelling error of "Oasis":

@chad yes, and want to help who don't know how to deploy Phabricator to use Phabricator and Sandstorm is perfect to that.

@MatheusVieira are you asking us to support it because you're a Phabricator user?

Link to the Sandstorm Vagrant SPK documentation - https://docs.sandstorm.io/en/latest/vagrant-spk/packaging-tutorial/

Specifically, you saw this page, and decided that you were not in the right place?

Was there any indication that the form wasn't working / wouldn't have worked?

Hi,
Thanks for responding. I was evaluating phabricator on my Ubuntu machine. I was certain the UI user registration wont work because email wont be sent out. So I went to terminal and used ./accountadmin to create an admin user.

bin/auth recover is a general-purpose flow not specific to this case.

I've never needed to recover an account. Can you give us details about how you ended up in a place where you felt that was necessary?

I faced the same issue too. As a user, after setting up a web UI why go back to terminal and type

./bin/auth recover <username>

and then come back to web UI to login? Once the setup is completed, a user would feel that the job is done and now he can login in peace.

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?

Yeah, I think something similar to D15961 is reasonable here. It's going to a little bit one-off and weird, but this and the timezone checks are the only cases where we care about client settings, I think.

@epriestley am I good to take a stab here at implementing the T3025-like behaviour?
If user is admin and clientProto != serverProto, display notification.
Approximately 5% familiar with Phabricator's JS side, but always interested in poking around more of the codebase - and I'm guessing most of this is gonna be touched in D15961.

Some things we can do easily here:

@epriestley and @mattflaschen I have created a windows installer here https://github.com/paladox/Arcanist-installer-for-windows

There are free installers that create the installation we want like

OK, after installing all the necessary extensions and changing the php.ini as recommended by phabricator everything works nice.

OK, I'm going to switch to php7 and see if it goes.

T10586 is likely a second case (similar to T7248) of a user without mysql or mysqli.

T9640 is tracking PHP7 compatibility. We haven't extensively tested Phabricator on PHP7 yet, but I believe several users are running it without any issues. We're happy to fix issues you encounter with PHP7 if you report them.

@epriestley that is from PHP 5.6.17