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