The next actions I plan to take here are:

Which version of phabricator are you running? Email I get have a plain-text alternate, have no meta tag, and are formatted very differently.

variables_order was indeed set to "GPCS". I changed it to "EGPCS" but it has no effect.

GC has caught up to Conduit and the conduit_methodcalllog table is down to 160MB from ~1GB.

bin/storage renamespace --from phabricator --to whatever --in whatever.sql > whatever.renamespaced.sql

I think the Leylines change didn't actually work because we make the call via the LB so the request appears to coming from outside the cluster.

Deploying Leylines + GC changes to admin now.

I used bin/files migrate to move some old files which were stored in MySQL before S3 was configured to S3. The file blob table is now down to 160MB from 477MB.

A big part of this appears to be that dumping the huge Leylines table locks it, so requests can't record their own Leylines data:

Changing the type is going to run into the issue of what to do about the fields which differ between the two types. Fields which are present in the old type will continue to be displayed unless you clear them when changing types.

Could you kindly suggest me extend which Remarkup rule for parsing a specific URL pattern into a token like we do for tasks like T5000.
I can't find where you do this exactly.

Specifically, I'd like to make these changes:

I think:

Things seem better here for me, although I'm still seeing a couple issues:

This is probably T12071. Does your php.ini set variables_order to something like "GPCS"?

@epriestley, what's weird is, I still have this on my bug install, despite having the latest stable updates. I checked, and the migration definitely ran. Thoughts on how to debug this further?

(Also, registration already requires filling out a CAPTCHA if CAPTCHAs are enabled, so adding a second CAPTCHA on this flow shouldn't meaningfully raise the barrier for attackers.)

I suspect these might be "security researchers" who are trying to demonstrate how Phabricator is rife with "critical vulnerabilities".

There is a task to create another target rendering engine, but I'm not able to locate it at the moment.

OK. But isn't it weird from an end-user POV to have unparsed remarkup there?
If it's a choice, you can close this issue! Thank you for your quick answer.

This is working as intended. We only have two choices for target rendering, full remarkup or text.

Thank you for the quick response and fixes!

In T12639#221773, @chad wrote:

I think this is T10038

I think this is T10038

What's the status on this right now? Looks like a fun thing to try and get over the finish line.

This would be useful for us as well, we want to migrate from using local authentication (which was very easy to setup when initially bringing up our server) to using LDAP authentication. We had most/all of our users create accounts using their LDAP username but using local authentication, but really we should have set up LDAP from the beginning.

Reference: Adding LaTeX support into the Phabricator team collaboration system
Should I extend PhabricatorRemarkupCustomInlineRule also?

• I deployed D17774 to secure.
• I verified that rSVNTEST now correctly raised an error because it was backed by a service with muliple hosts.
• I moved rSVNTEST and rHGTEST to a one-host service, securex-legacy.phacility.net.
• I can no longer reproduce any issues against this host.