[wp-hackers] Child plugins (add-ons) (Dino Termini)
david at wordshell.net
Sat Feb 16 22:09:30 UTC 2013
On 16/02/13 21:38, wp-hackers-request at lists.automattic.com wrote:
> On Feb 16, 2013, at 4:31 PM, David Anderson <david at wordshell.net> wrote:
>> >it's to allow users to receive their add-ons via the normal WordPress updating mechanism, to do so without breaching wordpress.org rules on remote code
> Interesting conversation. Would you mind elaborating on those specifics? I'm trying to envision what code is need for what you are saying.
The specifics of the updating mechanism? I'm using the library mentioned
before to fetch update information, and updates, from my shop site. On
the user's side, the add-ons manager plugin over-loads the URLs used to
get update information and updates for the other plugin. That's easy
enough. It sends along the user's identifying information. The shop end
receives that information and passes back the update information in the
right format. That includes a version number (which can depend on what
add-ons they've bought; basically, add a new segment to the version
number and use that to store add-ons information. If the plugin is at
version 1.2, then 1.2.1 is used for '1.2 with 1 add-on'), or the
download if requested. The download is created on-the-fly, again
according to the purchased add-ons.
The shop-side also needs code to hook into the e-commerce platform and
record new entitlements when purchased. So the flow goes like this:
1) User buys add-on in shop.
2) Upon payment, hooks fire to record that add-on purchase/entitlement
in the shop's database
3) User visits their own site, and makes sure that they've got the
"add-ons manager" plugin installed, and have entered their credentials
for the shop.
4) The add-ons manager now indicates to the user that they've made a
purchase, and invites them to claim it for this particular site. User
clicks on a link to make that claim.
5) This generates an RPC to the shop, which now records that this add-on
purchase is linked to that particular site.
6) The add-ons manager also forces WordPress to re-check for available
updates at the same time.
7) The "any updates available?" request thus arrives at the shop, which
indicates that yes, there are updates.
8) The add-ons manager is also at this stage telling the user to "follow
this link to your updates page to claim your add-on"
9) User goes to normal WordPress updates page, and clicks on the link to
update the plugin
10) WordPress requests the new zip from the shop. The shop constructs
it, containing the new add-on, and delivers it to WordPress
11) WordPress installs the plugin, now containing the new add-on. The
user now has the add-on.
So from the user's point of view, they:
1) Buy add-on from shop
2) Install add-ons-manager plugin and enter their shop credentials
3) Click on link in add-ons-manager plugin to claim the purchase
4) Click on link to perform update to actually receive that purchase on
It was far more code + complexity than I realised when I started! I'm
thinking I'll try to clean up and market that lump of code next, it took
so long to create! (I've ended up with two plugins - the add-ons manager
that the user has; and the shop-side management plugin that does the
fancy work at that end).
More information about the wp-hackers