ALex,
Here's another one.
In modify.cgi
if (exists $CFG->{add_system_fields}->{$key}) {
$new->{$key} = $link->{$key};
}
else {
my $val = $IN->param($key);
$new->{$key} = defined $val ? $val : $link->{$key};
}
}What happens, is that other fields that are passed into the form are _NOT_ saved in the Changes table database record.
This prevents a plug-in from adding fields for checking.
_ALL_ data should be saved in the Changes table, since like Preview this may contain significant numbers of extra fields.
Then, when _actually_ saving the data to the Links table, (or other tables) the library routine uses the
foreach my $key (keys %cols)
for "safety" and to prevent database errors.
I hope I'm clear, but I just spent 2 hours trying to figure out why my upload file was not being passed to the plug-in either in a pre or post hook! And I think this is why. I'm going to hack around it for now, but a better way (official) needs to be figured out!
Even if I pick the data out in from the "$IN->param()" hash, those changes are ignored pretty much, and writing to $IN is not the best thing to do.
I guess the plug-in could try to read the changed table entry in the Changes table, rather than just pass the new values back to modify.cgi, but it seems logically that modify.cgi should be more "lenient" saving change data, and the library routines need to be "strict" in generating the SQL statement.
Either way, I had a problem with the modify routines in the beta, and now that I'm trying to release a stable version, I'm having to deal with them :) Some official way of dealing with the flow of data through modify.cgi should be set down, otherwise, plug-ins will be overriding each other, cancelling each other out, and doing other funny things, when really it's a core "feature" of modify.cgi's internal subroutine that is literally dropping the ball :)
PUGDOGŪ
PUGDOGŪ Enterprises, Inc.
FAQ: http://pugdog.com/FAQ
Here's another one.
In modify.cgi
Code:
foreach my $key (keys %cols) { if (exists $CFG->{add_system_fields}->{$key}) {
$new->{$key} = $link->{$key};
}
else {
my $val = $IN->param($key);
$new->{$key} = defined $val ? $val : $link->{$key};
}
}
This prevents a plug-in from adding fields for checking.
_ALL_ data should be saved in the Changes table, since like Preview this may contain significant numbers of extra fields.
Then, when _actually_ saving the data to the Links table, (or other tables) the library routine uses the
foreach my $key (keys %cols)
for "safety" and to prevent database errors.
I hope I'm clear, but I just spent 2 hours trying to figure out why my upload file was not being passed to the plug-in either in a pre or post hook! And I think this is why. I'm going to hack around it for now, but a better way (official) needs to be figured out!
Even if I pick the data out in from the "$IN->param()" hash, those changes are ignored pretty much, and writing to $IN is not the best thing to do.
I guess the plug-in could try to read the changed table entry in the Changes table, rather than just pass the new values back to modify.cgi, but it seems logically that modify.cgi should be more "lenient" saving change data, and the library routines need to be "strict" in generating the SQL statement.
Either way, I had a problem with the modify routines in the beta, and now that I'm trying to release a stable version, I'm having to deal with them :) Some official way of dealing with the flow of data through modify.cgi should be set down, otherwise, plug-ins will be overriding each other, cancelling each other out, and doing other funny things, when really it's a core "feature" of modify.cgi's internal subroutine that is literally dropping the ball :)
PUGDOGŪ
PUGDOGŪ Enterprises, Inc.
FAQ: http://pugdog.com/FAQ