The DO ANOTHER block contains hard-coded text and return-pages used for radio buttons which is always displayed for new entries. This change allows customized HTML to replace it for when you want to use the table editor in your own custom admin pages.
…ecs. If we are running an or search and not all of the specs have equivelant sql specs (WHERE clauses) then don't try to optimize the query as doing so will cause records to not be returned that might match other specs.
This reverts commit 8cd47ac.
* Revert behavior in the case where the return value is a hashref. * A return value of undef explicitly states that we should not process a flypage. On 08/31/2009 01:54 PM, Mike Heins wrote: > Quoting Peter (firstname.lastname@example.org): >> On 08/31/2009 12:01 PM, Mike Heins wrote: >>> Quoting Jon Jensen (email@example.com): >>>> It looks more reasonable to me than the old code, but the behavior doesn't >>>> quite look compatible. Before, $base could be assigned an arbitrary result >>>> hashref and thus could be used for a different kind of on-the-fly product, >>>> but now it seems the product code has to actually exist in a real >>>> database. >>> Good point. >>> >>>> I am not using that feature and don't object to the change, but I thought >>>> I'd point out the different behavior. >>> Now that I think about it, it was designed to handle OnFly products so the >>> change doesn't make sense. >> Ok, well that's why I asked. How about we keep the old code if the >> return is a hashref, but if it's just a text scalar which contains a sku >> then get $base from product_code_exists_ref()? > > I think that works. > >> Also just to give an explicit way to say, "don't display a flypage for >> this" a return of undef could result in the flypage being skipped as >> if the sku doesn't exist? > > Yes.
Conflicts: WHATSNEW-5.7 ... MANUALLY RESOLVED
On 09/12/2009 09:26 PM, Mike Heins wrote: > Quoting Peter (firstname.lastname@example.org): >> Incidentally why the mess of code in Util.pm to get the same result that >> %z would give anyways? > > Probably because I was stupid when I wrote it, and didn't understand what > %z did. Or I did it before %z became standard. > > It should be changed.
Do not specify a default charset if none is passed via MV_HTTP_CHARSET. Thanks to Raymond Cheng <email@example.com> for pointing out the regression caused by this.
* A null or non-numerical entry in the table(s) for the maxquantity field should result in no maximum quantity enforcement for that product. * Remove redundant code for fetching the quantity from the table(s). * Fix instance where two DB hits are used to fetch one value. * Get rid of goto. * Basically a rewrite of the correspondign block of code.
…ns, hours, days, weeks, months and years. Also can string multiple adjustments together and compensate for daylight savings time changes over the adjustment period. This sub (in Util.pm) accepts up to three arguments. The first (required) argument is the adjustment to be made and is a signed number followed by one of seconds, minutes, hours, days, weeks, months or years (these can be abbreviated). The second optional argument is a unixtime to be adjusted and defaults to the current time. If the third argument is true then the resulting time will be compensated for any daylight savings time differences. The sub uses POSIX::mktime() to do the conversions and so does not come with a new module requirement for Interchange. * _set_acl() in UserDB.pm now uses adjust_time() instead of time_to_seconds(). * [pay-cert] tag now uses the new adjust_time() function instead of the older time_to_seconds(). * [component], [convert-date] and [css] now use the new adjust_time() function instead of the older time_to_seconds(). * [convert-date] now has new compensate_dst argument that when set to 1 will compensate the adjusted time for daylight savings time changes (it basically passes 1 as the third argument to adjust_time()). * fixed bug in [convert-date] that skewed the time by one hour if the starting date was during daylight savings time and an adjustment was made. * [time] now uses adjust_time() instead of the older time_to_seconds(). There is also a new compensate_dst attribute that when set to 1 will compensate the adjusted time for daylight savings time changes (it basically passes 1 as the third argument to adjust_time()). Following are examples that help to illustrate all of the above new features. Note that many of the examples may require adjustment depending on your local time zone and locale settings: Code: <pre> Current time: [time]%c[/time] +5 hours: [time adjust="+5 hours"]%c[/time] +5 years: [time adjust="+5 years"]%c[/time] -8.3 months: [time adjust="-8.3 months"]%c[/time] +2.6 days: [time adjust="+2.6 days"]%c[/time] +7.7 months: [time adjust="+7.7 months"]%c[/time] +7 months: [time adjust="+7 months"]%c[/time] +7 months (compensate_dst): [time adjust="+7 months" compensate_dst=1]%c[/time] +5: [time adjust="+5"]%c[/time] -500 hours=1: [time adjust="-500" hours=1]%c[/time] hours=+500: [time hours=+500]%c[/time] +500: [time adjust="+500"]%c[/time] +5 years, 6 months, 3 days, -4 hours, 7 minutes (compensate_dst): [time adjust="+5 years, 6 months, 3 days, -4 hours, 7 minutes" compensate_dst=1]%c[/time] duration filter: [cgi name=start_date set=200502120800 hide=1] [cgi name=offset set="12 hours 10 mins" hide=1] 20050212201000: [filter duration.start_date.offset][/filter] 20050212200500: [filter duration.-dummy.12.hours.5.mins]200502120800[/filter] convert-date tag: 200807151600: [convert-date adjust="+6 months" format="%c"]200807151600[/convert-date] 200807151600 (compensate_dst): [convert-date adjust="+6 months" format="%c" compensate_dst=1]200807151600[/convert-date] </pre> Results: Current time: Fri May 1 05:40:47 2009 +5 hours: Fri May 1 10:40:47 2009 +5 years: Thu May 1 05:40:47 2014 -8.3 months: Fri Aug 22 22:28:47 2008 +2.6 days: Sun May 3 20:04:47 2009 +7.7 months: Tue Dec 22 21:28:46 2009 +7 months: Tue Dec 1 04:40:47 2009 +7 months (compensate_dst): Tue Dec 1 05:40:47 2009 +5: Fri May 1 10:40:47 2009 -500 hours=1: Fri Apr 10 09:40:47 2009 hours=+500: Fri May 22 01:40:47 2009 +500: Fri May 1 10:40:47 2009 +5 years, 6 months, 3 days, -4 hours, 7 minutes (compensate_dst): Tue Nov 4 01:33:47 2014 duration filter: 20050212201000: 20050212201000 20050212200500: 20050212200500 convert-date tag: 200807151600 +6 months: Thu 15 Jan 2009 03:00:00 PM PST (compensate_dst): Thu 15 Jan 2009 04:00:00 PM PST
SourcePriority <source_list> <source_list> is a prioritized list of cgi variables to get the source (affiliate) name from. Can also include the following: mv_pc - has the current special casing of mv_pc, (ie RESET is special as are values that contain only digits). cookie-foo check the cookie with the foo label. session - stop here if session already exists, do not check any further variables. session-foo - stop here if foo session variable is set. Default: SourcePriority mv_pc mv_source Examples: Check the MV_SOURCE cookie for an affiliate name as well as the other defaults: SourcePriority mv_pc mv_source cookie-MV_SOURCE ...as above, but you don't want your affiliates using mv_pc: SourcePriority mv_source cookie-MV_SOURCE Check the cgi variable affid instead: SourcePriority affid Say you send affiliate traffic to other sites, and you don't want those sites to get credit for sales if a customer follows a banner from them back to your site: SourcePriority session mv_pc mv_source If you want affiliates who use the specialsource cgi variable instead of mv_source to get special treatment and can override customers who already have sessions: SourcePriority specialsource session mv_pc mv_source If you want to allow affiliates to get credit if there is a session but only if no other affiliate is already set: SourcePriority session-source mv_pc mv_source
…able is displayed verbatim without any input sanitation if there is a valid sku in mv_sku. Thanks to Mat from Bibliopolis for discovering and reporting the vulnerability.
…terated with [PREFIX-next].
…or any tag to supress its output. In order to preserve backwards compatibility with existing individual tags' hide attributes tag output is not reparsed if this is set regardless of the setting of interpolate or reparse attributes. The reasoning behind this is existing hide=1 attributes clear the output of the tag before the output is reparsed so setting hide=1 on those tags which used to support it had the effect of not reparsing output (because there was no output left to reparse). This can be tested with the following line of ITL: [tmp bar]bar[/tmp][calcn hide=1]'foo[tmp bar][area foo][/tmp]'[/calcn]::[scratchd bar] In my testing the above line of html outputs: ::bar Without the hide=1 attribute to calcn it outputs something like (url changed to protect the guilty): foo::http://www.example.com/foo.html So hide=1 is effectively preventing reparsing as well as hiding the output.
…iple selections. Usage example: CodeDef checkbox Multiple 1 * Set new Multiple flag for checkbox, movecombo, check_nbsp and multiple widgets. * Option editor will now correctly generate variants for options that use widgets capable of multiple selections (ie, multiple or checkout widgets). * New [widget-info] UI tag: [widget-info name attribute] name: Name of widget to fetch info on, eg: checkbox, if not specified then a hashref of hashrefs will be returned with all attributes for all defined widgets. attribute: Info to get for widget, eg: Multiple. If not specified then all attributes will be returned for the named widget in a hashref.
…ixed Matrix/Simple option products.
…talog.cfg as follows: Options Matrix display_type separate * Clean up and simplify code a bit.
…area widgets by showing the actual value if a label doesn't exist for the value.
…hash values for corresponding form fields when defaults=1 and wizard=1 are both set in the table editor.
…atus of the process name indicator. This respects the MV_DOLLAR_ZERO settings.
…th RPC mode preforking too many children on server startup due to race condition.
* Added GPL and copyright headers to a few files that were missing them.
addresses the following issues: * Fixed problem where only the last shipping policy will get stored if the multi-line format is used in shipping.asc. * Fixed problem where options are not converted and stored properly on all shipping policies. * Moved more code into the new process_new_beginning sub: * By passing a ref to the @shipping array I can now push new records onto the array from inside the sub. * The above means that the old @list array need not be returned since it's only purpose at that point was to push the record onto @shipping, then immediately be overwritten by @new. * That also means that @new can be assigned to @list inside the sub instead of outside it. * Since we no longer need to return @new, this frees up the return value which I have used to return the $first value instead. * Because $first is returned we no longer need to flag that condition by assigning "_newmode" as the shipping mode. * I also removed an entire redundant elsif branch from read_shipping. The regexp that the branch tested for would never cause the branch to be executed because the branch above it tests for a regexp that matches the same lines. I don't think it's a big deal to change the process_new_beginning sub the way I did because the sub itself is only about 5 weeks old, so the likelyhood of someone having implemented code around it is extremely small.
…rror messages (#7).