`/posts/{post-id}` NPF edit endpoint: Tipping status lost/undocumented

[marcustyphoon]

/posts/{post-id} - Editing a Post (Neue Post Format)

I noticed that some of our XKit Rewritten code unintentionally turns tipping on or off when editing a post (https://github.com/AprilSylph/XKit-Rewritten/issues/838); I thus did some research.

We are doing a put request to /posts/{post-id} (via the in-browser window.tumblr.apiFetch), with these parameters set: content, layout, state, publish_on, date, tags, source_url

We are not, at the moment, setting these parameters:

• send_to_twitter
• interactability_reblog
• hide_trail

...or any of these undocumented parameters, which I grabbed from gutenblr:

• can_be_tipped
• has_community_label
• community_label_categories

That I can tell from testing, interactability_reblog, hide_trail, has_community_label, and community_label_categories keep their values when edited via this endpoint with no values set, so omitting them is fine. (I didn't test send_to_twitter.)

can_be_tipped, on the other hand, appears to revert to the blog default if a post is edited via this endpoint without including it as a parameter set to its previous value.

Therefore:

• can_be_tipped should probably either be a documented NPF compose/edit parameter, not get reset if a post is edited without the parameter, or both;

• If making them public is desired, the community label parameters should also be documented;

• It would be nice to have an explicit description in the docs of what the NPF edit endpoint is supposed to default to/which parameters should be optional;

• I would love to know how the tipping status is actually saved internally, considering that it can be toggled both per-post and as a per-blog default! Is there an "unset" state internally? Does toggling the blog default erase the per-post information? (I have reported a bug about how the iOS app always sets can_be_tipped: true and would like to create a tool to retroactively set tipping in a consistent way.)

[sanmai]

Thanks for calling this out! That is indeed a bug. We'll get this fixed up. 👌

[marcustyphoon]

Quoting myself to note the results of some testing:

You can set the default value of "can my posts be tipped" in your blog settings.

If you compose a post using the new post editor on the web, and do not change the tipping toggle from [whatever agrees with your current setting], that post's tipping status will change with the blog setting. I assume that this means, internally, that it's stored as null/undefined.

If you compose a post using the new post editor on the web, and change the tipping toggle to the opposite of your current setting, that post's tipping status will be permanently set to that setting. I assume that this means, internally, that it's stored as on or off.

If you edit a post using the Tumblr API (NPF api endpoint), and don't pass a can_be_tipped value, the post's tipping status will change with the blog setting. I assume that this means that the internal value is being set to null/undefined.

What makes this confusing/ambiguous, of course, is:

1. There appears to be no way to tell whether a post is explicitly set to agree with your current blog default tipping status or if it's internally unset.
2. There's no way in the API to specify if you don't want to make any changes to the tipping status or if you explicitly want to make it unset. I want to be able to do both!

[marcustyphoon]

Tipping was removed.