Recently we struggled with a difficult issue in WordPress Multisite. We take care of a network of sports weblogs. Each is for a different sport and not all the domain names sound the same.
We have a master install at say worldrecords.org (sample name, not our client’s site). Logins only are SSL and all take place at worldrecords.org. An account at any site gets you access to all the sites. Hence login and password takes place at the master domain. Most visitors are not even aware of the domain switch during login.
When people would lose their password, the password reset email would not come from skatinggolds.org or lugegolds.org but from worldrecords.org. Many people would not recognise the domain and would delete the email without clicking and finishing the password reset. Worse yet the email might be considered spam by spam filters.
There is no code in WordPress Multisite to make sure these password reset emails come from the correct domain for account (original signup domain or site from which the password request came). It would be a day of coding to write something like this up. Longer to troubleshoot it. It would be weeks or months of work to try to push important code like this through WordPress Core Trac. If possible at all. WordPress Trac is very political and there are dozens of gatekeepers who like nothing better to mark tickets edge cases and close them peremptorily (1).
Here is where GitHub steps in.
The very brilliant Eric Teubert (2) logs and posts his small but important WordPress enhancements (62 of them!) in GitHub with just enough annotation that other developers can find his work. It’s very easy for us from our own GitHub account to fork his code and add improvements and enhancements of our own and for Eric to test and merge them to his master gist.
In this particular case, Eric has posted an excellent fix for our issue: Multisite: Password Reset on Local Blog.
Our client’s password reset emails now go out from the domain from which the password request was made. Users get those emails and click the links and have their new passwords.
Hundreds of hours of customer support are saved at our client’s sports networks. Hundreds of unhappy clients are made happy now. A win for everyone, thanks to:
- the brilliance of GitHub as an open source collaboration environment.
- the generosity of Eric Teubert to post his solutions.
Without GitHub it would just be too much work to share code properly and Eric would be unable to effectively show his generosity. Inertia would take over and hours would run out.
Developers develop on GitHub not in WordPress SVN as the tools are better
Arguably this kind of collaboration should take place directly on WordPress.org. There’s no viable system for this kind of collaboration within a large community where many people do not know one another (SVN works fine in a smaller community with hundreds of developers mainly know one another: that’s how WordPress started).
Why, oh why will WordPress.org not take advantage of the rich ecosphere of GitHub for its plugin repository. WordPress SVN is nigh impossible for useful collaboration. One has to contact the developer and acquire full contributor status before even starting to work together. This works as a huge brake on open source collaboration. Here’s how open source collaboration works: You find some code, you don’t know the person, you collaborate with hundreds of people per year.
Trying to get collaborator rights on even a third of the hundreds odd plugins we use actively would require hiring a full time person. All that energy basically evaporating like water in a desert. Good code gets wasted.
Solution: a native GitHub-WordPress SVN bridge
Due to the dislike of WordPress plugin repository keymaster Samuel Wood (Otto) to Git and particularly GitHub (2), the entire WordPress development community has to struggle with moving their code between GitHub and WordPress SVN via commercial service or plugins they’ve written themselves. We even have such a plugin free to the world but it was refused admission to the WordPress plugin repository.
A GitHub-WordPress SVN bridge would be much easier to write from inside WordPress.org. I hope one day Samuel Wood opens his heart and mind to Git and makes WordPress developers lives easier. A single day of coding could increase the velocity of collaboration on WordPress plugins by about three times. How about it Samuel?
(1). There are also hundreds of dedicated coders working really hard to improve WordPress: one does not exclude the other. In some cases, they are even the same people. For instance, a gatekeeper who likes nothing better to slam shut other people’s important tickets yet writes a lot of good fixes for him/herself and his/her projects. A concrete example of such a person would be @nacin Andrew Nacin. Triage remains a thankless job.
(2). Generosity is a way of life for Eric. Here’s his mission statement:
I help make podcasting accessible to everyone.
I develop the Podlove Podcast Publisher, the WordPress plugin for podcasters.
Unlike most plugin developers including Automattic (and Foliovision), Eric is true to the founding spirit of WordPress. His code is open and free and available from his own website. He only charges for support. He eschews recurring payments. To go back to those golden days of idealism without VC vultures circling the WordPress skies….
(2). In fairness to Otto, his dislike is grounded on GitHub’s lack of open source credo (i.e. it’s a third party service). The track record of third party services is not good. My counter argument here is that if GitHub abuses its monopoly position, WordPress could either switch over to Git and replicate much of the GitHub functionality or simply write a new bridge to the replacement tool of choice. I.e. GitHub’s monopoly is illusionary.
Moreover GitHub charges nothing for public repositories so GitHub is effectively an open source service (subsidised by private repositories, mainly paid for by companies).
Alec Kinnear
Alec has been helping businesses succeed online since 2000. Alec is an SEM expert with a background in advertising, as a former Head of Television for Grey Moscow and Senior Television Producer for Bates, Saatchi and Saatchi Russia.
Umm.. I have no idea why you’re blaming me. I have nothing against git. I’m not a huge fan of github’s tools, but if you want to develop there then by all means, do so. We do a lot of WordPress development using github. WordPress even has it’s own git repository if you prefer to use that: core.git.wordpress.org
Many people do their development and collaboration on other services like Github or Bitbucket, and then only push to the WordPress plugins SVN for release time. That’s perfectly acceptable and indeed recommended.
Hi Otto!
Fantastic. We have talked about GitHub in the past (on WPtavern I think) and you’ve argued against a GitHub to WordPressSVN bridge.
What I’d like to help you build is an in-house GitHub2SVN bridge. We have a plugin which developers can run from their own website but it’s very clunky. You turned it down for the WordPress repository due to security issues which are really tough to fix (it’s not our best code, the developer who built it is journeyman level). I know there are third party services as well but that’s added expense hassle and further compromise of security. It would be much better done within WordPress.org with credentials shared in such a way that WordPress.org does not have access to the full GitHub account.
Let’s make collaborating on plugins on GitHub and deploying on WordPress SVN really easy. It would be the best of both worlds!
That is already the plan. We’ve been planning that for over a year. But you’re too soon here. We need the new plugin directory in place first. One step at a time. Many changes coming soon.
Hi Otto,
There’s no need to plan so much. A built-in bridge to GitHub is something to just be built. And it should be as simple as possible.
Here’s how it could work. A WordPress plugin author just names the GitHub master the SVN master in a very simple plugin management screen in a plugin’s Admin settings, i.e. wordpress.org/plugins/businesspress/admin
In there, I’d paste all of: github.com/foliovision/businesspress
WordPress.org would check that URL to make sure it’s working or throw an error.
Of course there could only be one such GitHub master link in the WordPress.org admin screen. WordPress.org’s GitHub account would then “watch” that plugin. When there’s an pull into the Master branch (Master Branch’s only for simplicity’s sake), WordPress would then pull in the Git version and replace the current SVN master.
There’s no need for any settings, there’s no need for any programming. Dead simple.
WordPress plugin authors could just update their plugin on GitHub and have the changes come over to WordPress SVN in near real time. No fuss, no muss. You don’t even need to talk to GitHub (unless they limit the number of plugins a single account can watch (in which case you’d just need an exception to that limit).
Alec
PS. It doesn’t matter that the accounts match or authorised. If you have a plugin author who is pulling other people’s plugins from GitHub into WordPress SVN, that author would need a warning and a ban.
I wouldn’t use the master branch, I’d probably use the release mechanism and webhooks to notify w.org of those changes. But other than that, you have the basic idea.
That said, it would be added to the new directory, after it is launched. Not to the old directory.
Using the webhooks would be fine but I worry it makes deployment more complicated. My idea means not adding more burden to busy developers on an individual basis. Let’s do the hard work for the developers so they can release updates more efficiently and focus on improvements not deployment process.
I understand what you are saying about the new directory Otto but that seems to just add more delay for little purpose. Adding GitHub to SVN to the old directory, i.e. now, would be a matter of a day or two of coding. Moving it to the new directory would be a matter of hours as the functions would already be in place and just need to target new ends.
Hi Otto,
Even WordPress core is not only using GitHub instead of WordPress SVN for forking and managing repositories, they are even using GitHub issue tracker.
Refusing to put in a smooth bridge from GitHub to WordPress SVN is just a case of inconsiderate stubbornness from the WordPress.org Plugin Directory and more particularly you (as the gatekeeper here).
Remember the plugin directory staff’s role is to help developers and not to hinder them. This is just getting silly. Waiting for the new plugin directory and dragging your feet for another nine months afterwards is both absurd and unfair. You guys should be ahead of the curve, not four years behind it.
PS. Should you not be working to provide plugin authors both technical leadership, superior tools and better workflow? Sometimes it seems the plugin administration are more worried about your own comfort than that of those building WordPress amazing tools for free.