• some design idea
  • a centralize server for the NP_PM to query for updated plugins
  • data in XML format
  • allow install and upgrade of plugins
  • package crc/signature is needed for file integrity check against trojan and alike
• some thought on plugin upgrade
  • basic idea is to add a pversion column in nucleus_plugin, new version overwrite existing one, plugin admin menu detect it and list it for user to click for upgrade, upgrade is done by calling upgrade($oldversion) from the new code, also update event subscription list
  • I think it's not a good idea to just overwrite the fileas it might failed and user will be in hell to roll it back, maybe better to store it on a temp location until user click to upgrade. The drawback is the plugin need to do more to move the file and backup the old files (so we can rollback if failed)
  • needsUninstallToUpgrade($oldversion) can be used to checked whether to uninstall for upgrade
  • updateRequirement($currentInstalledVersion) can be used
  • can we just uninstall/re-install plugin??
  • user still have to follow the rest of the install instruction to get a plugin to work…
  • This mechanism is need for seamless plugin upgrade. ie mysql table structure changed. Yes, we can simply uninstall/re-install, but all current user data for this plugin likely lost when unInstall() drops all the tables. If we hacks the code to skip unInstall, the plugin will not work properly in this case as table structure changed….

• Pre-alpha code to test out some basic with new plugin add and update check function, to try out server-client protocol, zip file operation, zip download
• For 1st version, we can first implement just the upgrade function, and introduce install function later
• For upgrade function, we can do with uninstall/re-install and no signature/integrity check. However, initial design should take these into account
• Plugin install function will be added later
• We should implement plugin upgrade API in core and make this plugin use it in a later stage. For cases that a plugin db table structure changed, I think we might be able to put in logic in install() to detect if plugin table is create and called upgrade() for now.

This plugin actually a set of 2 plugins; one acts as query/download/admin server and the other as install/upgrade client

• provide a plugin admin menu to list all current plugins
• function to add new plugin, which track all version of the plugin
• function to add new version, each new version add becomes the latest version, admin has to fill in info like version/description/note, signature for each version is generate, how to uplod file to server? file upload manager? FTP??
• function to delete plugin and all version of the code
• function to delete a version of a plugin
• function to update a plugin info
• function to update a version of plugin ie. replace code
• install action event is used as client query/download entry point? or do like NP_pluginplugin that with an external php
  • entry point provides: 1) batch updated query function 2) code download 3) code signature query
• a plugin writer can run their own server to serve the plugin before it is added to the central server.
• some kind of auto plugin submission between servers?
• a plugin browse/list page for user

• provide a plugin admin menu to display list of updated plugins ready for upgrade
• client is configure to point to one central repository server
• update query can be trigger manual or automatically
• function to browse available plugins (in future release) one idea is to put this function on the wiki, with an install url to point to NP_PM server.
• a skinvar can be added to warn admin when a updated plugin is available

• Should we use XML-RPC or Nucleus action as web service API?
• get all available request: send from client to server, no parameter
• get all available response: send from server to client, contain list of all available plugins
• get plugin info request: send from client to server, contain plugin name(s)
• get plugin info response: send from server to client, contain plugin names, version, url/alt url, note, md5, upgrade method

• plugin version information
  • name of plugin: NP_<name of plugin>, which has to be the same throughout all versions as it is used as a key when search for latest version, arquire via getName()
  • id, an internal number for used in MySQL, used to identify a particular plugin in NP_PM's database, also used to sort versions of a plugin ie using SORT BY id DESC in SQL query (bad assumption or we can sort by version??)
  • version: in a uniform v<major>.<minor><patch> (ie 0.75b), major/minor is a number that can be intvar(), patch is optional alphabet from a-z, arquire via getVersion() (will be it too hard to do version compare this way???)
  • package URL/alternate URL: allow point to local or remote, this way we can spread the download workload on the plugin server to others, also an alternate location should be tracked if possible, in case the primary's gone
  • list of files: do we need this or we can get it from the zip dynamically?
  • description: a short description from the plugin's getDescription()
  • note: a special note attached to this verion. One way to use this isfor telling user post-upgrade manual action require (alternative is to helppage inside the plugin package, which is more preferable)
  • upgrade method: denote how to upgrade this plugin, it can be overwrite (simple overwrite and done), reinstall (uninstall+re-install), upgrade (overwrite than call upgrade() TDB)
  • MD5: signature of the package for integrity and security check

• adding new plugin version
  1. blog admin go to PM admin menu and click on add new plugin link
  2. a form come up, admin need to upload the zip file, fill in the url to zip, note, and upgrade method, than click add
  3. the plugin manager gets the plugin (if remote), extract it and create an instance, do a supportsFeature('PluginManager') check, call getVersion(), getAuthor(), getName() and such to get plugin info, also calculate the MD5 signature
  4. then a page with all the info is displayed for admin to confirm before save to the database.
  • how do we protect ourselve from some nasty someone write and submit to us a destructive/worm/virus plugin??? The best way is to eyeball the code before submit it to the plugin manager server.
• view statistics
  • statistics is collect when a client send a query, mostly just download count, number of know client (how without collecting IP??)
  • a UI is used to display this to admin only.
  • of course, we are not big brother, so no IP should be collected. or is it a issue?? (maybe we can make this optional to submit the client's url so we can feed it to Sites running Nucleus and for client counting purpose. It will be cool to know how big our actively user base is via this 8)
• modify plugin version
• disable plugin version
• delete plugin version

• manual plugin update check
  1. user blog admin go to the admin menu and click on the check for plugin update
  2. the backend gather list of all installed plugins and send a query to the PM server
  3. upon received the response, which is XML of list of plugins that changed (or not changed, or no supported), it stored it to a table for review
• automatic plugin update check
  1. A periodic plugin update is triggered (how? crontab? NP_Batch (pending)? skinvar ?)
  2. same as the manul check, the information collect is stored
• plugin upgrade
  1. user blog admin goto the admin menu and click upgrade plugin
  2. a form is display with all available plugin updates
  3. admin can select which plugin (or click all) to update
  4. the backend will download the zip file (url provided in the query response), uninstall the zip file to overwrite the old version, than install the plugin (ok… this is version 1 algorithm, v2 hopefully will have proper uninstall/overwrite/install or using upgrade/downgrade function from core if available)
  5. then display the plugin writer note on any manual action needed (via helppage??)
  6. for uninstall/overwrite/install case, warn users to check the plugin option as it is lost during the process
  • how to deal with install failure??? we might need to back up the old files and roll it back…. not a trivial operation!! I have seem enough problems of related nature at work…. idea #1 setup some kind of php exec jail that so the plugin instance cannot do anything ie mysql query network and such. get*() should not need any external functions…..
• new plugin install
  1. TBD