In T9897#161715, @chad wrote:

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/

The ordering of blogs on the right /phame is (I think after looking at it) creation date. I'm not sure that is the more useful than just lexographical(?) and feels bit implementation detail-y.

Nevermind about that last point, I see

We'll probably look at adding an "Archive" state in addition to Published and Unpublished. That would remove it from most views.

Also, Phame appears to sort posts by descending post ID number so even if I write over an old draft with new content it's going to sort way down. This is more part of my usual workflow: write some content, decide against it being a good idea, can't delete, ???, write over?

I've fixed this but someone still left a draft on my internal blog that I can't now delete. I considered just writing over it but it preserves their username on the authorship.

This means that exploration by new users is irreversible and my list of draft grows monotonically and becomes progressively more cluttered over time.

Since T10477 was closed as a duplicate of this task but ctrl+f "delete" turns up nothing I guess I'll repost my comment here: I can't find any way to delete a Phame draft or post. This means that exploration by new users is irreversible and my list of draft grows monotonically and becomes progressively more cluttered over time. Because the URLs are prettified, it's also not clear how to use bin/remove to delete a post object or what the object ID might be.

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 T9897#151198, @epriestley wrote:

Couple of thoughts, not necessarily unbeta stuff:

• Now that I'm actually using Phame, figuring out some kind of monogram/remarkup thing for it would be sort of nice so it's a little easier to reference a post in tasks/wikis/etc (my use case is that when I write a "Development Log" or "High Horse Soapbox" post, I'm often providing context for things elsewhere, and want to link it from that place/places). I don't think actual POST123 monograms are great for this, but this motivate:

Although I guess that sort of doesn't really solve many/any problems. But we could embrace that by allowing a blog to be "unlisted" or something, maybe.

A possible workaround is to create two blogs (review, production), and use "Move Post" as a "Super Publish".

There may be "document review" built into Phriction at some point. I don't know if maybe we could generalize that to Legalpad and Phame as well.

My expectation is that if your company has significant process around posting a blog post, they likely are using a different product to manage that (ie, Google Docs). Wordpress doesn't even offer such a feature without a third party plugin.

In T9897#155081, @chad wrote:

If they can post to the blog, they can read the draft.

Ah, sure -- sorting the home page by first-publish date makes instead of creation date sense to me.

I've been using phame for an internal announcement blog (stuff like "we upgraded phabricator!"). I've found it helpful to write a draft when preparing the release, and then publish it whenever the release actually happens. One minor issue is that posts are displayed in the order they are drafted, not the order they are published. This means the "we upgraded on Thursday" post shows up on Wednesday, and is not even the most recent post since there was another one on Wednesday.

If they can post to the blog, they can read the draft.

I've been trying Phame out internally and it's pretty sweet. The one thing I could not figure out how to do (and maybe the answer is I can't) was how to share a draft with someone to read before it's published. I tried adding them as a subscriber to the draft but that did not give them permission.

I also might take a crack at fixing "human language diffs", I think I can get something which is worlds better than what we do right now pretty quickly (even if it isn't perfect) and it would be nice to be able to be smarter all over the place about communicating description/title changes and tailoring things for typo fixes, spelling mistakes and other minor edits. I think this is something we can get groundwork in place for and then improve gradually without needing to do any big rewrites or anything.

Yeah I wanted to patch that this weekend but haven't gotten to it. :(

The logic around what we send to blog subscribers is a little goofy right now, and sends them the entire post content on every update.

Definitely, let me get you a rough cut.

I've been wanting to have next/prev post, but wasn't sure how to build it. I can build the UI and let you handle the query?

Couple of thoughts, not necessarily unbeta stuff:

I think this stuff is basically in good shape, I'll follow up on the Phame stuff in T9897 and the arc stuff in T7715.

Verified! You guys rock!

This should be fixed in HEAD. Let us know if you're still seeing issues or we missed anything.

Even if it's not an everyone has a blog case, again, I can't imagine it's a common use case to regularly be switching blogs to post on. Again, this is just a convenience function (a "New Post" button that creates a new post for the last-posted-to-blog). Not required, just a nice to have.

Ah ok, I don't think we've considered the "everyone has a blog" case. It might get hairy.

Oh cool - that's a useful shortcut. But imagine that the primary use case is this sort of note taking where everyone has their personal blog, I anticipate that 95% of the time, people will be writing blog posts on the same blog they last wrote on. For the 15 people on our team, 100% of us only write on one blog which is our personal blog.

The + is a link to create new posts, may not be 100% obvious.

The only feedback I have is that since the "New Blog" button was added top Right (instead of, for example, "New Post" which would default to, say, the last blog that you posted to), I inadvertently created a new Blog when I meant to write a post.

Sounds like you're using it as we do, though.

Well we're about to unbeta Phame if you have any use cases we're not thinking of.

As an aside, if you guys ever want insight from heavy Phab users, let me and Nico know! We're so deeply integrated now...we even automate the creation of Phab tasks via Salesforce to manage our entire Client Services team's work flow to onboard new clients. :)

Awesome :) yes, I don't see any of us caring about the slugs. In fact I remember it being a bit of a nuisance to do this because we'd have 15 people all with the slug of, for example, 12/10/2016, so we'd all have to make them unique. :)

ah, true

Since slugs no longer need to be unique, I'm just going to simplify this whole process and generate them automatically from titles.

We don't have external references to Phame, only internal references within Phame itself. So no need to have the old urls work in that regard. It's just that clicking the links in the phame UI itself is an important piece we'll need to work.

Also, is the fact that the URL scheme changed an issue (i.e., do you have a lot of links to the old URLs in external systems)? We weren't aware anyone was really using Phame seriously, but I can write a little extension you could use to keep the old redirects working for a while if that's also causing you pain.

(the reason this issue is exacerbated for us is because the titles of all our posts are dates, which many folks use /'s for, so we have a ton of posts with this issue)

Yeah it's a critical part of our workflow :) back at Google there's this concept of "weekly snippets" that the whole company used to use and our engineering team here at Doctor.com models after that. It's really useful to get visibility into work. :)

We could also just bring that patch upstream, but I think allowing "/" in slugs is probably a decision we'd regret in the long term.

As a workaround, you can apply this patch locally, which should make things work for now:

I am stoked someone uses Phame though!

(maybe we can hack the route?)

I don't know how involved a migration script would be, @epriestley?

You can use the URL /phame/post/edit/775/

@chad Hi Chad, so how can we remove it if we can't edit the post? Is there a workaround to edit the post? Or some manual database change we can make? We have literally hundreds of blog posts as we use this feature internally to track weekly work (hence the urgency as now our entire company has lost visibility into each other's work), so it would be a nightmare to do manually...

You'll need to edit your title phame_title to fix the 404 for now (I don't think it's worth providing a retroactive fix). We should have always been removing / from Phame Title as it would have always 404'd with Live View.