Alex, (and others who might be programming)
I have hit a few quirks, or bugs, and figure it's time to put them down, before I forget.
1) The following did not generate either a perl -c error, or a plug in error:
print $IN->header();
print Links::SiteHTML::display('Multi_attach_select'), $IN;
}note the misplaced ')'
2) I had accidentally cut/pasted (hith the shift insert twice) the code into the install.pm file for the plugin in the edit screen. The plugin uploaded without errors (even though 3 routines were redefined in it). When I ran the program, I only saw the first routines, since I didn't think I had to go further, _BUT_ of course this created a major error. I was "fixing" the first routine, but the second one was the one being executed. The plugin module gave no warning. I caught it when I did a "perl check" of the install.pm SPECIFICALLY. This means the warnings we get if upload a module with errors are being checked DIFFERENTLY than the perl check command does!! This is _VERY_ confusing for a developer!! The should be the same check, or there should be a warning to run perl check even after the OK message is obtained.
3) And, if you edit your plugin.cfg file directly (as you would if you are developing, and don't want to keep re-installing the plugin if you've made a change like a new hook, new parameter, or such), _MAKE_SURE_ you upload it in ASCII!! Your FTP program might be set for .pm and .pl and such to go up as ASCII, but .cfg is often 'binary'. If you upload in binary, it will NOT work! But it won't generate any errors either!! (alex... a simple test to see if the file is binary, when it's read it might be a big help for killing that sort of error -- this doesn't hapen with globals.txt or ConfigData.pm because .pm and .txt are known "ASCII" types.)
PUGDOGŪ Enterprises, Inc.
FAQ:http://LinkSQL.com/FAQ
Plugins:http://LinkSQL.com/plugin
I have hit a few quirks, or bugs, and figure it's time to put them down, before I forget.
1) The following did not generate either a perl -c error, or a plug in error:
Code:
} else { print $IN->header();
print Links::SiteHTML::display('Multi_attach_select'), $IN;
}
2) I had accidentally cut/pasted (hith the shift insert twice) the code into the install.pm file for the plugin in the edit screen. The plugin uploaded without errors (even though 3 routines were redefined in it). When I ran the program, I only saw the first routines, since I didn't think I had to go further, _BUT_ of course this created a major error. I was "fixing" the first routine, but the second one was the one being executed. The plugin module gave no warning. I caught it when I did a "perl check" of the install.pm SPECIFICALLY. This means the warnings we get if upload a module with errors are being checked DIFFERENTLY than the perl check command does!! This is _VERY_ confusing for a developer!! The should be the same check, or there should be a warning to run perl check even after the OK message is obtained.
3) And, if you edit your plugin.cfg file directly (as you would if you are developing, and don't want to keep re-installing the plugin if you've made a change like a new hook, new parameter, or such), _MAKE_SURE_ you upload it in ASCII!! Your FTP program might be set for .pm and .pl and such to go up as ASCII, but .cfg is often 'binary'. If you upload in binary, it will NOT work! But it won't generate any errors either!! (alex... a simple test to see if the file is binary, when it's read it might be a big help for killing that sort of error -- this doesn't hapen with globals.txt or ConfigData.pm because .pm and .txt are known "ASCII" types.)
PUGDOGŪ Enterprises, Inc.
FAQ:http://LinkSQL.com/FAQ
Plugins:http://LinkSQL.com/plugin