[wp-hackers] Child plugins (add-ons) (Dino Termini)

[David Anderson]

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.
>
> -Mike

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 
their site

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).

David