WordPress.org

Make WordPress Core

Opened 8 years ago

Closed 7 years ago

#5196 closed enhancement (fixed)

Support "minor edits" in Atom

Reported by: rubys Owned by: westi
Milestone: 2.7 Priority: normal
Severity: normal Version:
Component: General Keywords: has-patch
Focuses: Cc:

Description

When editing a page on the codex.wordpress.org wiki, one can mark an edit as "This is a minor edit" via a checkbox on the page.

I'd like to see a similar feature on the wp-admin/post.php?action=edit page. All that is needed is for the database to maintain the date when the post was last significantly edited, and this information can be put in the updated element in the atom:entry. The initial creation is significant, and any subsequent edits that do NOT check this box are also considered significant, edits which do check this box are not.

I am willing to help develop and test this feature, and would like to request that it go into WordPress 2.4.

Attachments (3)

minoredit.png (5.3 KB) - added by CiaranG 7 years ago.
Screenshot of proposed (plugin?) UI
minor-edit.patch (1.2 KB) - added by rubys 7 years ago.
Ciaran's change, in patch form with an added if-check
minoredithooks.patch (1.1 KB) - added by CiaranG 7 years ago.
Patch that adds two hooks to facilitate a "minor edits" plugin

Download all attachments as: .zip

Change History (37)

comment:1 @rubys8 years ago

  • Type changed from defect to enhancement

comment:2 @rubys8 years ago

  • Cc rubys added

comment:4 @westi8 years ago

+1

This is a really good idea.

Ideally the minorness should be filterable so plugins can auto decide it too.

comment:5 @markjaquith8 years ago

+1 Look to MediaWiki for a UI implementation

comment:6 follow-ups: @foolswisdom8 years ago

-2

Sp/k to Matt about this last week. We both agree that it would by interested to understand what infrastructure is needed to accomplish this, and to have it possible by the AtomPub protocol.

The negative vote comes to having a field in the WordPress dashboard experience. How do you define minor? How does your audience? This seems like an experience to evolve on the consumption side based on the audiences definition not the publishers.

comment:7 in reply to: ↑ 6 @markjaquith8 years ago

Replying to foolswisdom:

The negative vote comes to having a field in the WordPress dashboard experience. How do you define minor? How does your audience? This seems like an experience to evolve on the consumption side based on the audiences definition not the publishers.

To be clear, the content would be updated -- this just affects the timestamp for the "updated" element. It was also suggested that this would be a good use of inline documentation to help people understand what is minor (grammar, spelling, typos) and what is not (additions, deletions, alterations that change meaning).

Clients are free to implement content comparison to communicate changes to readers. NetNewsWire Pro does this.

comment:8 @foolswisdom8 years ago

Bottom line for me is I unfortunately see it as generally an over engineered experience, and unnecessary cognitive burden. Great plugin material.

comment:9 in reply to: ↑ 6 @rubys8 years ago

Replying to foolswisdom:

-2

Sp/k to Matt about this last week. We both agree that it would by interested to understand what infrastructure is needed to accomplish this, and to have it possible by the AtomPub protocol.

AtomPub makes use of the same atom:updated element for this purpose.

The negative vote comes to having a field in the WordPress dashboard experience. How do you define minor? How does your audience? This seems like an experience to evolve on the consumption side based on the audiences definition not the publishers.

The definition of minor can certainly vary by the author, and as already indicated, the consumer is always free to treat this as only a hint. In any case, I can replace an entire paragraph, and deem the change minor, or change as little as one character and assert that the latter is significant. All that is being asked for here is a checkbox (with associated help) and an if check.

comment:11 @ffemtcj7 years ago

  • Milestone changed from 2.5 to 2.7

No Patch. Moved to 2.7

comment:12 @CiaranG7 years ago

  • Cc CiaranG added

comment:13 @CiaranG7 years ago

I also want the "over-engineered experience" to prevent minor corrections from annoying feed subscribers. It seems like a plugin is the best way to go to achieve this.

See the attached screenshot for how I propose it should look. Note that to achieve this I had to hack a new hook into my source immediately before the Save button is generated in edit-form-advanced.php, which would be the only way of achieving a clean UI. How easy is it to get this hook into the main codebase?

@CiaranG7 years ago

Screenshot of proposed (plugin?) UI

comment:14 @CiaranG7 years ago

In the meantime, if anyone wants a quick fix I've done a nasty hack to my installation, with instructions here: http://blog.ciarang.com/posts/wordpress-minor-edits-hack/

@rubys7 years ago

Ciaran's change, in patch form with an added if-check

comment:15 @rubys7 years ago

  • Keywords has-patch added

I've attached Ciaran's change in patch format, with an additional change: the checkbox will only be shown if the post has been published.

comment:16 @josephscott7 years ago

+1

In additional clients should be able to this at the API level. I'll look at adding a minor_edit flag to metaWeblog.editPost.

comment:17 @ruckus7 years ago

  • Cc ruckus added

comment:18 @westi7 years ago

  • Owner changed from anonymous to westi
  • Status changed from new to assigned

comment:19 @westi7 years ago

Patch looks good.

comment:20 @lloydbudd7 years ago

(aka foolswisdom) I still don't think it benefits enough people enough. It seems fit to start life as a plug in. Do we need an action, filter or other infrastructure to make this possible?

It also seems like a support burden:
p1: "I hate your blog because you correct typos all day long and my news reader keeps marking your old posts as unread."
p2: "I'm using WordPress's minor edit feature. It must be broken."
g3: "Your news reader is just weak - pawn it!"

Also, there is an opportunity to be better advocates for the change you want to see, so lay persons like myself can more easily buy into the idea. Am I correct in understanding that this only benefits if using Atom feed? -- more support headache.

comment:21 @CiaranG7 years ago

I'm attaching another patch that adds two hooks - an action and a filter. These facilitate a plugin that does the same as the patch Sam Ruby submitted previously.

A plugin that works with these hooks can be found at http://ciarang.com/wp-minor-edit/wp-minor-edit-0.1.zip

The end result of applying this patch and activating the plugin should be exactly the same as applying the original patch. Applying the patch without activating the plugin should have no noticeable effect, but someone with more experience of the Wordpress code should definitely sanity-check that assertion!

@CiaranG7 years ago

Patch that adds two hooks to facilitate a "minor edits" plugin

comment:22 @rubys7 years ago

Lloyd:

The hypothetical discussion you are describing is not a future thing, it happens all the time -- not in some far distant future when some response to idea 272 finally lands in WP, but today. The ending in today's discussions, however are far different. They end with the person who simply wants to host a planet site shaking their head in dismay and muttering "what do you mean that WP doesn't provide a means a means to indicate a minor edit?", and then adding an "ignore_in_feed: updated" option on every WordPress blog, effectively making life more difficult for people who wish to make a significant update.

I'm not certain what advocacy you are talking about. My read is that the person who opened the idea a year ago didn't have any agenda they were attempting to further, other than simply wanting to make WordPress more useful for themselves and their readers.

It is true that RSS 2.0 doesn't have a built in element for precisely this purpose. That's what extensions are for. One can even put Atom elements inside RSS 2.0 feeds, and there is an Atom element designed exactly for this purpose. Note: the atom:updated element is just one possible element that could be used for this purpose. There may be others. And, in fact, WordPress could define one, in a wordpress.org namespace.

It is also true that not every feed reader has full and complete support for every feature defined in every feed format. This was true before idea 272 was published, and will continue to be true after ticket 5196 is resolved.

The question as to whether this should be implemented as a plugin or not is less interesting to me than the question as to whether or not this function will be deployed on wordpress.org. As I said, the discussions are not hypothetical, they are happening today. In fact, the were obviously happening a year ago, when the idea was published. I dare say that they predate the publishing of that idea. The resolution today is that WordPress does not provide a means to indicate that the edits were minor. The resolution is not that WordPress could not do so, or that some feed readers may make different choices, but that there is no choice to be made as WordPress does not provide a means to capture and convey the information.

comment:23 follow-up: @westi7 years ago

My personal feeling is this would be a nice feature.

For now I will add some hooks that make the plugin easy to do and make other plugins possible.

The current patch is too specific to this issue in the way the hooks are implemented.

Please try re-implementing your plugin based on the hooks I am about to commit and let us know if you have any issues.

comment:24 @westi7 years ago

(In [8635]) Give plugins the ability to do extra processing on a post before it is inserted/updated. See #5196.

comment:25 follow-up: @Viper007Bond7 years ago

The attached screenshot may be confusing to many people, especially the very novice users.

Keeping this as a plugin would be fine by me, but if this makes it into the core, then perhaps having it as an option in Settings -> Writing might be a good idea (to turn it on).

comment:26 in reply to: ↑ 23 @CiaranG7 years ago

Replying to westi:

Please try re-implementing your plugin based on the hooks I am about to commit and let us know if you have any issues.

Done.

The wp_insert_hook is much cleaner and more flexible, but for the edit form hook can we pass $post as a parameter as in my patch? The plugin needs this info to be able to determine the context - specifically in this case it needs to know when the post is not published in order to leave out the checkbox.

comment:27 follow-up: @Viper007Bond7 years ago

Can't you just global $post; or whatever variable the post lives in on the edit form?

comment:28 in reply to: ↑ 27 @CiaranG7 years ago

Replying to Viper007Bond:

Can't you just global $post; or whatever variable the post lives in on the edit form?

Yes. So here's an updated plugin that works against trunk as of [8635] - http://ciarang.com/wp-minor-edit/wp-minor-edit-0.2.zip

comment:29 in reply to: ↑ 25 @rubys7 years ago

Replying to Viper007Bond:

perhaps having it as an option in Settings -> Writing might be a good idea (to turn it on).

Sounds reasonable to me.

comment:30 @ryan7 years ago

(In [8702]) Rename wp_insert_post filter to wp_insert_post_data to avoid collision. see #5196

comment:31 @lloydbudd7 years ago

It looks like this issue can be closed as fixed -- infrastructure included for a plugin to be able to achieve this. Am I overlooking anything?

comment:32 @CiaranG7 years ago

Closing as fixed sounds good to me. The plugin is ready to roll out when these changes make it into a release version.

comment:33 @CiaranG7 years ago

By the way, plugin that works with latest filter name change ([8702]) is here: http://ciarang.com/wp-minor-edit/wp-minor-edit-0.3.zip

comment:34 @CiaranG7 years ago

  • Resolution set to fixed
  • Status changed from assigned to closed
Note: See TracTickets for help on using tickets.