Change Details

Extension installation requires three steps: - `git clone` the repository into `phorge/src/extensions` - `arc liberate` - `bin/storage upgrade` For an extension author, a lot of work goes into making sure it is set up correctly. For example, R5 needs [[ https://we.phorge.it/source/diagrams/browse/master/src/storage/patch/DiagramPatchList.php | DiagramPatchList.php ]] though the code is very reusable. Therefore, I believe we can simply the installation of extensions substantially, perhaps one day allowing for the semi-automated installation of extensions. Here is what I propose: - For an extension to be valid, the extension author needs to run `arc liberate` on the extension. This will generate `/src/__phutil_library_init__.php` and `/src/__phutil_library_map__.php`. In addition, the file `src/application/ExtensionNameApplication.php` is already required as it registers basic extension information. We will then need to make some adjustments to Phorge to automatically scan and load extensions (rather than `arc liberate`) that contain these files. This will also allow extension authors to use functions such as `phutil_get_library_root()` without worrying if their extension is loaded since Phorge will do it automatically. - Assume that all SQL patch files are located in `src/storage/patch` and autodiscover them. Much like core patches, have Phorge raise an error when autodiscovered extension patches aren't applied, prompting an administrator to run `bin/storage upgrade` - Allow extensions to register Monograms programmatically. This would not affect routing or Remarkup (AKA you still need to manually register routes and provide Remarkup rules) but we can use it to handle conflicts. In addition, I recommend that extension monograms be 2+ characters. If extension authors are using one character or have conflicting monograms, show a setup error.

Extension installation requires three steps: - `git clone` the repository into `phorge/src/extensions` - `arc liberate` - `bin/storage upgrade` For an extension author, a lot of work goes into making sure it is set up correctly. For example, R5 needs [[ https://we.phorge.it/source/diagrams/browse/master/src/storage/patch/DiagramPatchList.php | DiagramPatchList.php ]] though the code is very reusable. Therefore, I believe we can simply the installation of extensions substantially, perhaps one day allowing for the semi-automated installation of extensions. Here is what I propose: - For an extension to be valid, the extension author needs to run `arc liberate` on the extension. This will generate `/src/__phutil_library_init__.php` and `/src/__phutil_library_map__.php`. In addition, the file `src/application/ExtensionNameApplication.php` is already required as it registers basic extension information. We will then need to make some adjustments to Phorge to automatically scan and load extensions (rather than `arc liberate`) that contain these files. This will also allow extension authors to use functions such as `phutil_get_library_root()` without worrying if their extension is loaded since Phorge will do it automatically. - Assume that all SQL patch files are located in `src/storage/patch` and autodiscover them. Much like core patches, have Phorge raise an error when autodiscovered extension patches aren't applied, prompting an administrator to run `bin/storage upgrade` - Allow extensions to register Monograms programmatically. This would not affect routing or Remarkup (AKA you still need to manually register routes and provide Remarkup rules) but we can use it to handle conflicts. In addition, I recommend that extension monograms be 2+ characters. If extension authors are using one character or have conflicting monograms, show a setup error. - Create a "blank extension" that we keep up to date, that extension authors can use as a basis for their own extensions. I recommend we have a simple repository with an empty extension and a ton of comments explaining exactly how to customize the template. - Create a Diviner book specifically for extension authors explaining the format and auto loaded information, as well as links to the classes you inherit.

Extension installation requires three steps: - `git clone` the repository into `phorge/src/extensions` - `arc liberate` - `bin/storage upgrade` For an extension author, a lot of work goes into making sure it is set up correctly. For example, R5 needs [[ https://we.phorge.it/source/diagrams/browse/master/src/storage/patch/DiagramPatchList.php | DiagramPatchList.php ]] though the code is very reusable. Therefore, I believe we can simply the installation of extensions substantially, perhaps one day allowing for the semi-automated installation of extensions. Here is what I propose: - For an extension to be valid, the extension author needs to run `arc liberate` on the extension. This will generate `/src/__phutil_library_init__.php` and `/src/__phutil_library_map__.php`. In addition, the file `src/application/ExtensionNameApplication.php` is already required as it registers basic extension information. We will then need to make some adjustments to Phorge to automatically scan and load extensions (rather than `arc liberate`) that contain these files. This will also allow extension authors to use functions such as `phutil_get_library_root()` without worrying if their extension is loaded since Phorge will do it automatically. - Assume that all SQL patch files are located in `src/storage/patch` and autodiscover them. Much like core patches, have Phorge raise an error when autodiscovered extension patches aren't applied, prompting an administrator to run `bin/storage upgrade` - Allow extensions to register Monograms programmatically. This would not affect routing or Remarkup (AKA you still need to manually register routes and provide Remarkup rules) but we can use it to handle conflicts. In addition, I recommend that extension monograms be 2+ characters. If extension authors are using one character or have conflicting monograms, show a setup error. - Create a "blank extension" that we keep up to date, that extension authors can use as a basis for their own extensions. I recommend we have a simple repository with an empty extension and a ton of comments explaining exactly how to customize the template. - Create a Diviner book specifically for extension authors explaining the format and auto loaded information, as well as links to the classes you inherit.