I deployed D21062, and the three examples in the original report look good now. I checked about a dozen other pages and couldn't find anything else broken; let me know if I missed anything. Thanks for the report!

The second issue is that the API still returns a string when there is exactly one @attribute of a given type. This is a bit goofy; PhutilExecChannel is another example case.

I deployed D21061. First two example pages are good now, third one is hitting a different error. New trace is:

Docblocks may have multiple copies of the same @attribute directive, like this:

Here's the full stack trace:

The immediate issue now appears fixed and it seems likely that the root cause is also fixed. We should still hunt down the bad cache behavior in the presence of wonky permissions.

This cropped up again and the permissions error also resurfaced, even though I previously nuked the directory.

For now, I just hard-wiped the cache and regenerated the documentation again. ¯\_(ツ)_/¯

The file cache says that these files have already been parsed and contain no atoms, so the rest of the program behavior is expected after that. I'm not sure how this state came to exist.

• DivinerPublisher->publishAtoms() is being passed nothing, so it's correctly deleting everything.
• The graph cache is empty.
• The actual atom.cache file on disk is empty.
• The input to the cache is empty.
• The files aren't being passed to the atomizer rules (although the rules appear to be applying correctly).

So, so far it looks like the database is in a "good" state but the publish workflow incorrectly deleted all the articles. From previous efforts, I believe dropping the cache fixes this issue.

But note that the graphHash and nodeHash columns are 0, which I believe is a signal that these nodes have been deleted (I haven't touched this code in a while).

Oh, the contrib stuff got separated into a different book and has fully unpublished:

The "Contributor Introduction" document, specifically, seems to have unpublished. Let me see what I can dig up about the current database state.

I think a reasonable path forward here is for Diviner to have a {symbol} sort of syntax which executes a symbol index query. The symbol index can already be configured to know how to offer links to external documentation.

Per above, I think the pathway forward here is probably "tighter integration", not "merge/replace", i.e. tools for Diviner to automatically update Symbols, too. I'm just going to conceptually roll this up into T13047.

Embedding files by alias might be useful

Oh I see the problem with that

I've been locally previewing in Phriction.

I'd guess it's several days of work.

Is this hard to do? Can me accomplish?

+1 for random grepping. Thanks for the fix!

(Your diagnosis of the root cause was also correct.)

I deployed D17346 and rebuilt the indexes on this install with bin/search index --type DivinerLiveSymbol and behavior now seems correct. Thanks for the report!

I think the major intent was being able to edit "View Policy" so you could create private documentation, but I don't recall if we got that far.

You could tag a project I think, but not sure what that actually did.

Basically nobody is using Diviner, and I don't think the "Edit Book" page actually does anything useful.

I see the same behavior noted by @lianghu in T9042#129510.

Thanks!

This is probably very easy to fix, let me spend 3 seconds on it.

Yes, Phurl provides URL shortening. U10 is the root object providing ((prototype)).

Yeaaah, I would assume this worked for free with Remarkup, but I guess not. Yeah it's Phurl,

So this actually in Phurl (not clear from the link) and not valid itself because Phurl is a prototype?

Phurl is a prototype, too.

+1, especially with all the new types in PHP7 this would be awesome.

Ugh, it's too hacky. I'm just going to put a manual redirect in place for now instead.

I'm just going to put a redirect map in the book for now. This isn't a great long-term solution but I want to move forward on D13941 in some form.

To add to the comment of @cburroughs above, it would be useful to cater to existing workflows.

In this case, we should maybe have a way to put a redirect in Diviner, since this atom has legitimately moved here:

I guess that we should return a 404 (or even 410)

Yeah. I will probably end up just writing my own NodeJS script to parse and interpret the CSS documentation.

That looks like it could be pretty complicated to do safely.

Ah yeah, I'm not really talking about HTML within the comments themselves (although I'm sure we will have to deal with that as well). Specifically, this is the tool that has I have been referred to: https://github.com/kss-node/kss-node

Ah, interesting. The cases I'm familiar with are Javadoc, like this lovely example from Oracle:

Yeah, agreed on avoiding it if possible. I just got asked about CSS documentation which I have no idea about but there are existing tools which spit out HTML. I will look into what would be involved to parse the HTML.

My guess is that we can satisfy this by parsing a small, safe subset of HTML (bold, italics, tt, links).

What about the ability to publish arbitrary HTML into Diviner? This is not ideal, but it means that any documentation system can be integrated.

I don't think there's anything specifically actionable here. If your build server has direct access to the Phabricator database (it never should) I think we get this for free as soon as "lease host + build working copy + run command" is reliable.

Great, thank you! :)

We aren't going to ship with the Phriction content.

Seems fixed.

It seems counterintuitive to me.

This behavior seems fairly expected/reasonable to me.