MT Plugin Manager

After tag-teaming stupid MT shacolby and I finally succeeded at trying to get this MT Plugin Manager to work.

I installed on our system:

• ArchiveYear
• AWStatsReferers
• CategoryFaceted
• CategoryHeaderFooter
• CategoryOfArchive
• Countdown
• EntryNumber
• Exception
• FilterCategories
• IfArchive
• MTAmazon
• MTList
• Macros
• Process
  Tags
• Regex
• RSS feed (dunno if that one works yet though)
• 
  RelatedEntriesByKeyword
• SmartBody
• Topic Icon

by copying the
master list of all the plugins, renaming it to plugins.xml and placing
it in the plugins/ directory, then copying styles-pm.css to the mt-static directory, I at least got the thing to display- but now the “manual install” page still doesn’t work.

• the individual files it finds start with a .//usr/local/apache rather than just “/”. Why? Does that matter?
• the “action” field in the FORM (post) entity in the page is empty, which seems to suggest it wants the same CGI that generated the page, mt-pm.cgi
• the same mode, __mode=manual_install, is specified as a key-value pair
• the unknown plugin file (e.g. mt-amazon.pl) is also misnamed in the FORM: changed that too
• Manually edited file and ran on client to get this to work… nothing yet
• Within Manager.pm, “manualInstall” does most of the work, generating the page listing all the unknown files (potentially plugins) and farming out to “manualInstallFile” if information is coming in from a form
• maybe the save process is just not working? PluginData.new() is being called… defined in MT::PluginData.pm (in lib, not extlib/MT/Plugins). Where is this data stored?
• Looks like the manual registry is working, however the manual registry page doesn’t make previously-registered files go away
• If the plugin in question is a simple series of files, (like perl files), then there is no problem, and the installation goes well
• however, if there is unzipping involved, we get problems: compilation stops on things like

  Bareword “Z_OK” not allowed while “strict subs” in use at /usr/local/apache/cgi-bin/mt/extlib/Archive/Zip.pm line 1808

• testing on ArchiveYear and IfArchive – both of which use .zip files to install
• the files in the working blogs are owned by user www-data and group ftp– yet the .zip files brought into manager-cache are
  owned by user www-data and group www-data.
• Even the successfully installed plugin, FilterCategories, is permissions 644. Will this run?
• shac tried quoting all the return values in Zip.pm… this got rid of some errors. But that means the errors were there because the return types were not defined, which is probably in Compress::Zlib
• damn, it’s looking like :
  1. There are two different Zlib.pm modules: Compress::Zlib and IO::Zlib
  2. we have two of each on our system- we already had them installed in our perl, in /usr/lib/perl5/site_perl/5.6.1,
     and now we have one in the MT installation
  3. the MT installation version may not define Z_OK ?
  4. I added a debug to print out @INC.. sure enough we are using the MT version first… should I update the MT libraries, or just mess with “use lib”?
     I’ll update the libraries.
• uh oh- our Compress::Zlib and IO::Zlib modules in MT are identical. I think we screwed up the install.
• yep that was it… deleted that one… now the main problem is permissions. At this point there are two ways to fix it that I can see:
  1. open the libraries to any user, or get shac to put every system user in the same group and do it that way. Acutally, the user owning the libraries right now is not the MT user for a reason; I wonder if we should change that or not, it seems like a security risk?
  2. Modify Manager.pm so it is smarter about file ownership and permissions. If I do that, I guess I should insert the fix in the bug tracking report to be a good MT citizen…