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

Retroactive posse #206

Closed
mapkyca opened this Issue Mar 29, 2014 · 24 comments

Comments

Projects
None yet
4 participants
@mapkyca
Collaborator

mapkyca commented Mar 29, 2014

Be able to posse already posted items in edit

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

@benwerd

This comment has been minimized.

Show comment
Hide comment
@benwerd

benwerd Mar 29, 2014

Member

A+

On Sat, Mar 29, 2014 at 12:05 PM, Marcus Povey notifications@github.comwrote:

Be able to posse already posted items in edit

Reply to this email directly or view it on GitHubhttps://github.com/idno/Known/issues/206
.

Ben Werdmuller
http://goog_1933028737
benwerd.com | werd.io

+1 (312) 488-9373

Member

benwerd commented Mar 29, 2014

A+

On Sat, Mar 29, 2014 at 12:05 PM, Marcus Povey notifications@github.comwrote:

Be able to posse already posted items in edit

Reply to this email directly or view it on GitHubhttps://github.com/idno/Known/issues/206
.

Ben Werdmuller
http://goog_1933028737
benwerd.com | werd.io

+1 (312) 488-9373

@mapkyca

This comment has been minimized.

Show comment
Hide comment
@mapkyca

mapkyca Apr 2, 2014

Collaborator

Ok, dug a little into this, and two things need to happen:

  1. we modify buttons to show when _id is present
  2. if ->posse contains $service we set disabled
  3. we trigger the post event again on save

However, all current POSSE plugins a) listen to only one event, and b) don't handle a case where a link has already been posted particularly gracefully.

In short, this may be a little bit more involved than my current bandwidth allows :)

Collaborator

mapkyca commented Apr 2, 2014

Ok, dug a little into this, and two things need to happen:

  1. we modify buttons to show when _id is present
  2. if ->posse contains $service we set disabled
  3. we trigger the post event again on save

However, all current POSSE plugins a) listen to only one event, and b) don't handle a case where a link has already been posted particularly gracefully.

In short, this may be a little bit more involved than my current bandwidth allows :)

@benwerd

This comment has been minimized.

Show comment
Hide comment
@benwerd

benwerd Jan 2, 2015

Member

Bumping. Retroactive POSSE and de-POSSE both.

Member

benwerd commented Jan 2, 2015

Bumping. Retroactive POSSE and de-POSSE both.

@mapkyca

This comment has been minimized.

Show comment
Hide comment
@mapkyca

mapkyca Aug 29, 2015

Collaborator

Bumping again, since it's been brought up in discussion more than once recently...

Collaborator

mapkyca commented Aug 29, 2015

Bumping again, since it's been brought up in discussion more than once recently...

@benwerd

This comment has been minimized.

Show comment
Hide comment
@benwerd

benwerd Aug 31, 2015

Member

Yeah. Would be super-cool. Haven't had time, and the UX is important, but it's massively necessary.

Member

benwerd commented Aug 31, 2015

Yeah. Would be super-cool. Haven't had time, and the UX is important, but it's massively necessary.

@mapkyca

This comment has been minimized.

Show comment
Hide comment
@mapkyca

mapkyca Dec 17, 2015

Collaborator

Bumping this again. Might try and implement it shortly...

Collaborator

mapkyca commented Dec 17, 2015

Bumping this again. Might try and implement it shortly...

@benwerd

This comment has been minimized.

Show comment
Hide comment
@benwerd

benwerd Dec 17, 2015

Member

Nice. I definitely have some thoughts on this. We do have some of the components to make this work.

Member

benwerd commented Dec 17, 2015

Nice. I definitely have some thoughts on this. We do have some of the components to make this work.

@kylewm

This comment has been minimized.

Show comment
Hide comment
@kylewm

kylewm Jan 13, 2016

Collaborator

I'm thinking through the UX a little, and it's definitely tricky. In Red Wind, it's always worked like: you edit a post, toggle the targets you want to syndicate to, and click save to POSSE to them. Clicking "Edit" in order to syndicate has always felt a little off to me; like clicking "Start" to shutdown the system.

I played around a little with an alternative; a screen specifically for syndicating. You click the "Syndicate" link

syndicate-link

to bring up the syndication page which just has the item rendered and the syndication toggles at the bottom

syndicate-form

I dunno, it's functional but definitely feels janky in its own way.

And oh man de-POSSEing would be amazing (I see you feature creeping!), and definitely complicates things. Accidentally deleting a POSSE copy could be a disaster (I'm imagining like deleting a Medium post and losing a permalink that's been shared around). That doesn't really feel like something you should be able to do from the edit screen (?)

Collaborator

kylewm commented Jan 13, 2016

I'm thinking through the UX a little, and it's definitely tricky. In Red Wind, it's always worked like: you edit a post, toggle the targets you want to syndicate to, and click save to POSSE to them. Clicking "Edit" in order to syndicate has always felt a little off to me; like clicking "Start" to shutdown the system.

I played around a little with an alternative; a screen specifically for syndicating. You click the "Syndicate" link

syndicate-link

to bring up the syndication page which just has the item rendered and the syndication toggles at the bottom

syndicate-form

I dunno, it's functional but definitely feels janky in its own way.

And oh man de-POSSEing would be amazing (I see you feature creeping!), and definitely complicates things. Accidentally deleting a POSSE copy could be a disaster (I'm imagining like deleting a Medium post and losing a permalink that's been shared around). That doesn't really feel like something you should be able to do from the edit screen (?)

@benwerd

This comment has been minimized.

Show comment
Hide comment
@benwerd

benwerd Jan 13, 2016

Member

I'd say if you can remove the POSSE from the edit screen, it hits you with a bunch of confirmation errors. Not something you can accidentally click. Having the mechanism to remove POSSE also allows you to do things like effective snapchat: post a status update on Twitter for 30 seconds and then pull it, automatically. Suddenly content only needs to show up on a social network for as long as you want it to.

Member

benwerd commented Jan 13, 2016

I'd say if you can remove the POSSE from the edit screen, it hits you with a bunch of confirmation errors. Not something you can accidentally click. Having the mechanism to remove POSSE also allows you to do things like effective snapchat: post a status update on Twitter for 30 seconds and then pull it, automatically. Suddenly content only needs to show up on a social network for as long as you want it to.

@kylewm

This comment has been minimized.

Show comment
Hide comment
@kylewm

kylewm Jan 15, 2016

Collaborator
  1. if ->posse contains $service we set disabled

There's a bit of an impedence mismatch now that each service has account as part of its identifier too

The syndication target is twitter::kylewm2 and the posse field looks like ["twitter" => [ "identifier" => "@kylewm2"]]. I don't think there's a general way to convert from one to the other yet.

Collaborator

kylewm commented Jan 15, 2016

  1. if ->posse contains $service we set disabled

There's a bit of an impedence mismatch now that each service has account as part of its identifier too

The syndication target is twitter::kylewm2 and the posse field looks like ["twitter" => [ "identifier" => "@kylewm2"]]. I don't think there's a general way to convert from one to the other yet.

@matzoman

This comment has been minimized.

Show comment
Hide comment
@matzoman

matzoman Jan 26, 2016

Contributor

I'm working on this issue.
Right now I'm not sure how I can disable a button in edit mode when the entry is already POSSE'd to the service.

getPosseLinks() and getServiceAccounts($service) do not match, right?

Contributor

matzoman commented Jan 26, 2016

I'm working on this issue.
Right now I'm not sure how I can disable a button in edit mode when the entry is already POSSE'd to the service.

getPosseLinks() and getServiceAccounts($service) do not match, right?

@kylewm

This comment has been minimized.

Show comment
Hide comment
@kylewm

kylewm Jan 26, 2016

Collaborator

@matzoman yes, that's exactly where I got stuck too. I think what I'd do is add a field to PosseLinks called "account" so you'd have like

{
    "twitter": { 
        "url": "https://twitter.com/someuser/1234", 
        "identifier": "@someuser",
        "account": "someuser",
    },
    "facebook": { 
        "url": "https://facebook.com/someuser/1234", 
        "identifier": "Some User",
        "account": "10008899828928",
    }
}

And that way you could construct the service::account. It would only work for POSSEd posts going forward but I think that's the best we can do.

Collaborator

kylewm commented Jan 26, 2016

@matzoman yes, that's exactly where I got stuck too. I think what I'd do is add a field to PosseLinks called "account" so you'd have like

{
    "twitter": { 
        "url": "https://twitter.com/someuser/1234", 
        "identifier": "@someuser",
        "account": "someuser",
    },
    "facebook": { 
        "url": "https://facebook.com/someuser/1234", 
        "identifier": "Some User",
        "account": "10008899828928",
    }
}

And that way you could construct the service::account. It would only work for POSSEd posts going forward but I think that's the best we can do.

benwerd added a commit that referenced this issue Jan 26, 2016

@benwerd

This comment has been minimized.

Show comment
Hide comment
@benwerd

benwerd Jan 26, 2016

Member

Seconded ;)

Member

benwerd commented Jan 26, 2016

Seconded ;)

@benwerd

This comment has been minimized.

Show comment
Hide comment
@benwerd

benwerd Jan 26, 2016

Member

I've updated the Twitter plugin but will need to update Facebook etc later.

Member

benwerd commented Jan 26, 2016

I've updated the Twitter plugin but will need to update Facebook etc later.

@matzoman

This comment has been minimized.

Show comment
Hide comment
@matzoman

matzoman Jan 26, 2016

Contributor

S.th. Else i noticed: the save function is calling the syndicate function, better seperate because the syndicate trigger event of the Twitter plugin for example are calling save again. --> possible endless loop

(I hope this makes sense)

Contributor

matzoman commented Jan 26, 2016

S.th. Else i noticed: the save function is calling the syndicate function, better seperate because the syndicate trigger event of the Twitter plugin for example are calling save again. --> possible endless loop

(I hope this makes sense)

@matzoman

This comment has been minimized.

Show comment
Hide comment
@matzoman

matzoman Jan 26, 2016

Contributor

moving 'syndicate' outside of 'save' means changing every plugin --> not the best solution, but more clean code?

Contributor

matzoman commented Jan 26, 2016

moving 'syndicate' outside of 'save' means changing every plugin --> not the best solution, but more clean code?

@kylewm

This comment has been minimized.

Show comment
Hide comment
@kylewm

kylewm Jan 26, 2016

Collaborator

syndicate trigger event of the Twitter plugin for example are calling save again. --> possible endless loop

I absolutely agree, and I'm pretty sure I heard Ben mention this too. Too many events are triggered by simply saving an Entity (which happens all the time, e.g. whenever someone comments).

I think we should add a function Entity::publish that would only be called when the user actually clicks "Publish". publish would call Entity::save and then:

  1. (Optionally) Add it to the feed
  2. Call syndicate

This would be useful for saving Drafts in the future too; i.e. we could save without publishing them.

Collaborator

kylewm commented Jan 26, 2016

syndicate trigger event of the Twitter plugin for example are calling save again. --> possible endless loop

I absolutely agree, and I'm pretty sure I heard Ben mention this too. Too many events are triggered by simply saving an Entity (which happens all the time, e.g. whenever someone comments).

I think we should add a function Entity::publish that would only be called when the user actually clicks "Publish". publish would call Entity::save and then:

  1. (Optionally) Add it to the feed
  2. Call syndicate

This would be useful for saving Drafts in the future too; i.e. we could save without publishing them.

@kylewm

This comment has been minimized.

Show comment
Hide comment
@kylewm

kylewm Jan 26, 2016

Collaborator

moving 'syndicate' outside of 'save' means changing every plugin --> not the best solution, but more clean code?

I vote yes, especially if you can do it in a way that outdated plugins degrade gracefully.

Collaborator

kylewm commented Jan 26, 2016

moving 'syndicate' outside of 'save' means changing every plugin --> not the best solution, but more clean code?

I vote yes, especially if you can do it in a way that outdated plugins degrade gracefully.

@benwerd

This comment has been minimized.

Show comment
Hide comment
@benwerd

benwerd Jan 27, 2016

Member

I strongly agree with adding Entity::publish and modifying every plugin.

Member

benwerd commented Jan 27, 2016

I strongly agree with adding Entity::publish and modifying every plugin.

@matzoman

This comment has been minimized.

Show comment
Hide comment
@matzoman

matzoman Jan 28, 2016

Contributor

Today I worked on adding Entity::publish and modifying the plugins. ("photo" worked: yay!)
The next step would be to disable the buttons when the entry was already POSSE'd. maybe tomorrow.
(my branch: Retroactive-posse)

Contributor

matzoman commented Jan 28, 2016

Today I worked on adding Entity::publish and modifying the plugins. ("photo" worked: yay!)
The next step would be to disable the buttons when the entry was already POSSE'd. maybe tomorrow.
(my branch: Retroactive-posse)

@benwerd

This comment has been minimized.

Show comment
Hide comment
@benwerd

benwerd Jan 29, 2016

Member

@matzoman this sounds completely awesome!

Member

benwerd commented Jan 29, 2016

@matzoman this sounds completely awesome!

@matzoman

This comment has been minimized.

Show comment
Hide comment
@matzoman

matzoman Jan 29, 2016

Contributor

@benwerd just a heads up: Twitter Pull Request small fix for your changes in the twitter plugin.

about this issue: I made progress, pull request follows maybe on monday.

Contributor

matzoman commented Jan 29, 2016

@benwerd just a heads up: Twitter Pull Request small fix for your changes in the twitter plugin.

about this issue: I made progress, pull request follows maybe on monday.

@kylewm

This comment has been minimized.

Show comment
Hide comment
@kylewm

kylewm Feb 8, 2016

Collaborator

Thanks again @matzoman!

Collaborator

kylewm commented Feb 8, 2016

Thanks again @matzoman!

@kylewm kylewm closed this Feb 8, 2016

@benwerd

This comment has been minimized.

Show comment
Hide comment
@benwerd

benwerd Feb 8, 2016

Member

Incredibly cool!

Member

benwerd commented Feb 8, 2016

Incredibly cool!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment