Page MenuHomePhorge

Include information for installing required PHP version in Diviner docs
Closed, WontfixPublic


Building on my experience of setting up Phorge on php7.4 with Debian 11 (Bookworm).
Most modern OSes' distributions do not keep php7.4 available, as it is officially EOL on PHP upstream.

There's little information in the documentation about installing PHP on a system - which is surely on purpose, as there are many tutorials on "how to set up a LAMP server" and all its variants.
Someone installing Phorge would likely know where to look to do so, as we're clear about what's necessary to get Phorge running, and the packages are normally universal.
However, installing an EOL version of PHP is nontrivial, and requires either third-party package archives (e.g., PPA's, DPA's, AUR) or building PHP from source.

Sometimes, these third-party archives can bring in conflicts and other danger and trouble with your local package state, and make a big mess.

For instance, adding for their maintained php7.4 forward-port, meant that apt wanted to install apache2, despite already having nginx available.
The workaround took a lot of trial and error to find, and this issue had kept me from using Phorge after a necessary server upgrade.

This is all rendered moot with the implementation of PHP 8 support, but until that is the case, we're in a weird limbo.

This is mostly a note to myself to go in and touch the docs, and to others on how to tame the dragons which be here; but also a request for thoughts on how best to approach this, if even at all.

I can spin up some testing VMs with common server OS targets, and walk myself through the practice of setting up Phorge and php7 on each, take notes, and write the procedures down.


This is rendered moot by D25537: Update PHP versions in install guide: Remove 5, Add 8. and by further discussion in this task's comment thread - PHP 8 is de facto supported, and installing PHP 7 should be unnecessary.
I'll consider this task closed.

Event Timeline

sirocyl updated the task description. (Show Details)

I'll take your word on it that it's supported, though the current installation guide says otherwise.
Further, I had a few roadbumps on a fresh install to a new server with PHP 8, that I suspect may relate to strlen(NULL) behavior, but I did need to set up PHP 7 to make sure that was or wasn't the case.
(I'm in the process of reproducing those and working out a possible cause or trace. Some manifested as warning banners, one as a 502 on my end in the GitHub auth provider.)

I suspect PHP 7(.4) is (for now) the most stable option for running Phorge, and that's documented on the installation guide, as well, currently.

(I'm actively pushing a test environment's buttons to find bad PHP 7 -> 8 transitional behavior and report on it, so my project group can be sure on our production environment to have a more stable PHP 8.)

Oh, totally possible that I forgot to update it :)

Did you try post T15554/D25440 ? That's the cut-off from "crashes on php8" to "might show a log".

I'm on the latest pull, commit f81e821abf2b275d1778d02a018a4d0af7208be8.
A bit off topic here :) but I'll quickly sum up the issue I'm having (and am in the middle of trying things to fix):

  • Visiting https://[phorge instance]/auth/config/view/2/, where my Github auth item is, makes nginx dump a blank 502 page, no further info.
  • First instinct is to check the /var/log/nginx/error.log, where I get a PHP stack trace concatenated into one line, and an nginx header length error (reformatted for readability. the PHP error is truncated):
2024/02/12 08:45:54 [error] 201825#201825: *1 FastCGI sent in stderr: "
PHP message: [2024-02-12 08:45:54] EXCEPTION: (InvalidArgumentException) Call to phutil_nonempty_string() expected null or a string, got: PhutilSafeHTML. at [<arcanist>/src/utils/utils.php:2127]
PHP message: arcanist(head=master, ref.master=8ef1ead6aca0), phorge(head=master, ref.master=f81e821abf2b)
PHP message:   #0 <#2> phutil_nonempty_string(PhutilSafeHTML) called at [<phorge>/src/applications/auth/storage/PhabricatorAuthProviderConfigTransaction.php:153]
PHP message:   #1 <#2> PhabricatorAuthProviderConfigTransaction::getTitle() called at [<phorge>/src/applications/transactions/view/PhabricatorApplicationTransactionView.php:448]
PHP message:   #2 <#2> PhabricatorApplicationTransactionView::renderEvent(PhabricatorAuthProviderConfigTransaction, array) called at [<phorge>/src/applications/transactions/view/PhabricatorApplicationTransactionView.php:182]
PHP message:   #3 <#2> PhabricatorApplicationTransactionView::buildEvents(boolean) called at [<phorge>/src/applications/transactions/view/PhabricatorApplicationTransactionView.php:230]
PHP message:   #4 <#2> PhabricatorApplicationTransactionView::buildPHUITimelineView() called at [<phorge>/src/applications/transactions/view/PhabricatorApplicationTransactionView.php:209]
PHP message:   #5 <#2> phutil_escape_html(PhabricatorApplicationTransactionView) called at [<phorge>/src/infrastructure/markup/render.php:139]
PHP message:   #6 <#2> phutil_escape_html(array) called at [<phorge>/src/infrastructure/markup/render.php:97]
PHP message:   #7 <#2> phutil_tag(string, array, array) called at [<phorge>/src/view/phui/PHUITwoColumnView.php:203]
PHP message:   #8 <#2> PHUITwoColumnView::buildMainColumn() called at [<phorge>/src/view/phui/PHUITwoColumnView.php:121]
PHP message:   #9 <#2> PHUITwoColumnView::getTagContent() called at [<phorge>/src/view/AphrontTagView.php:161]
PHP message:   #10 <#2> AphrontTagView::render() called at [<phorge>/src/view/AphrontView.php:222]
PHP message:   #11 <#2> AphrontView::producePhuti

2024/02/12 08:45:54 [error] 201825#201825: *1 upstream sent too big header while reading response header from upstream, client: [My IP], server: [Phorge instance domain], request: "GET /auth/config/view/2/ HTTP/2.0", upstream: "fastcgi://unix:/var/run/php/php7.4-fpm.sock:", host: "[Phorge instance domain]"

From there, I saw what broke, quickly hopped to PhabricatorAuthProviderConfigTransaction.php and hackily coerced that value's type: $title = "" . $provider->renderConfigPropertyTransactionTitle($this); and it "works", albeit spewing the sanitized HTML text of the transaction title as expected.

Current troubleshooting in progress is:

  • run a ./bin/storage upgrade in case I missed it Done, no upgrade necessary, nothing got changed.
  • deleting the Github auth object directly using ./bin remove and re-creating it Done, still produces the same 502 in nginx and type error in PHP.
  • nuke this DB and install, completely start over fresh, and immediately attempt to add Github auth and view it. (in case it was something php8 bugged up and persisted into DB)
  • if that works, then spin up a new staging VM, install php8 as before, attempt to repro this again and if it bugs out, make a formal report about it :)

(After some troubleshooting for this one, it looks increasingly like a bona fide application bug and not a php8 issue, so I'll probably be making a bugreport about it.)

On it, thank you!

EDIT: That fixed it, wooo 😅

sirocyl triaged this task as Low priority.
sirocyl updated the task description. (Show Details)