[geeklog-devel] Plugin help --- Package Extractor

Tony Bibbs tony at tonybibbs.com
Thu Jun 14 10:06:04 EDT 2007


Joe, while all this sounds good, it duplicates everything PEAR does.  Just a note you can do all this stuff with an embedded PEAR installation (read: no dependency on a system-level PEAR installation).  While people are trying out Joe's code (which is good) I'd wish people would do more than just stare blindly at the PEAR stuff committed months ago.  A little TLC and it will do everything Joe's trying to do minus having to manage the core code that manages packages, etc.

Feel free to drop this note in the Trash folder, but figured i'd remind everybody this sort of stuff is there in a way that is a lot less work us.  Not that I'm bitter ;-)

--Tony

----- Original Message ----
From: Joe Mucchiello <joe at ThrowingDice.com>
To: Geeklog Development <geeklog-devel at lists.geeklog.net>
Sent: Tuesday, June 12, 2007 9:26:51 PM
Subject: [geeklog-devel] Plugin help --- Package Extractor

I've just about finished a new plugin called Package Extractor for 
Geeklog. I consider it only Alpha level code at the moment. In a 
nutshell, it presents an upload form for plugin tarballs. You upload 
the tarball and it extracts the files to the proper directories 
(admin to /public_html/admin/plugins/$plugin_name, public_html to 
/public_html/plugins/$plugin_name, and the rest to 
/plugins/$plugin_name). Assuming nothing goes wrong it redirects you 
to the plugin.php where the install link for the new plugin should be 
available in lower part of the page.

Features (and Limitations):
* Appears on the Admin menu only to members of Root as "Package 
Extractor (N/A)".
* It only works with tar, tar.gz, tar.bz2 and tgz files as it is 
using PEAR::ARCHIVE::TAR to do the extractions. Plans for zip and rar 
support as they become available.
* Likewise, it is pretty strict about the file name being 
$plugin_$plver_$glver.tar.
* If there is a file named package.inc in the tarball, it will 
attempt to execute the function plugin_postpackageupload_$plugin (if 
it exists) after it moves the files. This is a place where plugins 
with weird file location requirements can move more stuff around. 
(Like Blaine's lib-portalparts.php file.) If the function returns 
false, the upload is aborted (though I still need to make it clean up.
* Each major step of the process executes in its own request using 
redirects to avoid long processing time limitations made by some webhosts.
* Files are placed in /data/packages before extraction. On success 
they are moved to /data/packages/installed. (Automatic cleanup of 
installed is a future feature.)
* If the plugin is already installed, it compares plugin versions. If 
they match, it aborts the extraction. If they don't match it disables 
the current plugin, extracts and re-enables. This should activate the 
"upgrade" button in the plugins.php admin screen.
* It logs much of its activity to a file called /logs/package.log

Future Ideas:
* Well, some kind of 
SOAP/XML-RPC/Web20/whatever-it's-called-these-days interface to a 
public website which would allow you to download the package from the 
web rather than uploading from the browser would be really cool. 
Probably include a support URL API like plugin_support_site_$plugin 
so plugins can reveal their "official" website to the package 
extractor (this would go in functions.inc of course).
* It's called Package Extractor because I expect it to also work with 
Theme installation someday.
* package.inc could have lots of cool functions. Like, 
plugin_final_instructions_$plugin, a function that would display an 
informative page about last minute things you MUST take care before 
hitting that install link. It would end on that page instead of 
plugins.php page if the function returns a string. Or, 
plugin_home_server_$plugin which, with the web20 interface could 
allow the plugin to verify it is up to date.
* Oh, yeah. It needs a good icon.

As I said, it's at the Alpha stage. It works in my test environment 
for most simple plugins (autotags, nettools, faq, glutil). More 
complex plugins really need that package.inc file but that's up to 
the plugin writers to support. And that's why I'm posting here. This 
thing needs testing in alternate environments (I've only got Win XP, 
Apache 2, PHP 5, GL 1.4.1). I'm looking for a few testers and for a 
few plugin writers to support the package.inc extensions.

I'll have a tarball available to those who request it by the end of 
the week (although originally I was going to post this Sunday so who 
knows). I just need to test installing the package extractor plugin 
itself as it's been an active plugin in my test system for a while 
now. I also need to make a sample package.inc file.


----
Joe Mucchiello
Throwing Dice Games
http://www.throwingdice.com 

_______________________________________________
geeklog-devel mailing list
geeklog-devel at lists.geeklog.net
http://eight.pairlist.net/mailman/listinfo/geeklog-devel






More information about the geeklog-devel mailing list