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

In T9897#155081, @chad wrote:

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

My thinking is along the lines of the network operations team is writing a post that a data center will be unavailable on Tuesday and would like some people who are not networking experts to read it (to confirm that the salient fact that applications in the datacenter will be unavailable isn't lost to arcane BGB wizard jargon). It feels sort of awkward to give unrelated people write access just so they can read. I think this fits with the "internal announcements" theme but unless your internal company is huge is probably "nice to have".

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.

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.

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

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.

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:

Related, now that I've written a few internal posts I found myself wanting to link to a previous post in a way that would generate a backlink/mention.

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/

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.

a) How do I figure out the object ID for a phame post?
b) Please consider adding a delete button as part of unbetaing Phame.

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

This sounds like the root issue to me. How is Phame set up on your server and why are users creating random posts everywhere? We're not likely to add a delete option since it's inconsistent with Phabricator's policies.

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.

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?

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

Nevermind about that last point, I see

Sort default home view by first publish date, not creation date, so newly published stuff is at the top instead of lower down (whenever it was first written).

in the description that would address this, yes.

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.

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/

That's because macros are restricted to logged in users there: https://phabricator.wikimedia.org/applications/view/PhabricatorMacroApplication/ As logged in user everything is ok.

any plans/chance to implement search if you unbeta phame? T6383?

we have 5 blogs with many posts. it would be great if we could search for posts :-)

I can probably copy-pasta that feature.

@epriestley Any of what's left reasonable for me to accomplish? Or are they all super technical?

The major custom domain issue is that there's no way to specify a protocol (HTTP vs HTTPS) or port (although this is less important). In particular, http://blog.phacility.com/ works and is the default live URI for that blog, but we would prefer https://blog.phacility.com/ to be the default URI and for http to redirect to https.

We should probably change the behavior of "Custom Domain" so that there are two fields stored in the database:

• domainFullURI or whatever (a new field): stores a value like https://blog.example.com:12345/.
• domain (existing field): continues storing the actual host with no protocol or port.

We need to keep the domain field because blogs should have unique domains. In particular, these should always be the same blog:

http://blog.example.com/
http://blog.example.com:80/
https://blog.example.com/
https://blog.example.com:443/

If we don't require this, we run into various silly/confusing problems:

• Users would reasonably expect all of these URIs to lead to the same blog.
• We can't necessarily distinguish between a request to blog.exmaple.com and blog.example.com:80 anyway.
• There are sort-of attacks if users are allowed to create blogs, where an attacker can try to create a blog with a domain like https://blog.phacility.com:443/ and put evil content on it that looks like it's official.

So the workflow would look like this:

• User enters full URI (protocol + domain + optional port), like https://blog.phacility.com/ (UI is basically the same as it is now -- they still enter one value, it just has protocol + port now).
• Error if they don't enter "http" or "https".
• Error if they have a username, password, path, query string, or anchor/fragment in the URI.
• Write the full value to domainFullURI.
• Extract just the host, write that to domain (this will throw on duplicates since there's a unique key).

Then:

• PhameBlog->getExternalLiveURI() should respect the specified protocol.
• PhameLiveController->setupLiveEnvironment() should redirect from HTTP to HTTPS, or vice versa, if we're on the wrong one.

This is probably reasonably straightforward to implement, but may be a big pain to test locally. You can test custom domains like this:

• Add local.blog.phacility.com to your /etc/hosts file.
• Create a blog on local.phacility.com with that custom domain.

Testing HTTPS is trickier, although it's probably good enough to see that URIs and redirects get generated correctly even if https://local.blog.phacility.com/ doesn't actually work.

Custom domains probably need a way to link to an alternate root (e.g., the main company site).

Oh, and this is probably pretty straightforward, I'm just not sure what we want to do about it. Issue is that there's no link to get back to phacility.com from http://blog.phacility.com.

We could just add a couple of fields like "Parent Site Name" and "Parent Site URI" or something, which turn into a "Phacility" crumb at root level.

User enters full URI (protocol + domain + optional port), like https://blog.phacility.com/ (UI is basically the same as it is now -- they still enter one value, it just has protocol + port now).

For this, should I write a migration script to just add http:// for people who have already configured it?

Yeah, I think you can just do a SQL migration like:

UPDATE {$NAMESPACE}_blog.blog
  SET fullWhateverWhatever = CONCAT('http://', oldDomainColumn, '/')
  WHERE oldDomainColumn IS NOT NULL;

FYI, there is a report about a regression from multiple users at WMFs-Phabricator: https://phabricator.wikimedia.org/T144338

Please follow the instructions in Contributing Bug Reports if you'd like to report a bug. Thanks!