"Phabricator" and "Phacility" are trademarked names, and the logo is copyrighted. To start an initial fork we need update the source code and remove references which identify the product as Phabricator in order to abide by trademark/copyright laws and expectations. This particularly needs to be done so that changes to the product are clearly reflected as being work done by Phorge community/organization and not Phabricator/Phacility.
EvanP has communicated that he would be willing to accept an upstream patch that makes the branding of the site configurable/convenient. The primary diffs which pull out mentions of "Phabricator" and "Phacility" should be done in a means that it would be accepted upstream.
The ideaoverall strategy for this looks roughly like:is:
1. Extract out the words "Phabricator" and "Phacility" from user-visible strings, in both rP and rARC , to instead pull the project name and organization from a single static method (one method in rP which pulls the hard-coded value defined in rARC).
2. Leave the hard-coded values as "Phabricator" and "Phacility"Coordinate with upstream to create a revision that easily enables rebranding of the project
- So far EvanP has made some changes (though not yet landed) which remove most uses of "Phacility" as well as his username from the application, and also remove other miscellaneous things like the ubuntu/centos installation scripts (which use "Phacility" and "Phabricator").
2. Create a new fork of Phabricator to start Phorge from, based on these rebranding upstream changes
3. First diverging commit to be re-brand as "Phorge"
4. Submit theRe-apply our current landed change upstream to Phabricators
For #1 the strategy is going to be
4.1. Create a handful of static functions to `getPlatformName() = Phabricator`, Everything goes perfectly and the changes are adopted`getProjectRepo() = phabricator`
5.2. Make updates to appearances of "Phabricator" in the interface to prefer, Pull in the accepted changes from upstreamin order:
6 1. Removing the name if it's not needed in context
2. Replace the project name,ing the name with a generic reference (e.g. organization name,"the platform")
3. andReplacing the logo/faviconname with Phorge-branded assets`getPlatformName()`
3. Make updates to uses of `phabricator` as a path to use `getProjectRepo()`, including `phutil_get_library_root()`
4. Add a ReMarkup parser that can swap out something like `${{{ platform.name }}}` to use `getPlatformName()`
5. Update diviner documents to use this new remarkup block to allow easily re-branding the documentation
- Note however that document titles do not use remarkup for rendering, so a different solution will be needed for where "Phabricator" appears in diviner document names.
6. Update code which produces links to diviner documents based on the document name to do a similar platform-name swap out
7. Create new diviner documents based on user-exposed references to `Tnnnn` or `phurl.io`, based on the relevant content hosted on `secure.phabricator.com`
8. Updated references to `Tnnnn` or `phurl.io` links to instead link to the new diviner documents
9. Leave HTTP headers and Email headers alone for now. I'm not sure there's anything reasonable that can be done for these (it might be possible to update HTTP headers without any regressions though I'm not familiar enough with what they're used for).
Additionally EvanP provided a proof-of-concept which would allow for mass-renaming files to strip out "Phabricator" but still allow classes defined as `PhabricatorXYZ` to be loaded by PHP. This works through some reflection hackery and would require us to build a mapping of old classname -> new classname. This would allow us to more confidently rename classes, Completeas any used via reflection would still load properly even if using the old class name.
---
Various places identified as indicating "Phabricator"
- [ ] Various places in the settings
- [ ] Auth app
- [x] Diviner mentions Phabricator in the command line example for building docs and additionally calls it Phabricator documentation
- Marking as completed because this is being addressed by {T15012}
- [ ] Emails mention Phabricator in various subjects, bodies and sender names
- [ ] Logo, Phorge-branded assets to be created via {T15005}
- [ ] `./NOTICE` has some legal text we might need help with.
- [ ] Emails have a bunch of `X-Phabricator-*` headers, for configuring rules in mail clients.
- We may want to allow installs to keep it as `Phabricator` for compatibility
- [ ] `PhabricatorAphlictManagementWorkflow.php` has several hard-coded paths assuming the project is checked out under the directory name of `phabricator`, which will need changed to checking `phorge` first and then `phabricator` if it doesn't exist, otherwise installing Aphlict will fail to locate the default configuration file for anyone starting from a fresh install vs. updating their existing checkout.
- [ ] `PhabricatorDaemonsSetupCheck.php` creates several setup issues with `.addCommand('phabricator/ $ ./bin/phd ...')`. I believe this is just text that is displayed to the admins of a site however the `phabricator/` here represents the repository of the project. This along with the above issue related to Alphict assuming `phabricator` as a directory name we may need to extract out a similar "project repo name" to be used in these places.
- [ ] `PhabricatorPHPPreflightSetupCheck.php` creates a setup issue which includes a link using `https://phurl.io` -- these Phurl links will direct to content hosted on `secure.phabricator.com`. I'm not sure what to do about these. In this case the content being linked to is https://secure.phabricator.com/T12101. We probably need to extract the content into a Diviner doc and link to that instead? Looking at some of the other setup issues linking to docs/content it looks like there's a way to do this via `PhabricatorEnv::getDoclink('Managing Daemons with phd')` which I'm assuming links to https://secure.phabricator.com/book/phabricator/article/managing_daemons/.
- [ ] `PhabricatorConfigConsoleController.php` the `loadVersions()` method has hardcoded references to `phabricator` and `arcanist` repository names which are used to inspect the version. It also inspects the git repository looking for remotes that are hosted on either `github.com` or `secure.phabricator.com`. We will need to update the repository name checking and the remote locations to swap `secure.phabricator.com` to `we.phorge.it`.
- [ ] `PHUIBadgeExample.php` creates an example "Lead Developer" badge with the title of "Lead Developer of Phabricator" which we can change to "Phorge" but has a "source" of "Direct Award (epriestley)". This page is all example usage of UI mostly for Phabricator developers. I'm fine with keeping these types of tributes to `epriestley` but we should check with Evan if he'd like to have his name removed as well. Checking on https://secure.phabricator.com/uiexample/view/PHUIBadgeExample/ it doesn't look like this actually appears in the UI but this might be a bug -- in the resulting HTML this information does appear and is supposed to show on the "back" of the badge when it's flipped over by clicking it.
- [ ] `PhabricatorEnv.php` in the `initializeCommonEnvironment()` and `getEmptyCWD()` functions there are hardcoded calls to `phutil_get_library_root('phabricator')`. When we extract the repository name we will need to search for other uses of `phutil_get_library_root()` as there are likely other `phabricator` we need to extract.
- [ ] `PhabricatorEnv.php` in the `getDocLink()` function it hardcodes the project URI to `https://secure.phabricator.com`.
- [ ] `scripts/sql/manage_storage.php` script sets a multi-line synopsis using `<<<EOHELP` block which is not translated using `pht()`. We might just need to address this in a separate diff to hardcode "Phorge" after the other changes. Although in other PHP scripts it looks like this can be sent through `pht()` (see `PhabricatorClusterConfigOptions.php` use of `<<<EOTEXT`)
- [ ] `scripts/sql/manage_storage.php` will spit out an error during an exception which references `phabricator/ $ ./bin/config ...`, there are likely numerous of these throughout the `scripts/` files.
- [ ] The following SQL migration files print translated text with "Phabricator". These could be changed but are also probably fine to leave as-is.
- `resources/sql/patches/20130820.file-mailkey-populate.php`
- `resources/sql/patches/20130611.migrateouath.php`
- `resources/sql/patches/20130820.file-mailkey-populate.php`
- [ ] `PhabricatorCoreConfigOptions.php` an example for `phabricator.base-uri` is given as `http://phabricator.example.com/`. This should be changed to `https://phorge.example.com` in a separate diff after everything else is merged. Same with `phabricator.production-uri`, `phabricator.allowed-uris`. This also shows up in the `didValidateOption()` function when an exception is thrown with an error message.
- [ ] `PhabricatorMetaMTAConfigOptions.php` defines `$single_description` to be text that includes example email addresses using `phabricator@example.com` which should be updated after the changes are merged.
- [ ] `PhabricatorMySQLConfigOptions.php` defines options which default the `storage.default-namespace` to `phabricator` as well as mention that value in the description.
- [ ] `PhabricatorSetupIssueView.php` uses `hsprintf()` to print out `phabricator/ $ ./bin/config ...` text, another hard-coded repo reference
- [ ] `PhabricatorSetupIssueView.php` has a function `renderRestartLink()` which looks up a Diviner book by title, "Restarting Phabricator" which will need to be updated to match our Diviner book.
- [ ] `PhabricatorOAuthServerApplication.php` has a function `getHelpDocumentationArticles()` which retrieves a Diviner doc by title, "Using the Phabricator OAuth Server". This will need to be updated to match our Diviner book title.
- [ ] `PhabricatorSpacesNamespaceEditor.php` the `getEditorApplicationClass()` function is returning a translated version of a class name. This looks wrong and the call to `pht()` should probably be removed?
- [ ] `PhabricatorProjectBuiltinsExample.php` has a function `renderExample()` which calls `phutil_get_library_root('phabricator')` which will need updated to use the project repo name instead.
- [ ] The following bash scripts print out "Phabricator" and will need updated
- `scripts/install/install_ubuntu.sh`
- `scripts/install/update_phabricator.sh`
- [ ] `PhabricatorBaseURISetupCheck.php` has a function `executeChecks()` which uses `https://phabricator` in example text. This will need to be updated.
- [ ] `PhabricatorBaseURISetupCheck.php` also uses `phabricator/ $ ./bin/config ...` example that will need updated to use the project repo.
- [ ] `PhabricatorBinariesSetupCheck.php` renders a reference to `T3046` which is only valid reference on `secure.phabricator.com`. Probably make a Diviner doc for this information and link to that instead.
- [ ] `PhabricatorBinariesSetupCheck.php` includes a path reference to `phabricator/support/bin/` which will need updated to use the project repo.
- [ ] `PhabricatorConfigExtraSetupCheck.php` uses `csprintf()` to give several examples with `phabricator/ $ ./bin config ...` which will need updated to use the project repo.
- [ ] `PhabricatorConfigExtraSetupCheck.php` prints several references to tasks using `Tnnnn`, we will need to build Diviner docs to cover this content and update references to link to those instead.
- [ ] `PhabricatorManualActivitySetupCheck.php` has several examples with `phabricator/ $ ./bin/...` which will need updated to use the project repo.
- [ ] `PhabricatorManualActivitySetupCheck.php` renders several links to `phurl.io` addresses which redirect to a tasks/content on `secure.phabricator.com`. We will need to build a Diviner doc with this information update the link.
- [ ] `PhabricatorMySQLSetupCheck.php` has a use of `phutil_get_library_root('phabricator')` which will need replaced with the project repo