6 months ago maybe? Phriction Documents now support full policy controls and are no longer "magically" tied to Projects. T7005 covers adding back some functionality of auto-connecting them to Project pages.

Was the feature of projects having wiki pages removed? I cannot figure out how to set this up on my installation.

+1 for just adding normal comments at the foot of the page, below the main document content.

Assuming things don't change up too much, maybe something like:

since my current problem is the nesting limit, not the doc count limit, can we make it "more than 250 OR more than 2 nested levels"?

What about making the full list a dialog? If there are more than 250, then show a button on the hierarchy box to see the full list, which then just displays dialog. That way later we can add search or other things to the dialog if needed.

ok... yet another solution:

The core issue is Phriction itself doesn't have the robustness to allow organizations to build structure in their documents (ie, be a real CMS). Some of these features are already roughly planned out. Relying on a tree of hundreds or thousands of links isn't the solution we intend to pursue, we'd rather solve the issue in other ways. We're not apt to accept stop gap solutions if it means they'll have to be removed down the road.

case in point: to answer your question took *many* clicks... 5 levels (less than 100 docs).

https://secure.phabricator.com/book/phabcontrib/article/feature_requests/ covers what we look for in feature requests.
https://secure.phabricator.com/book/phabcontrib/article/contrib_intro/ covers how to contribute to Phabricator.

How many documents / levels do you have @metagriffin?

good point. how about an ajax call? i.e. any time a level is expanded it returns a json array of the documents in that branch (a spinner is displayed while fetching).

send the entire document tree to the client

i find the current display of documents a little lacking: it is a bit misleading (because there are effectively hidden documents), it gives a poor overview of the entire document landscape, and it forces a lot of extra clicking & reloading if i am trying to get to a deeply nested document.

In T7325#97766, @devurandom wrote:

I added myself to that project. I cannot expect that from everyone on my site.

Please also note that in my reports I try to give the most simple steps for reproduction. I might report an issue which includes steps done by someone else, and still write "I" for simplicity.

I added myself to that project. I cannot expect that from everyone on my site.

I didn't realize this got morphed into something "general".

I'm not sure how you made all these other edits then?

/w/generic-url is private to that project. I cannot even view it without cheating myself into the project by force of my admin powers.

...in theory this should now be clear to you from rP0a0ac1142953.

You should visit /w/generic-url, specify some content along with the other edits you seek, hit save, then delete the document again.

Does rP0a0ac1142953 also solve T7325#97666?

In D11829#114759, @epriestley wrote:

I think tailoring the error message is sufficient. Letting users edit the title of deleted documents feels weird / surprising.

since i'm in there

One way to delete a wiki document is to clear the document body and hit "save".

In T4768#59424, @epriestley wrote:

We can probably do conflict detection fairly easily, but conflict resolution is more difficult.

If you put the project back under the original name, then upgrade, the policy will be set correctly after the upgrade.

It's all policy based per document, so more flexibility.

I didn't notice. And I have surely not the latest version of Phabricator! :)
At this point the question is if the problem will arise during the upgrade, or it is managed in some way?

There isn't a project wiki in Phabricator, it was removed many moons ago.

Sounds like you'll be happy in a post T3670 world. :D

In our scenario, we have members of various teams who can control deployments, as well as the DevOps team (all of who can control deployments). We could create another project which is "DevOps + Deployment Managers", in addition to the "DevOps" and "Deployment Managers" projects, but this seems like more maintainance of projects (what happens if someone is removed from "DevOps" but not "DevOps + Deployment Managers"? They'll still be able to access stuff that they should no longer have access to.)

In T7140#96200, @hach-que wrote:

The way policy works is clearly understood, it's just impractical when you want to open up a bunch of wiki documents. This is impractical when you have a parent document and 20 children; yes I could go through and update the policies on all 21 documents, but it's annoying and tedious.

In our scenario it was that we wanted to add another project to the list of "members of projects" policy on who could view the deployment-related wiki articles. With custom policies, not only did I have to update all of the child documents, but I also had to go through the custom policy editor for each one.

I should add that the way Phragment currently solves this problem is that it has a "Replace policies on child fragments with the policies above.", but this seems less appropriate for Wiki articles (given that you might want to have a child document with a more restrictive policy than it's parent, whereas for Phragment you're usually updating policies for ZIP archives and all their files).

The way policy works is clearly understood, it's just impractical when you want to open up a bunch of wiki documents. This is impractical when you have a parent document and 20 children; yes I could go through and update the policies on all 21 documents, but it's annoying and tedious.

This may be too subtle, but the policy is "what the policy is on THIS doc *and* I have to be able to see all the parents". Thus, things currently work like

Thanks for the tip. I successfully deleted the document.

projects used to be a keyword, with all sorts of automagical hooks between Projects and the wiki. This has been deprecated.

This stuff was fixed in connection with T4029. That work happened in late October / early November, and your install (Oct 8) predates it. I expect that things work as you expect them to at HEAD. Let us know if you still see issues with new files after updating.

@epriestley the most recent commit hash is: 19db3fbb605cd1f304927a9c094098bdcbdce517. It's a few months behind.

@mrbrowning, what version of Phabricator are you running?

Not sure I understand the issue, can you not set it to All Users by default already?

Looks like its not JS related, disabled JS and the issue persisted, disabled CSS, works.

Haha, yeah, I broke it right before that. This broke saving basically saving anything so I noticed it right away.

alrighty, haha, i just updated 10 minutes ago. ;-)

We are likely to move Conpherence to Source Sans as well, so shoring up any issues will be important.

@chad
Thanks for adding latin extended font. And my firefox supports woff2 already (I use this version).
And the font rendering issue is only reproducible on my laptop, currenty I work on my normal computer and phirction looks fine. My laptop has Windows 8.1 x64 Polish version. Perhaps the issue is triggered by language settings. Anyway I hope updated woff2 fonts to solve the issue. Currently I use this fonts on my local instance (woff, not woff2):
http://fonts.googleapis.com/css?family=Source+Sans+Pro:400,700&subset=latin,latin-ext
Also the issue is not reproducible on IE.

In T7066#93472, @chad wrote:

Firefox doesn't officially support woff2 (http://caniuse.com/#feat=woff2) but this is a step to supporting more languages on some browsers. I'll continue to look into building more support (we really like Source Sans).

In T7066#93467, @chad wrote:

Latin Extended according to Adobe:

Welsh, archaic Danish and Esperanto.

Firefox doesn't officially support woff2 (http://caniuse.com/#feat=woff2) but this is a step to supporting more languages on some browsers. I'll continue to look into building more support (we really like Source Sans).

You can see if D11545 renders any better or not, not sure I see a difference.

Latin Extended according to Adobe:

Well, mine install + This one looks ok. On firefox at least.

I built a version of "everything" Source Sans as a woff2 file in my sandbox, I just can't seem to find a place where it actually fixes anything. I did something similar to my local sandbox like you're Phriction document.

Hey @chad - Latin Extended would be useful for anybody in central/eastern europe. It does make font bigger, but some DO need it (and it may look horrible without it). My install also looks fine, so maybe I simply have good set of fonts already present on my system and Firefox selects proper ones?

I'm not able to find a reproducible case here, I tested current Firefox (35) in Mac, Windows, and Linux:

If you could provide a testable Phriction document on this install, that would be very helpful.