Hey Automattic, What’s Going on With Edit Flow?

Edit Flow is an editorial workflow plugin for WordPress created in 2009 that is actively installed on more than 10K sites. Although the author listing on the plugin’s page shows Mohammad Jangda, Daniel Bachhuber, and Scott Bressler as authors, it’s currently maintained by Automattic.

Bachhuber announced in 2013 that Automattic claimed ownership of all the plugins he worked on during his employment, including Edit Flow. The WordPress.com VIP team took over development and in some cases, uses it on client sites.

If you visit the plugin’s page today, you’ll see the following notice:

This plugin hasn’t been updated in over 2 years. It may no longer be maintained or supported and may have compatibility issues when used with more recent versions of WordPress.

According to the changelog and the Edit Flow news blog, the plugin hasn’t been updated since January 2014, when 0.8 was released. For more than a year, concerned users have created threads in the support forum questioning if the project has been abandoned.

A user who goes by the name drtarnaizoltan who has used Edit Flow for more than two years even suggested a crowdfunding campaign to continue development.

We have an online magazine, and started to use this plugin almost 2 years ago. We don’t want to switch another, cause everyone in the editorial likes this one. I think we are not alone in this situation. I suggest to make a fundraising for continuation the develop of this plugin. We are able make a kickstarter page or something like that to reach our goal. What is your opinion about?

The most recent commit to the project’s GitHub page is from Bachhuber six months ago. All of the communication channels used by Edit Flow developers to inform users are dormant. It’s ironic that a company that relies on so many tools to communicate internally has failed to communicate with users of its plugin. This is a classic example where a little communication about the project’s status would go a long way.

Edit Flow is an important plugin that we use on the Tavern and as a user, I understand the frustration of not knowing what’s going on. The lack of updates, and inability to fix a critical bug I reported a year ago that conflicts with WordPress mobile apps is forcing us to consider alternatives.

I reached out to Automattic to find out whether or not Edit Flow is still an active project. Mark Armstrong, who represents Automattic provided the Tavern with the following statement:

Edit Flow is a plugin we maintain, and a number of WordPress.com VIP clients use it. We have no other updates in the works at this time.

While his statement verifies that it’s an active project, all signs point to it being an abandoned plugin for those not part of the WordPress.com VIP program.

Have you ditched Edit Flow? Let us know what alternatives you’ve discovered and or use.


45 responses to “Hey Automattic, What’s Going on With Edit Flow?”

  1. I don’t use the plugin, however I know that many people rely on it. I think it’s quite funny that Automattic, a company who postulates updating stuff, is not abel to update a famous plugin. They could even manage to update 1 line in their readme.txt: “Compatible up to: 3.8.13”

    A kickstarter campaign is interesting. But I don’t think Automattic is missing money rather than motivation. Another alternative could be to fork the plugin. Maybe a more active group of developers are keen enough to take it over :)

    • ‘Tis indeed a pot calls the kettle black moment. We’ve just spent/wasted five hours of a junior developer’s time to test and update all our plugin notices for 4.5. It was a better workflow for us to concentrate our efforts on quickly fixing the occasional breakage than spending hours three times/year going through what is basically a bureaucratic procedure. It seems Automattic feels the same way.

      Automattic really should give Mr Bachhuber back Edit Flow (if not the other plugins) if they are not prepared to develop them further.

      Thanks Jeff for your efforts to get Edit Flow back in the groove.

      • Mr Bachhuber, Mohammad Jangda, and Scott Bressler are currently listed as authors, so they should be able to update the plugin on the WP repo. I agree with the other comments – someone should fork it.

        The thing is – kickstarter or not – someone has to be willing to take it on, fork it, and maintain it. It sounds like the users are possibly willing to support such development. Now, just need to find the developer(s) to take on the project.

        • I’m not even sure a Kickstarter effort is all that needed. After all, someone could fork EF, fix/enhance it and release it as a premium, paid plugin, asking for $X for a year of support, etc. I guess the question is whether there’s a large enough market to support that and have it make sense.

  2. Since this is an integral part of our editorial process, I would be happy to donate should Automattic decide to put this plugin up for adoption or if another committed group of developer decides to fork it.

    If anyone is interested in this, please email me using my personal blog for funding.

  3. Did Armstrong say *why* they’ve not updated it in the plugin repository for so long? I mean, yay, VIP customers use it… but that’s not an excuse for the lack of public updates.

    No need to adopt it from them either – it’s OS. Someone could fork it.

    • Building a fork up from scratch is not as easy as it sounds. Automattic may censor any mention of Edit Flow or attempt to disallow any use of the name in the fork. It took Joomla the better part of two years to recover from the Mambo fork process. Users aren’t sure who to listen to, what to use. A handoff is normally a much smoother process, hopefully with Automattic VIP continuing to take an interest in Edit Flow’s stability.

      Edit Flow Reloaded might be a good name (Reloaded has become a bit of a convention around WordPress for fork which attempt to act as an heir to neglected or abandoned plugins).

  4. I’m commenting here with my community member hat on and not as an Automattician as I have no involvement with the team(s) that manage this plugin or any inside knowledge.

    It’s on GitHub. Instead of jumping directly to discussion of forking it, why not open an issue or two on the features you’d like to see? If they’re well received, write a patch and submit a pull request.

    I mean this is exactly the same type of thing you’d do for WordPress. You’d open a Trac ticket and contribute a patch.

    Just because a project doesn’t have any recent new features doesn’t necessarily mean that it’s abandoned, it just often means that priority has been placed elsewhere. I know that’s certainly the case with many of the plugins that I’d written and released personally.

    • This is a lame excuse. Automattic doesn’t have the resources to even update the compatibility strings? I refuse to believe that.

      Also, why take something over and then not update it? They didn’t need to take it over in order to use it. Taking it over also means taking on some responsibility.

      Sorry, but “it’s on github”, while meaning something to the technically inclined, leaves the vast majority of WP site admins out in the cold. People are trained to get plugins from the wp.org site (aside from premium versions sol d by their developer).

      • Yes, exactly! And particularly for an organizational workflow tool–it makes NO sense to get everyone trained and invested in something that isn’t being actively maintained. I’m encouraging small organizations to create sustainable, easily-maintained websites–the last thing they need is a headache because I chose a bum plugin, wasted their time, AND need them to adopt a new system.

  5. The issue is pretty much the same with plugins like Co-Authors Plus and Ad Code Manager and to some extent also Zone Manager (Zoninator).
    These plugins all exists in updated versions on Github, which are not reflected in the plugin repository on wordpress.org
    To me this indicates that Automattic are fixing issues for their VIP-customers, but aren’t very focused on users with self-hosted sites.
    I wouldn’t recommend using these plugins unless your fee familiar with managing plugins directly from Github.
    Finding good alternatives aren’t easy though.

    • Which makes me think of something: has anyone built a plugin for managing updates to plugins hosted on Github? You could install it, point it to the repos you want, have it suck them down and install them, and then monitor changes/milestones/tags? Hrmmmmm.

      You could even take it a step further and scrape together some sort of search interface that would parse readme files. Perhaps Github could get on board by allowing tagging/categorization of repos which would help with search. Plugin authors would tag their repo wordpress-plugin or wordpress-theme… etc.

      • People have been struggling to develop on Github and deploy to WordPress.org SVN plugin repository for years. There’s been lots of talk with Otto/Samuel Wood about adding Github integration to WordPress.org’s SVN here on the tavern, allowing us Github users/WordPress plugin authors to simply point a recent Github version at our WordPress repository and do an instant update.

        Ship does work. I just tested it. Ship though is a security nightmare as it grabs access to private repositories in Github as well as public ones as well as full access to your WordPress.org credentials. Deployer is a similar service with similar security issues. Workaround for Github would be to use a dummy user who only has access to your public repositories.

        We’ve coded a WordPress Github to WPSVN plugin in-house which also deploys from Github to WordPress SVN without the same security concerns (passwords only go into your own WordPress site where you have that we are a bit worried about releasing (support nightmare). There are also some paid services doing something similar but WP Pusher does not seem to cover the Github to WordPress SVN trail (they could add it easily enough).

        Of course, it would be much, much easier if WordPress.org would just code and enable this feature (one way deployment from Github to WordPress SVN. Ironically Github was recently raked over the coals for being unresponsive to open source project maintainers. Hope is the last thing every lost (Italian proverb).

        • Hey Alec,

          That’s a helpful breakdown of the current Github>WPorg workflow options. What I was proposing was something different, though: A way to let WordPress users search not only the wporg repo for plugins, but search Github as well. 

          The point would be to install plugins directly from Github as well as pull updates to them. If such a thing existed the folks here running a year old version of Edit Flow would have gotten the updates available on Github by now… See what I mean?

        • Hi Jason,

          Yes, your idea is an interesting one. Where I would agree with Otto/Samuel Wood though is that there should be a single canonical version of the WordPress repository (multiple repositories is one of Linux’s maintenance nightmares). WordPress.org plugin moderators have done a good job on being inclusive enough that there’s not substantial reason for anyone to open a parallel WordPress repository (imagine the extra work for developers with half a dozen or a dozen active plugins).

          No, for me, the missing key is an easy and secure way to deploy from Github (the collaborative environment of choice) to WordPress.org SVN (the end user/web publisher canonical version). It’s strange to still be talking about this when the original discussion about Github to WPSVN started no later than 2011.

          We’ll put up a GPL open source version of GitHub to WPSVN tomorrow on GitHub. The code needs some work to be easily deployed. Hopefully some other people also using GitHub for development and WordPress for deployment will be interested in collaborating.

        • Hi Jason,

          I promised you a plugin which would automatically update your WordPress.org plugins from GitHub repositories. When updating is a single big red button, it’s a lot easier to keep WordPress SVN release versions up to date. Here it is: GitHub2SVN. We’d be delighted to see some development forks and will process pull requests very quickly.

          Addressing your issue of updating plugins which are on GitHub directly, there are two options: the rather elaborate GitHub Updater (322kb/1658 commits) or the very simple External Update API (17kb/94 commits). External Update API comes set up for GitHub by default. My preference would be for the latter as it’s flexible and lightweight. The more sites and projects we build and maintain over many years, the more attractive simple and lightweight code becomes.

      • Yes, there are quite a few of those around; just recently stumbled across one of these and then did a quick look around.

        Some are just focusing on themes, also one or two classes for helping with updates directly from Github ..

        .. and if I remember correctly, the TGM class also supports fetching and updating plugins from Github.
        Though I might be mistaken.

        cu, w0lf.

  6. I’m a VIP Wrangler with the WordPress.com VIP team and I’m commenting on behalf of Automattic:

    Folks, we’re sorry that it looks as though we’ve abandoned Edit Flow. We certainly haven’t, and we should have at least updated the tested tag for the plugin as you rightly point out.

    We’ve done that today, as well as make sure Github and WordPress.org are in sync.

    (Note the WordPress.org page hasn’t updated as I type.)

    Internally I’m working on an effort to make Automattic better at maintaining our own plugins. We want to avoid this situation as much as we can, and I promise we’re trying.

    Thank you for calling us out on this. Let’s see what we can all do about getting some attention for Edit Flow.

  7. Thank you Jeff Chandler! I used Edit Flow on a website I previously managed, but got rid of it when I realized it had been abandoned. (Yes, abandoning communication = abandoning the product and its users).

    Good to see Automattic’s response, we’ll see if they follow through.

  8. Do you want another example: Intense Debate.

    Technically, the best feature-packed plugin to drastically improve commenting experience on wordpress blogs.

    Integrated into Automattic.

    And totally abandoned.
    The support threads full of people reporting huge issues that have never been fixed.
    I myself gave up on it after seeing it became SQL error hell in my server’s error logs because of the plugin with recent wordpresses.
    The plugin code never adapted to mobile device users.
    No contact option anymore, just a vague FAQ.

    I’m not saying Automattic is a bad company, far from it, but as all companies, they’re bound to lack in some regards.

    Well, plugins are one of those areas, they abandon some plugins and forget these plugins’ potential, forcing users to migrate, this is a pity :(

    So, hey, dear Automattic people, check IntenseDebate, it would deserve a revival :)

      • Matter of opinion, I guess.
        In terms of functionality, it’s got everyone one might have wanted, and more.
        The design was something that could have been fixed, like mobile devices compatibility.

        But the advantages were many. Nowadays, not much more, it’s sad.
        And the other systems have their own problems. Disqus wants you to create an account and they do their best to keep the comments discussion in their own site pages rather than on the blog where it started, for instance.


Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

%d bloggers like this: