be considered a "bugfix" since a NUL mostly likely represents a delimiter between multiple form values and thus the end of a "line".
thanks to Jens Seidel <email@example.com>)
to Martin Sin <firstname.lastname@example.org> added Vietnamese translation of Debconf templates (Closes: #311962, thanks to Clytie Siddall <email@example.com>)
can tax shipping only when taxable items are in the total.
Add a new "size_scratch_prefix" argument to the [image] tag. If "getsize" is in use (which is the default), passing a value for "size_scratch_prefix" to [image] will result in the height and width of the image being placed into temporary Scratch-space variables with names "<size_scratch_prefix>_height" and "<size_scratch_prefix>_width", respectively. Naturally, if "getsize" is given a perl-false value, the dimensions will not be found for the image and thus the "size_scratch_prefix" value is ignored. (Dumb) Example: [image src=foo.png size_scratch_prefix=foo] foo.png has height [scratch foo_height] and width [scratch foo_width] This kind of thing can be useful for styling control and page layout, as it allows the application programmer to work with the image dimensions and adjust markup/styling appropriately in response to those dimensions. The scratch values created are temporary (i.e. as if they were created via [tmp ...]) and will not persist in the session past the end of the current page process.
… of overwriting "default" with one another.
Fixed bug in &Vend::Interpolate::iterate_array_list that could cause the $Row object to be an empty hashref in the event of certain looping conditions that cause the field hash to be populated but not the fieldname array.
Fixed some issues in the discount-related code to ensure that the $::Discounts hashref is used appropriately and to maximize robustness of discount-spaces function.
Ethan Rowe <firstname.lastname@example.org>. Can provide a whitespace-separated list of sub names to execute following a successful login; this "postlogin_action" list directive/argument can be specified at the profile level or as an argument to the [userdb] tag at login time. The subs will be executed in the order they are listed within the "postlogin_action" value. They are not passed any arguments, and their return values are not used in any meaningful way; any behaviors desired from the login must therefore be entirely encapsulated within the sub(s) specified in the list.
The CartTrigger functionality allows for specification of any number of subroutines (global or catalog subs, specified by name) to execute whenever the contents of a shopping cart are changed via the standard means available through CGI variable space (i.e. when changes are invoked via the 'process' system actionmap through mv_order_item and mv_order_quantity field submissions, or from a standard Interchange cart page). The subroutines will be executed per-change, such that any page process resulting in multiple alterations to the cart will potentially call these functions multiple times. Directives are used to turn this behavior on/off and to control some details of its behavior: CartTrigger: an array-type directive; list the different subroutine names to execute at cart-modification time here. CartTriggerQuantity: a boolean-type (i.e. yes/no) directive, defaulting to 'no'/'false'; when set to yes/true, changes to item quantity on an existing cart member will cause the cart trigger subs to fire. A value of 'no' (the default) means that quantity changes on existing cart lines do not call the trigger (though a quantity change to zero will result in a delete, which does fire the cart trigger). Each subroutine specified in CartTrigger will be passed the following arguments whenever they are called: 1. Reference to the cart 2. Scalar representing the action that fired the trigger; value will be one of: add, update, delete 3. Hashref pointing to the new row (except for the 'delete' action, in which case this will be undefined) 4. Hashref representing the old row (except for the 'add' action); for 'update' actions, this will be a *copy* of the row prior to the changes. The old row is no longer a member of the cart. 5. The cart's name The return value from each subroutine call is pushed onto an array; when the particular trigger firing is complete (i.e. all subroutines specified in CartTrigger have been called), the full array of results is returned. However, the initial version of this functionality does not use these return values in any meaningful way. It must be noted that the Interchange cart subsystem is based on arrayrefs of hashrefs; there is no object encapsulation for limiting/monitoring programmatic access to the contents of any cart. Consequently, direct manipulation of the cart from within Perl will *not* cause these triggers to fire. The triggers only fire when the cart contents are modified through the standard Interchange CGI-based variables/processing. Therefore, it is assumed for now that any programmer sufficiently comfortable/confident to manipulate cart contents directly can also be given the responsibility of deciding whether or not it is appropriate to invoke any cart triggers in response to such changes.
and use the UserControl setting that was already passed in rather than a direct hook-in to the catalog config hash.
…ore in November 2003
* Continue "project_id" -> "po_number" rename.
* Designed to take care of the case where a customer forgets their ID and creates a new account. * Adds radio box to select target, button to merge the users. Should be self-explanatory, but probably should be added to UI documentation. * Actions are logged, by default in logs/merge_users.log.
many-to-one targeting such as a user merge feature.
global or catalog variable MV_EMAIL_INTERCEPT, which causes all outgoing email to be rerouted to that email address. This makes it much easier to do development with functions that involve email because real end-user email addresses can be used but the developer will receive the mail. Headers in the form X-Intercepted-To: etc. are added to show what the original destination of the mail was, and the interception is also noted in the catalog error log.
flex_select (like userdb and transactions in large mode) to get the right menu.
wildely out of date and I doubt that anyone uses it anyway.
have one already. I think this was done for Solaris. I can't remember now. :-) * Fixed a bunch of potential buffer overflows. Each of them would have a very remote possibility of being tripped, unless intentionally. * Added a "OrdinaryFileList" directive to DECLINE requests where the path starts with one of the values in the list. If this module DECLINEs a request then Apache will attempt to serve the request instead. This is useful for creating excptions to <Location />, for image files etc. * Added a "FilesContext" directive so that we can handle ourselves if we are called from within a <Files> context instead of a <Location>. If I can find a way to determine this automatically then I will drop this directive. Consider it to be depreciated even though it has only just been added. * Added a "URIPathPrefix" directive to replace the leading '/' in the SCRIPT_NAME with the given value, before passing the request on to Interchange. * Removed "FilesContext" and "URIPathPrefix" configuration directives and replaced with a new "InterchangeScript" directive. The new "InterchangeScript" can be used to specify a SCRIPT_NAME to pass to Interchange. The value will override the SCRIPT_NAME=/foo that would default from <Location /foo>. * Cleaned up the location_len handling. * Changed some of the directive description text slightly. * Fixed a bug with a patch kindly supplied by Josh Lavin. The OrdinaryFileList code was using the IC_MAX_DROPLIST configurable setting instead of its own IC_MAX_ORDINARYLIST. * Strip the location path from the request_uri string unless the location is "/". This fixes a problem with [history-scan] regex matches when using a <Location />. * Applied a patch supplied by Jonathon Sim of Zeald. Thanks Jon! The patch fixes a problem where the result code from a call to the ap_scan_script_header_err_buff() Apache API function was not being examined closely enough. This apparently caused problems with GoogleBot and caching proxies that make use of the If-Modified-Since HTTP header. * Lots of minor cleanups.
…le to route them to a separate log with: ErrorDestination <<EOF 'WARNING: POSSIBLE BAD ROBOT. %s accesses with no 30 second pause.' logs/robots.log 'Too many IDs, %d hour wait enforced.' logs/robots.log EOF
default path attempts in $ICROOT and $ICROOT/lib).