Kindly flagging as "little fixes needed on unit tests"

gotta set it

like this I guess

git rebase master

git rebase master

I've added 2 unuseful tips but this seems not ready for production. Flag as "solution seems affected by N+1 query problem". Maybe useful to open a cute task and do more triage.

I've tested in my console:

Relevant report:

Super nice prototype but flagging as "more digging probably needed for production"

oh true that! sigh I should look around a bit more

FYI I pasted the list of the 341 different FA icons used by Phorge as of 2025-04-24 (excluding the list of all icons in PHUIIconView::getIcons()) in P50

Argh, PEBKAC, right. Thanks!

[acko@fedora phorge (master *$|u=)]$ ./bin/storage upgrade
Target                          Error
phabricator_paste.paste.mailKey Surplus

In T16035#21876, @avivey wrote:

FontAwesome doing the freemium thing makes me sad, and I'm worried about misinterpreting their license (e.g., I think the fa-regular is not part of free, but is available on the GH repo for paying customers.)

Works for me: (on rPdfe8539c6a)

All these options make me want to just go with Sprites (See "Tokens" and "Authentication" in https://we.phorge.it/uiexample/view/PHUIIconExample/).

I can reproduce with the embedded copy of FontAwesome. I cannot reproduce if I use Fork Awesome 1.2. Switching over as a stopgap is a potential solution, especially because it offers SVG support, which can pave the way for a native-SVG replacement.

@mainframe98: Does ./bin/lipsum generate pastes work as expected for you? I'm seeing errors here:

 OOPS  Generator ("Pastes") was unable to generate an object.
#1364: Field 'mailKey' doesn't have a default value

In T15891#21871, @aklapper wrote:

PhabricatorSearchDocument::isInnoDBFulltextEngineAvailable() could be completely removed and this class could instead check the DB software version via mysqli::get_server_info and PDO::getAttribute(PDO::ATTR_SERVER_VERSION) ?
I guess that's a topic for a separate task though...?

Now that rP7aee92b5e95cfc11059e9ff8788e5e53dc88e84d is merged (plus realizing that shouldUseMySQLSearchEngine() is only called in https://we.phorge.it/source/phorge/browse/master/src/applications/config/check/PhabricatorMySQLSetupCheck.php;7aee92b5e95cfc11059e9ff8788e5e53dc88e84d$106, plus seeing rP48a34eced28d82b77eb840d05702daffb8e3ddbb), maybe PhabricatorSearchDocument::isInnoDBFulltextEngineAvailable() could be completely removed and this class could instead check the DB software version via mysqli::get_server_info and PDO::getAttribute(PDO::ATTR_SERVER_VERSION) ?
I guess that's a topic for a separate task though...?

Quick and dirty way to test: Insert this in a random place (output listed after the // ):

$services = PhabricatorSearchService::getAllServices();
foreach ($services as $service) {
  phlog(get_class($service));                   // 'PhabricatorSearchService'
  phlog($service->getDisplayName());            // 'MySQL'
  phlog($service->getEngine());                 // Object PhabricatorFerretFulltextStorageEngine
  if ($service->getEngine() instanceof
      PhabricatorFerretFulltextStorageEngine) {
    phlog('yesh');                              // 'yesh'
  }
}

The sublevels of the tree can be made hidden, and they can be revealed when clicking on a specific parent. And if the user expands the tree to a large size, then it is worth limiting the maximum size of the panel and showing a vertical scroll when the maximum is reached.

Having the wiki's tree of contents on the side would indeed be pretty nice, I gotta say. This is especially the case on the landing pages of a given instance's wiki, at least until it inevitably sprawls to be gigantic ;)

No clarification why disabling users is not sufficient, thus declining.

git rebase master

Whitespace

Thanks! also for the freshly added unit test :3 :3

Seems fixed now. Thanks :3

Ok, I'll improve it, because I still have a lot to learn about Phorge and its source code, otherwise I'll fix those issues myself

If there is an issue in Phorge then please provide steps to reproduce in Phorge. Please also strip unneeded full quotes which make comments hard to read. Thanks!

In T15056#21737, @danielyepezgarces wrote:

T391929 In that task on Wikimedia Phabricator, I had put some issues

Steps to reproduce the bug:

• Enable the "Dark Mode (Experimental)" theme in Wikimedia Phabricator.
• Go to the Phabricator Workboard.
• Click on any button that has a dropdown menu.

And with these steps you can see the error like the images I have attached

I just checked that the issue can be replicated in the Accessibility workboard, on the Affects-Wikimedia workboard it looks good

In T15056#21750, @aklapper wrote:

In T15056#21737, @danielyepezgarces wrote:

@danielyepezgarces: Please always provide clear steps to reproduce something somewhere, in most recent Phorge itself.

In T16035#21703, @aklapper wrote:

but the "Regular" Icon Style is not available in the free version and is "Pro only".

I was wrong or misinterpreted. fa-regular-400 as part of the "Free" version exists at https://github.com/FortAwesome/Font-Awesome/tree/6.x/webfonts

git rebase master