When I put var_dump() in other parts of the code, I can see the output from /var/log/apache/error.log, but just can't see any output for the ones I mentioned above.

Er, almanac.service.search, rather.

D15345 adds these capabilities:

I can confirm this behavior. Is there any way to fix that ?

I think var_dump() will normally be hard to observe, since it will go to stdout but that isn't connected to anything by default so it will just vanish (we don't write stdout to the daemon log). My guess is that the code is running, you just aren't seeing the var_dump() output.

@sinayion don't start the phd service before mysql. The daemons need the database to be active.
I'd start phd after http and mysql are up and running.

It looks like "git push" in DrydockLandRepositoryOperation.php doesn't get executed.
I put some var_dump as the following, and click "Land Revision", but no related log printed out.

I think the most natural syntax (and the one I tried before discovering it didn't work!) would be to allow one to basically copy-paste the existing path at the top of file pages (the one inside the phui-header-header element), so that for example, a link to Diffusion's readme file on here would be: rP/README.md
And to link to, say, a specific line of a specific revision: rPbe0e84a81abc/README.md$17
And likewise for ranges: rPbe0e84a81abc/README.md$5-13

Let me know if you hit issues -- it should just be better in every way than maniphest.query was, but I might have missed some data or something like that.

Ah, thank you. I'll update to use that.

Broadly, *.search and *.edit endpoint are replacing older *.query and *.variousnameslikeupdate endpoints, see:

It's present in maniphest.search.

I noticed today that the maniphest.points field doesn't appear in the Conduit output for e.g. maniphest.query. I can't find a task addressing this, but it would be very helpful (I have several scripts that used our auxiliary points field, but since migrating that to maniphest.points they don't work any more).

My overall goal is to create a changelog automatically from the resolved tasks in Maniphest and I want to sort the changelog entries by category (like "GUI", "I/O", "Setup", "Documentation" etc.)

Sure, happy to bring those both upstream.

Implementation of what's described above - also seems to provide the expected results in my case, and limits impact to PHPUnit results. If a file is executed at all, it should show up normally; when completely untouched (which tends to show up with phpunit whitelisting, now necessary in the newest versions).

Our use-case: We usually plan our tasks max. 3-4 milestones in advance and the one currently being worked on is the most important / most looked at. We archive milestones that belong to the past (after moving all tasks to current / future milestones).

That seems totally reasonable. It seems like a bit of a stretch for PHP code specifically, but sane as a general-purpose answer.

Oh, this is probably actually $operation->setWorkingCopyVCSError(...);

To fix this:

Makes sense. Don't change it on my behalf then, I can see how this would benefit teams that plan sprints/milestones way far out.

See T8227 for discussion of why adding an option is a measure of last resort.

Could it be a config option for projects for milestone sort order, newest -> oldest or oldest -> newest? It would be nice to customize it.

Ah, I missed "In Diffusion". Let me see if I can reproduce there.

Your steps match mine. However, I'm not getting an "Action With No Effect" prompt; instead, the server acts like it's processing, and redisplays the page, but doesn't actually make any changes.

I'm not strongly attached to this behavior and don't mind swapping it and seeing how much pushback we get, it just seemed like the much better behavior at scale, and seeing it use on the Trello meta-board suggested to me that it was reasonable and possibly familiar to users coming from Trello:

oh! sorry.

:( I was just trying to help with the clear up of nonsense. I was looking for a way to close the task, but I thought at least I could remove one by merging.

Looks like maybe Macros aren't visible to outside people. Found https://phabricator.wikimedia.org/phame/post/view/1/what_s_new_lots_of_improvements_on_phabricator.wikimedia.org/

In T10412#160950, @epriestley wrote:

Change milestoneNumber in phabricator_project.project to reorder milestones.

@wuup, I undisabled you since I think you weren't part of the "click shiny buttons" activity this morning.

I think @wuup might have been an innocent bystander who was caught in the crossfire. Poor guy!

Can you walk us through what broad, overall goal you're trying to accomplish more generally? See Contributing Feature Requests and Describing Root Problems for help describing root problems. As those documents repeatedly emphasize, it's really important for us to understand root problems.

T4854 is also related.

I dug this up: https://github.com/websharks/comet-cache/issues/234#issuecomment-49382000

Here is also the subproject order, I had to archive some projects because the board was too large/cumbersome with them activated. We usually plan 2-3 sprints out, with some tasks moving further out if something blocks them. This ordering really hurts us being able to effectively move or change tasks as needed:

In T10412#161683, @epriestley wrote:

The logic is that if you have 50 milestones, you are probably much more interested in milestones 50, 49 and 48 (this week / next week / last week) than milestone 1 (a year ago).

I'm having trouble reproducing this -- I attempted to follow your steps, but didn't experience the issue. Here's what I did:

Here's how our main project board looks after the recent change:

I'm not sure I'd be more interested in Milestone 50 vs. Milestone 1. My assumption is the next milestone up is the most immediately on the left. And the furthest one out time wise, is the furthest one away.

We archive milestones so they don't appear on the board anymore.

The logic is that if you have 50 milestones, you are probably much more interested in milestones 50, 49 and 48 (this week / next week / last week) than milestone 1 (a year ago).

One specific thing we're starting to see more of is test users signing up and bulk-associating or bulk-merging large numbers of tasks. There doesn't seem to be any specific intent behind this, but I think these UIs are shiny and make it easy to click a lot of buttons and have a large effect. Here's one such user on this install, who has registered three accounts just because they like clicking buttons so much:

See also T4854 -- mod_pagespeed is known to be incompatible with Phabricator, and should not be used.

I am using the recent Bitnami Phabricator stack

In T10300#158235, @cburroughs wrote:

This has tripped me up a few times (maybe since arc was made great again?) and I think it happens when you do arc land foo instead of arc land in foo.

I'm also a bit confused why it is ordered Milestone 3 > Milestone 2 > Milestone 1. I would assume that the third milestone is the furthest target to hit and should be displayed on the right?