Both of those options are locked in the UI. "This configuration is locked and can not be edited from the web interface. Use ./bin/config in phabricator/ to edit it." I know the basic syntax is phabricator/ $ ./bin/config set <key> <value>, is it just a case of

It's fairly straight forward to add your own linter extensions as well, the only thing that becomes difficult if how you distribute them. Upstream doesn't help with this at all but you should be able to figure it out from the wiki if you have a need for them.

Thanks for the report. This should be fixed in HEAD of master, and fixed in production some time in the next 24 hours when the docs regenerate.

Those changes add a fairly coarse disk-based cache here for use by the CLI. I expect it to shed ~95% of the load and make the admin tier stop glowing white-hot 24/7.

Follow PhabricatorSearchEngineExtension or similar.

If you only knew how lucky you are to have Evan explain this to you rather than trolling through grep -Rn "PhutilClassMapQuery" * --include \*.php errday.

(The second step is because some types of attachments work on multiple object types, and you could even conceivably write an "edge" attachment here that just works for anything and returns all edges, although I'm not confident that doing so isn't a major security problem.)

I think you've already written these, but the budget walkthrough is:

Live, armed, pre-commit A/B testing is unambiguously the most exciting part of our jobs.

For the record, I strongly endorse autopatching unreviewed code onto live, armed, autonomous combat vehicles.

Internal attachment is definitely the shortest path. Whatever we end up with is likely to look very similar to the naive version, and you can keep your attachment running after we offer an "edges" attachment, so there shouldn't be any real transition cost.

Should we implement this as an internal search attachment in the meantime? Or is there a possible pathway for @jcox to get something like this working in ~3 days?

This is basically a special case of T5873.

I'm thinking we just create a search attachment for maniphest.search which contains diff PHIDs.

Probably a bug. I spent like 5 minutes trying to get that field to work, inspecting the db, rebuilding search, etc, and link field never seems to get indexed.

Any thoughts? If it sounds like a real bug I'll file a report.
(meant to add this as a comment, but accidentally added an answer)

Found some shorter repro steps:

Ahh okay. I understand now. That did indeed happen automatically.

If you give a Phurl an "Alias", you can type ((thatalias)) in Remarkup to reference it. For example:

Also the ((alias)) syntax should use the most-preferred URI, although I think that will happen automatically.

I added a note about this to T7338 for the longer term.

That should really have been in a day 1 "spend 10 minutes doing this stuff first" document, I started collecting this stuff in T11561.

Also, are prototype applications enabled (phabricator.show-prototypes)? If not, Phurl won't actually be installed.

Alternate/simpler test is "does /phurl/ work".

Also, are prototype applications enabled (phabricator.show-prototypes)? If not, Phurl won't actually be installed.

Ah, okay. I'm not immediately sure, then -- did you restart Apache / is /config/edit/phurl.short-uri/ picking up the change?

I suppose we could link to /config/module/site/, which has a list of all Sites, but it's probably not intuitively obvious from there what's going on. It's also possible in some future world to reach this screen without running Phabricator at all (T1806), although probably unlikely.

Oh I left out the fact that I had already configured phurl.short-uri but still get the "Site Not Found" message.

First screen is good.

Just want to sanity check this before I continue. I set the ServerAlias and started getting this page when visiting short.url.com:

I've updated both hosts and manually fixed D16464 to display the correct changes.

Yeah, I just neglected to push secure002 when I pushed secure001. I'll fix this shortly.

Oh, this looks like a smoking gun:

There's no changeset in the database, so this isn't just a weird permissions issue -- legitimately, no changeset was extracted.

bin/differential extract rPHU491ebc74d816dbe2fc8bbbbc992e8a14f8c613be also extracts the change correctly:

This might actually something more narrowly scoped since, e.g., D16468, D16469, and D16470 worked fine.

Thanks @chad. I would say it's the same for the visibility part, but not for the filtering support by custom fields.

Ah, yeah. If you're using Apache with <VirtualHost /> directives, try something like this?

This is T4863.

I'm unable to get URL shortening to work locally. Is there some apache configuration required to get it working?

Its seems that when i am pressing run build from the web interface it gets stuck in the building part while if i execute

@chad Could be. I wasted a whole day on this. Anyways i moved to ubuntu now and it seems to be working pretty well there.

Giving full access to all users for the host repo folder solved the issue. As this is a vulnerability, I shouldn't left it as 'chmod a+w'.

I have the same problem.

difficult? right?

Maybe T4947: SELinux / AppArmor ruin everything all the time?

Just to be sure i reinstalled the whole thing in a new machine(Centos 7), but was still getting this issue. I switched to ubuntu and it works fine for me. I followed this one as well but still din't make it to work. https://blogs.gnome.org/aklapper/2014/11/10/phabricator-on-fedora-20/

I think it's just adding implements PhabricatorApplicationTransactionInterface, then adding the methods for that.

I poked at it, but wasn't immediately obvious. I can poke again tomorrow.

Also to fix.

I think this is straightforward to fi.