Recent Updates Page 2 Toggle Comment Threads | Keyboard Shortcuts

  • Aaron Jorbin 6:03 pm on September 30, 2012 Permalink | Reply  

    I added a simple build file to minify the CSS and JS. There are two dependencies that will get announced if you try and run the script without it. Right now, the script only works if run from inside the root folder of the project.

    @benbalter – Can you update your release script to remove this build script from what is pushed to WordPress.org ?

     
  • Ben Balter 11:01 am on September 25, 2012 Permalink | Reply
    Tags: final countdown,   

    It’s the final countdown.

    two outstanding issues:

    Pending wrapping up the above, would love to see this get pushed public Thursday, if not, Monday at the latest.

    If you can take a few minutes to spin up and install and click around a bit, even opening issues would be helpful at this point.

     
  • Daniel Bachhuber 12:22 pm on September 21, 2012 Permalink | Reply  

    @benbalter can you add @mjangda to the Github repo so he can check out the code?

     
  • Ben Balter 2:05 pm on September 15, 2012 Permalink | Reply
    Tags:   

    Did a big round of cleaning up, including a whole bunch of unit tests (and associated fixes as a result).

    Outstanding tickets:

    • permission tweaks (on it)
    • Possibly a bug on merge, but I think it’s resolved
    • Publish metabox refresh
    • Documentation final pass

    With the above knocked out, I think we’d have a solid 0.1 and would feel comfortably flipping the switch and making things public. Thoughts?

     
    • Daniel Bachhuber 2:43 pm on September 15, 2012 Permalink | Reply

      Sounds great!

    • Benjamin J. Balter 2:45 pm on September 15, 2012 Permalink | Reply

      Update: Documentation should be close to good to go.

    • Daniel Bachhuber 12:22 pm on September 21, 2012 Permalink | Reply

      Want me to crank out the publish metabox this weekend?

      • Benjamin J. Balter 9:24 am on September 22, 2012 Permalink | Reply

        That’d be awesome. Given your expertise with Edit Flow, I think you might know the code better (and seem to have a crisp vision for where it should be). Let me know how I can help.

        I was going to try to crank out the last few remaining permission issues this weekend, and and was hoping that we could shoot for at least a soft launch on GitHub early next week so we can get some more folks involved, or if the codes there, just go ahead and push to the .org repo.

      • Benjamin J. Balter 10:51 am on September 25, 2012 Permalink | Reply

        Any chance you had a chance to take a stab at metabox? (think I saw there was a wordcamp). If not, no worries, just trying to figure out how soon we can get this out the door.

  • Ben Balter 1:11 pm on September 9, 2012 Permalink | Reply
    Tags: .org   

    FYI, requested a repo on .org so we can get it in the plugin directory when we’re ready

     
  • Ben Balter 3:04 pm on September 7, 2012 Permalink | Reply
    Tags:   

    In terms of an MVP, it’s probably just documentation and clicking through / debugging. (re: documentation, if we do it in the WIki [ e.g., https://github.com/benbalter/wp-document-revisions/wiki ], I have a script to merge it down into readme.txt and readme.md )
     
    In terms of stuff on my list, I’d love to get at least a few unit tests in there, at least to get it set up with Travis CI (https://github.com/benbalter/wordpress-plugin-tests/), and was toying with the idea of integrating with Scribu’s front-end editing or similar. The APIs already there, and the permissions should work, it’s just a matter of building out the front end.
     
    Last, I think it should be a small lift, but the other feature on my list would be to either spoof or copy over the parent’s revision history on fork (so it’s like a true fork w/ the full history).
     
    Beyond that, I think you might know this space better than I do. You’ve seen the code… what sucks? What’s missing? What feature can we kill off?
     
    • Benjamin J. Balter 3:06 pm on September 7, 2012 Permalink | Reply

    • Daniel Bachhuber 4:34 pm on September 7, 2012 Permalink | Reply

      The killer feature is the button you can add on the frontend where users can “fork” a piece of content, make changes, and submit those changes for review. Ideally, users shouldn’t have to be logged in or need to access the backend for this to happen.

      If the backend workflow features are useful enough though, maybe the frontend stuff can come later and, after it, a big announcement.

      • Benjamin J. Balter 4:44 pm on September 7, 2012 Permalink | Reply

        That’s the vision. I’d love for it to be like P2 where most folks never even know the back end exists.

        I see two distinct use cases that we have to build for:

        1) Collaborative editing. I’m on the backend, i’m comfortable there, but the standard revision system isn’t enough for my organization’s needs.

        2) user-submitted edits. I’m a newspaper and I want people to be able to submit corrections, which I approve and go live.

        #1’s most of the way there. #2 is plumbed in. There should already be an API exposed to allow everything to happen from the front end. I played around with Scribu’s front-end-editing a bit, but nothing substantive.

        The one issue I’d love to figure out (as I imagine in #2 the publisher wouldn’t want the public in their users table), how to allow (pseudo)anonymous forks. We’d need some sort of persistence (this guy has submitted 3 things before) perhaps along the line of comment authors, but I think they’d need to be users (or at least *a* user) so the fork can have an author. Thoughts?

  • Daniel Bachhuber 1:44 pm on September 7, 2012 Permalink | Reply
    Tags:   

    After temporarily disabling custom capabilities, I’ve created my first fork! Doing so raises a few questions though:

    • What is the plugin supposed to be doing? What problem does it solve?
    • Do I publish a fork? If not, how do I merge it back into the original?
    • Should forks be a public post type if they aren’t intended to be published?

    Based on my prior opinions, forks shouldn’t be a public post type by default. The point of “creating” a fork is to be able to make edits to another post type, and then be able to “submit a pull request” to have your changes merged back into the original. This is what v0.1 should be.

    Thoughts?

     
    • Benjamin J. Balter 2:53 pm on September 7, 2012 Permalink | Reply

      I had two potentially conflicting design philosophies when I was sketching things out.

      1. Mirror GitHub as much as possible — it’s a well thought out workflow that most folks understand
      2. Use native WordPress functionality as much as possible — it’s a well thought out workflow that most folks understand

      Publicness: I remember going back and forth on whether forks should be public, and the only reason I fell on the public side was because if I fork a GH repo, my work on it, is by default, public. I don’t know how that would play out on the front end in a WordPress context, but that was the logic. Could go either way though. There’s something to be said for the possibility of a public revision history down the line, or ability to see pending “pull requests”, etc.

      Publishing: Theoretically, if I don’t have the `publish_post` cap, the publish button should be the standard submit for moderation. If I do have the `publish_post` cap, or am reviewing something from the moderation queue, I should have the normal publish button. The plugin should be intercepting the publish action and merging the fork into the parent post or presenting the conflict for resolution. I think this makes sense from a UX standpoint as you’re “publishing” the changes. Think of this less of a standalone CPT and more of fork of the parent post. Once published, nobody should have `edit_published_fork` caps, as they serve simply as a history, e.g., see this users forks (unless it makes sense to use the parent’s revision (the merge) and use metadata or some magic to query). The use case here was more for news-ish sites to allow readers to submit corrections, and have a running log of their contributions. If the forks are public, we just use author pages and don’t have to code anything. May make sense to back-burner this, or make it a filter for users that want the feature. Was in the original spec.

      Purpose: Originally, http://ben.balter.com/2012/02/28/github-for-journalism-what-wordpress-post-forking-could-do-to-editorial-workflows/

      • Collaborative editing (by resolving two users’ conflicted saves – Wired’s example)
      • Saving draft changes of already-published content
      • Scheduling pending changes to already-published content
      • Allowing users without edit or publish capabilities to edit and submit changes to content (similar to GitHub’s pull request system)

      I’m not strongly opinionated on the public/private thing. If you think the contribution archive makes sense as a feature and that’s the way to do it (thinking author archive for a CPT), great, if not (or if there’s a better way to do it), let’s flip it.

    • Daniel Bachhuber 4:32 pm on September 7, 2012 Permalink | Reply

      I remember going back and forth on whether forks should be public, and the only reason I fell on the public side was because if I fork a GH repo, my work on it, is by default, public.

      If it’s a private repo though, the fork remains private. In the publishing world, most work remains private until it goes public. I think that should be the default option with the ability to enable public forks if you need.

      If I do have the `publish_post` cap, or am reviewing something from the moderation queue, I should have the normal publish button. The plugin should be intercepting the publish action and merging the fork into the parent post or presenting the conflict for resolution. I think this makes sense from a UX standpoint as you’re “publishing” the changes.

      This is not intuitive in my opinion. Instead, something like “Merge” would be more descriptive. Similarly, most of the other options in the post submit box could be removed.

      If you think the contribution archive makes sense as a feature and that’s the way to do it (thinking author archive for a CPT), great, if not (or if there’s a better way to do it), let’s flip it.

      Maybe this should be v0.2. It’s not terribly obvious as it is, but there certainly is great potential in allowing for public forks, showing version history and forking contributions, etc.

      • Benjamin J. Balter 4:38 pm on September 7, 2012 Permalink | Reply

        In the publishing world, most work remains private until it goes public.

        Totally agree. Just trying to think through the flow. That should be the case with public forks, no? If it’s not published (draft, private), it’s not public. If it’s published (meaning it’s already merged into live post), it’s public, no?

        Similarly, most of the other options in the post submit box could be removed.

        May make sense to (either now or down the line) remove the standard publish metabox and add our own simpler one? Was just trying to keep the UX as fluid as possible between forks and posts.

        Maybe this should be v0.2…. there certainly is great potential in allowing for public forks, showing version history and forking contributions, etc.

        #worksforme

        • Greg Linch 12:59 am on October 14, 2012 Permalink

          A potential bug with merging a forked draft back into a draft:

          I did: I forked a draft post and merged it back
          I saw: It published
          I expected: It to only merge — not publish

          Sorry if I missed this elsewhere (I’ve been following all the GitHub threads!), but will this be fixed going forward?

          I can imagine many use cases where this would be very problematic if not. If it stays as is, the admin language should be changed to “merge and publish” for drafts and “merge and republish” for previously published posts.

        • Daniel Bachhuber 1:07 am on October 14, 2012 Permalink

          That’s a bug. Merging into a draft shouldn’t cause it to publish. File a Github issue and I’ll take a look?

        • Greg Linch 10:27 am on October 14, 2012 Permalink

c
Compose new post
j
Next post/Next comment
k
Previous post/Previous comment
r
Reply
e
Edit
o
Show/Hide comments
t
Go to top
l
Go to login
h
Show/Hide help
shift + esc
Cancel