recaptime.dev
@recaptime-dev's working patches + fork for Phorge, a community fork of Phabricator. (Upstream dev and stable branches are at upstream/main and upstream/stable respectively.)
hq.recaptime.dev/wiki/Phorge
phorge
phabricator
1@title Developer Setup
2@group developer
3
4How to configure a Phorge development environment.
5
6Overview
7========
8
9There are some options and workflows that may be useful if you are developing
10or debugging Phorge.
11
12
13Configuration
14=============
15
16To adjust Phorge for development:
17
18 - Enable `phabricator.developer-mode` to enable some options and show
19 more debugging information.
20 - Enable `phabricator.show-prototypes` to show all the incomplete
21 applications.
22 - See @{article: Using DarkConsole} for instructions on enabling the
23 debugging console.
24
25
26Error Handling
27==============
28
29Errors normally go to DarkConsole (if enabled) and the webserver error log,
30which is often located somewhere like `/var/log/apache/error_log`. This file
31often contains relevant information after you encounter an error.
32
33When debugging, you can print information to the error log with `phlog(...)`.
34You can `phlog(new Exception(...))` to get a stack trace.
35
36You can print information to the UI with `throw new Exception(...)`,
37`print_r(...)`, or `var_dump(...)`.
38
39You can abort execution with `die(...)` if you want to make sure execution
40does not make it past some point. Normally `throw` does this too, but callers
41can `catch` exceptions; they can not catch `die(...)`.
42
43
44Utilities
45=========
46
47After adding, renaming, or moving classes, run `arc liberate` to rebuild
48the class map:
49
50```
51phorge/ $ arc liberate
52```
53
54Until you do this, Phorge won't recognize your new, moved, or renamed
55classes. You do not need to run this after modifying an existing class.
56
57After any modifications to static resources (CSS / JS) but before sending
58changes for review or pushing them to the remote, run `bin/celerity map`:
59
60```
61phorge/ $ ./bin/celerity map
62```
63
64This rebuilds the static resource map.
65
66If you forget to run these commands you'll normally be warned by unit tests,
67but knowing about them may prevent confusion before you hit the warnings.
68
69
70Command Line
71============
72
73Almost every script supports a `--trace` flag, which prints out service
74calls and more detailed error information. This is often the best way to get
75started with debugging command-line scripts.
76
77
78Performance
79===========
80
81Although it is more user-focused than developer-focused, the
82@{article:Troubleshooting Performance Problems} guide has useful information
83on the tools available for diagnosing and understanding performance problems.
84
85
86Custom Domains
87==============
88
89If you're working with applications that support custom domains (like Phurl or
90Phame) you can normally test them by adding more entries to your webserver
91configuration that look exactly like the primary entry (or expanding the
92primary entry to match more domains).
93
94Phorge routes all requests based on host headers, so alternate domains
95do not normally need any kind of special configuration.
96
97You may also need to add `/etc/hosts` entries for the domains themselves.
98
99
100Creating Test Data
101==================
102
103You can create test objects with the "Lipsum" utility:
104
105```
106phorge/ $ ./bin/lipsum help generate
107phorge/ $ ./bin/lipsum generate ...
108```
109
110Test data can make your local install feel a little more realistic. With
111`--quickly`, you can generate a large amount of test data to help test issues
112with performance or scale.