ApplicationEditor

The major change this week is that ApplicationEditor landed against Maniphest. It is currently deployed and configured on this server (secure.phabricator.com) and seems to be working fairly well, but has not been promoted to stable yet because of the large scope of the change.

• T9905 has a summary of user-facing impact.
• User Guide: Customizing Forms is the best place to get started with the new form customization features.
• T9908 has some additional context and chatter.

Development is largely paused here for the moment (which mostly means that we aren't immediately converting every other application):

• I want to use it for a bit and be more confident we've worked out most of the kinks.
• I'm not totally satisfied with some of the internal UI/UX, which feels "clunky", and want to think about how to improve it.
• I want to give impacted installs more opportunity to provide feedback about navigating disruptions in T8434 / T9905, to make sure they have reasonable pathways forward and that we're generally headed in the right direction.

Land Revision

The "Land Revision" feature can now target branches other than master. T9952 has some details about the conditions under which this works (and how it works). T182 has discussion of the feature as a whole.

Phame

@chad did a lot more work on Phame, and we're getting closer to taking it out of the prototype phase.

We've removed skins, and I officially abandoned D3720, which contained most of a glue-layer which would have (in theory) let us run Wordpress themes in Phame. Although I find the idea of building this hilarious, no version of skins ever worked very well and they don't seem particularly important in the modern era of Medium and other skinless blog engines. It's possible we'll look at restoring skins in some future version, but it was an easy decision to cut them for v0. Our current thinking for the near future of the product focuses more on adding ways to enhance the builtin skin than supporting reskinning.

Upcoming

A major goal of recent ApplicationSearch / ApplicationEditor work has been to eventually fix broad architectural problems with the Conduit API that leads to many methods being inconsistent, unavailable, or otherwise missing features or functionality. Today, many Conduit API methods are basically copy/pastes of the equivalent web UI methods, but they don't necessarily get updated when new features are added. As a result, they're often frozen in time near v0 of the corresponding application.

Among other things, the ApplicationSearch and ApplicationEditor infrastructure changes give us an opportunity to drive Conduit methods through the same search/edit code that the web UI is driven by, so new features will immediately be reflected in the API without adding additional dedicated code. T9964 describes the next steps toward this.