Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merge Semantic Linkbacks into this plugin #112

Closed
dshanske opened this issue Jan 25, 2017 · 13 comments
Closed

Merge Semantic Linkbacks into this plugin #112

dshanske opened this issue Jan 25, 2017 · 13 comments

Comments

@dshanske
Copy link
Collaborator

I know there is a reason it was separated, but I want to discuss if that should be revisited.

@dshanske
Copy link
Collaborator Author

dshanske@c23c434 - The original noted reason for removal of microformats support was the specification.

The specification now notes that "When a Webmention implementation does support updating (i.e., a "Webmention update implementation"), it MUST support updating data from properties of the primary object of the source. (e.g. properties of the [h-entry] of the page)." This would be an endorsement of microformats within the plugin to a greater degree than now.

The biggest issue is that the php-mf2 parser has a PHP 5.3 dependency. But the plugin could be set to degrade in the event that this occurred. The individual files could be loaded separated.

I cannot see a scenario where someone would want webmentions and not at least some of Semantic Linkbacks.

@dshanske
Copy link
Collaborator Author

As this is a controversial issue, I am expressing a hope for an eventual reunification but accepting that a lot of things that might not be possible at this time would have to be addressed for this to be a reality. I suggest we keep this issue open as a discussion point.

@dshanske
Copy link
Collaborator Author

The first question is if separate comment types should be used for like, etc. The comment comment type is the equivalent of reply.

@tantek
Copy link

tantek commented Dec 31, 2017

TBH I think this is one of the most important improvements to make for the Webmentions plugin. This is key to how Webmentions (as a protocol, web standard, and ecosystem) are so much better designed and implemented than Pingbacks/Trackbacks etc. that the WordPress plugin by the same name should really reflect the full promise of what Webmentions do in practice on the indieweb, and more importantly what a typical user of Webmentions expects that they will do (provide actual rich reactions like comments, likes, etc. not just junky pingback links)

@gRegorLove
Copy link

Some reasons I think they should be merged:

  • Easier setup, fewer steps. "Install this one plugin, then..."
  • Nice presentation of webmentions should be a core part of the plugin. Installing the plugin should give the functionality and improved look of comments (vs pingbacks/trackbacks)
  • In Better Spam and Moderation Handling #87 (comment) I realized that some of the data I'm suggesting working with (canonical URL) is provided by Semantic Linkbacks, so would require both plugins. I think canonical URL should be part of the webmention comment meta.
  • I don't have a citation handy, but I've seen incidents in #indieweb chat and IndieWebCamps over the years where people are confused by there being two plugins, sometimes installing just Webmention
  • The name "Semantic Linkbacks" is jargony, doesn't tell you what it does

@dshanske
Copy link
Collaborator Author

@pfefferle and I discussed finally addressing this issue. This will require a new data structure as a first step and a migration function. The brainstorming for this is on the wiki at https://indieweb.org/WordPress/Data

@snarfed
Copy link
Contributor

snarfed commented Jun 26, 2019

friendly nudge. could be a good project for summit!

@pfefferle
Copy link
Owner

I do not think it is that easy, because I would recommend to rewrite the SL code! The actual version feels really hacky!

@dshanske
Copy link
Collaborator Author

dshanske commented Aug 2, 2019

@pfefferle Is it better to merge the code and then rewrite, or only incorporate the new non hacky version?

@pfefferle
Copy link
Owner

I would prefer to not merge the code as is, because otherwise it is harder to rewrite it, without the limitations of the old structure...

@dshanske
Copy link
Collaborator Author

dshanske commented Aug 7, 2019

I will continue with pulling in pieces of infrastructure.

@snarfed
Copy link
Contributor

snarfed commented Nov 29, 2022

Still seeing confused users file bugs elsewhere due to the bad UX of having these two plugins separate, eg snarfed/bridgy#1355 (comment). Hope the merge refactoring work is coming along ok!

@dshanske
Copy link
Collaborator Author

dshanske commented Apr 7, 2023

Resolved via version 5.0.0

@dshanske dshanske closed this as completed Apr 7, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants