Fatal error on Uncaught Exception #291
Labels
priority: high
The issue/PR is high priority—it affects lots of customers substantially, but not critically.
type: bug
The issue is a confirmed bug.
Comments
rrennick
added
type: bug
|
Fixed in #292 |
thenbrent
added a commit
that referenced
this issue
Jul 18, 2019
Fix recurring action schedules, and in the process, refactor all schedules to avoid duplicate code and ambiguity of properties and parameters. This patch introduces to important new base classes: * ActionScheduler_Abstract_Schedule and * ActionScheduler_Abstract_RecurringSchedule These are then used to implement all other schedule types - cron, recurring/interval and simple. This helps unify the data on each schedule. For example, schedules used to have different property names referring to equivalent data. For example, ActionScheduler_IntervalSchedule::start_timestamp was the same as ActionScheduler_SimpleSchedule::timestamp. Both of these timestamps actually referring to the date the action was scheduled, but due to ambiguity in naming, like 'start' or 'date' or 'first', the data was sometimes used to refer to the scheduled date, and sometimes the first instance of a recurring schedule. While unifying the properties, their nomenclature has also been changed to avoid ambiguity. Fixes #330 and associated issues - #256, #258, #291, #293 and #296.
thenbrent
added a commit
that referenced
this issue
Jul 18, 2019
Fix recurring action schedules, and in the process, refactor all schedules to avoid duplicate code and ambiguity of properties and parameters. This patch introduces to important new base classes: * ActionScheduler_Abstract_Schedule and * ActionScheduler_Abstract_RecurringSchedule These are then used to implement all other schedule types - cron, recurring/interval and simple. This helps unify the data on each schedule. For example, schedules used to have different property names referring to equivalent data. For example, ActionScheduler_IntervalSchedule::start_timestamp was the same as ActionScheduler_SimpleSchedule::timestamp. Both of these timestamps actually referring to the date the action was scheduled, but due to ambiguity in naming, like 'start' or 'date' or 'first', the data was sometimes used to refer to the scheduled date, and sometimes the first instance of a recurring schedule. While unifying the properties, their nomenclature has also been changed to avoid ambiguity. Fixes #330 and associated issues - #256, #258, #291, #293 and #296.
thenbrent
added a commit
that referenced
this issue
Jul 18, 2019
Fix recurring action schedules, and in the process, refactor all schedules to avoid duplicate code and ambiguity of properties and parameters. This patch introduces to important new base classes: * ActionScheduler_Abstract_Schedule and * ActionScheduler_Abstract_RecurringSchedule These are then used to implement all other schedule types - cron, recurring/interval and simple. This helps unify the data on each schedule. For example, schedules used to have different property names referring to equivalent data. For example, ActionScheduler_IntervalSchedule::start_timestamp was the same as ActionScheduler_SimpleSchedule::timestamp. Both of these timestamps actually referring to the date the action was scheduled, but due to ambiguity in naming, like 'start' or 'date' or 'first', the data was sometimes used to refer to the scheduled date, and sometimes the first instance of a recurring schedule. While unifying the properties, their nomenclature has also been changed to avoid ambiguity. Fixes #330 and associated issues - #256, #258, #291, #293 and #296.
thenbrent
added a commit
that referenced
this issue
Jul 19, 2019
Fix recurring action schedules, and in the process, refactor all schedules to avoid duplicate code and ambiguity of properties and parameters. This patch introduces to important new base classes: * ActionScheduler_Abstract_Schedule and * ActionScheduler_Abstract_RecurringSchedule These are then used to implement all other schedule types - cron, recurring/interval and simple. This helps unify the data on each schedule. For example, schedules used to have different property names referring to equivalent data. For example, ActionScheduler_IntervalSchedule::start_timestamp was the same as ActionScheduler_SimpleSchedule::timestamp. Both of these timestamps actually referring to the date the action was scheduled, but due to ambiguity in naming, like 'start' or 'date' or 'first', the data was sometimes used to refer to the scheduled date, and sometimes the first instance of a recurring schedule. While unifying the properties, their nomenclature has also been changed to avoid ambiguity. Fixes #330 and associated issues - #256, #258, #291, #293 and #296.
thenbrent
added a commit
that referenced
this issue
Jul 19, 2019
Recurring schedules issues, as outlined in #330. This patch fixes recurring schedules, and in the process, refactors all schedules to avoid duplicate code and ambiguity of properties and parameters. This patch introduces to important new base classes: * ActionScheduler_Abstract_Schedule and * ActionScheduler_Abstract_RecurringSchedule These are then used to implement all other schedule types - cron, recurring/interval and simple. This helps unify the data on each schedule. For example, schedules used to have different property names referring to equivalent data. For example, ActionScheduler_IntervalSchedule::start_timestamp was the same as ActionScheduler_SimpleSchedule::timestamp. Both of these timestamps actually referring to the date the action was scheduled, but due to ambiguity in naming, like 'start' or 'date' or 'first', the data was sometimes used to refer to the scheduled date, and sometimes the first instance of a recurring schedule. While unifying the properties, their nomenclature has also been changed to avoid ambiguity. Fixes #330 and associated issues - #256, #258, #291, #293 and #296. squash! Fix recurring schedules, e.g. Cron and Interval schedules
thenbrent
added a commit
that referenced
this issue
Jul 19, 2019
Recurring schedules issues, as outlined in #330. This patch fixes recurring schedules, and in the process, refactors all schedules to avoid duplicate code and ambiguity of properties and parameters. This patch introduces to important new base classes: * ActionScheduler_Abstract_Schedule and * ActionScheduler_Abstract_RecurringSchedule These are then used to implement all other schedule types - cron, recurring/interval and simple. This helps unify the data on each schedule. For example, schedules used to have different property names referring to equivalent data. For example, ActionScheduler_IntervalSchedule::start_timestamp was the same as ActionScheduler_SimpleSchedule::timestamp. Both of these timestamps actually referring to the date the action was scheduled, but due to ambiguity in naming, like 'start' or 'date' or 'first', the data was sometimes used to refer to the scheduled date, and sometimes the first instance of a recurring schedule. While unifying the properties, their nomenclature has also been changed to avoid ambiguity. Fixes #330 and associated issues - #256, #258, #291, #293 and #296. squash! Fix recurring schedules, e.g. Cron and Interval schedules
thenbrent
added a commit
that referenced
this issue
Jul 19, 2019
Recurring schedules issues, as outlined in #330. This patch fixes recurring schedules, and in the process, refactors all schedules to avoid duplicate code and ambiguity of properties and parameters. This patch introduces to important new base classes: * ActionScheduler_Abstract_Schedule and * ActionScheduler_Abstract_RecurringSchedule These are then used to implement all other schedule types - cron, recurring/interval and simple. This helps unify the data on each schedule. For example, schedules used to have different property names referring to equivalent data. For example, ActionScheduler_IntervalSchedule::start_timestamp was the same as ActionScheduler_SimpleSchedule::timestamp. Both of these timestamps actually referring to the date the action was scheduled, but due to ambiguity in naming, like 'start' or 'date' or 'first', the data was sometimes used to refer to the scheduled date, and sometimes the first instance of a recurring schedule. While unifying the properties, their nomenclature has also been changed to avoid ambiguity. Fixes #330 and associated issues - #256, #258, #291, #293 and #296. squash! Fix recurring schedules, e.g. Cron and Interval schedules
thenbrent
added a commit
that referenced
this issue
Jul 19, 2019
Recurring schedules issues, as outlined in #330. This patch fixes recurring schedules, and in the process, refactors all schedules to avoid duplicate code and ambiguity of properties and parameters. This patch introduces to important new base classes: * ActionScheduler_Abstract_Schedule and * ActionScheduler_Abstract_RecurringSchedule These are then used to implement all other schedule types - cron, recurring/interval and simple. This helps unify the data on each schedule. For example, schedules used to have different property names referring to equivalent data. For example, ActionScheduler_IntervalSchedule::start_timestamp was the same as ActionScheduler_SimpleSchedule::timestamp. Both of these timestamps actually referring to the date the action was scheduled, but due to ambiguity in naming, like 'start' or 'date' or 'first', the data was sometimes used to refer to the scheduled date, and sometimes the first instance of a recurring schedule. While unifying the properties, their nomenclature has also been changed to avoid ambiguity. Fixes #330 and associated issues - #256, #258, #291, #293 and #296. squash! Fix recurring schedules, e.g. Cron and Interval schedules
thenbrent
added a commit
that referenced
this issue
Jul 19, 2019
Recurring schedules issues, as outlined in #330. This patch fixes recurring schedules, and in the process, refactors all schedules to avoid duplicate code and ambiguity of properties and parameters. This patch introduces to important new base classes: * ActionScheduler_Abstract_Schedule and * ActionScheduler_Abstract_RecurringSchedule These are then used to implement all other schedule types - cron, recurring/interval and simple. This helps unify the data on each schedule. For example, schedules used to have different property names referring to equivalent data. For example, ActionScheduler_IntervalSchedule::start_timestamp was the same as ActionScheduler_SimpleSchedule::timestamp. Both of these timestamps actually referring to the date the action was scheduled, but due to ambiguity in naming, like 'start' or 'date' or 'first', the data was sometimes used to refer to the scheduled date, and sometimes the first instance of a recurring schedule. While unifying the properties, their nomenclature has also been changed to avoid ambiguity. Fixes #330 and associated issues - #256, #258, #291, #293 and #296.
thenbrent
added a commit
that referenced
this issue
Jul 24, 2019
Recurring schedules issues, as outlined in #330. This patch fixes recurring schedules, and in the process, refactors all schedules to avoid duplicate code and ambiguity of properties and parameters. This patch introduces to important new base classes: * ActionScheduler_Abstract_Schedule and * ActionScheduler_Abstract_RecurringSchedule These are then used to implement all other schedule types - cron, recurring/interval and simple. This helps unify the data on each schedule. For example, schedules used to have different property names referring to equivalent data. For example, ActionScheduler_IntervalSchedule::start_timestamp was the same as ActionScheduler_SimpleSchedule::timestamp. Both of these timestamps actually referring to the date the action was scheduled, but due to ambiguity in naming, like 'start' or 'date' or 'first', the data was sometimes used to refer to the scheduled date, and sometimes the first instance of a recurring schedule. While unifying the properties, their nomenclature has also been changed to avoid ambiguity. Fixes #330 and associated issues - #256, #258, #291, #293 and #296.
thenbrent
added a commit
that referenced
this issue
Jul 24, 2019
Recurring schedules issues, as outlined in #330. This patch fixes recurring schedules, and in the process, refactors all schedules to avoid duplicate code and ambiguity of properties and parameters. This patch introduces to important new base classes: * ActionScheduler_Abstract_Schedule and * ActionScheduler_Abstract_RecurringSchedule These are then used to implement all other schedule types - cron, recurring/interval and simple. This helps unify the data on each schedule. For example, schedules used to have different property names referring to equivalent data. For example, ActionScheduler_IntervalSchedule::start_timestamp was the same as ActionScheduler_SimpleSchedule::timestamp. Both of these timestamps actually referring to the date the action was scheduled, but due to ambiguity in naming, like 'start' or 'date' or 'first', the data was sometimes used to refer to the scheduled date, and sometimes the first instance of a recurring schedule. While unifying the properties, their nomenclature has also been changed to avoid ambiguity. Fixes #330 and associated issues - #256, #258, #291, #293 and #296.
thenbrent
added a commit
that referenced
this issue
Jul 26, 2019
Recurring schedules issues, as outlined in #330. This patch fixes recurring schedules, and in the process, refactors all schedules to avoid duplicate code and ambiguity of properties and parameters. This patch introduces to important new base classes: * ActionScheduler_Abstract_Schedule and * ActionScheduler_Abstract_RecurringSchedule These are then used to implement all other schedule types - cron, recurring/interval and simple. This helps unify the data on each schedule. For example, schedules used to have different property names referring to equivalent data. For example, ActionScheduler_IntervalSchedule::start_timestamp was the same as ActionScheduler_SimpleSchedule::timestamp. Both of these timestamps actually referring to the date the action was scheduled, but due to ambiguity in naming, like 'start' or 'date' or 'first', the data was sometimes used to refer to the scheduled date, and sometimes the first instance of a recurring schedule. While unifying the properties, their nomenclature has also been changed to avoid ambiguity. Fixes #330 and associated issues - #256, #258, #291, #293 and #296.
thenbrent
added a commit
that referenced
this issue
Jul 31, 2019
Recurring schedules issues, as outlined in #330. This patch fixes recurring schedules, and in the process, refactors all schedules to avoid duplicate code and ambiguity of properties and parameters. This patch introduces to important new base classes: * ActionScheduler_Abstract_Schedule and * ActionScheduler_Abstract_RecurringSchedule These are then used to implement all other schedule types - cron, recurring/interval and simple. This helps unify the data on each schedule. For example, schedules used to have different property names referring to equivalent data. For example, ActionScheduler_IntervalSchedule::start_timestamp was the same as ActionScheduler_SimpleSchedule::timestamp. Both of these timestamps actually referring to the date the action was scheduled, but due to ambiguity in naming, like 'start' or 'date' or 'first', the data was sometimes used to refer to the scheduled date, and sometimes the first instance of a recurring schedule. While unifying the properties, their nomenclature has also been changed to avoid ambiguity. Fixes #330 and associated issues - #256, #258, #291, #293 and #296.
thenbrent
added a commit
that referenced
this issue
Jul 31, 2019
Recurring schedules issues, as outlined in #330. This patch fixes recurring schedules, and in the process, refactors all schedules to avoid duplicate code and ambiguity of properties and parameters. This patch introduces to important new base classes: * ActionScheduler_Abstract_Schedule and * ActionScheduler_Abstract_RecurringSchedule These are then used to implement all other schedule types - cron, recurring/interval and simple. This helps unify the data on each schedule. For example, schedules used to have different property names referring to equivalent data. For example, ActionScheduler_IntervalSchedule::start_timestamp was the same as ActionScheduler_SimpleSchedule::timestamp. Both of these timestamps actually referring to the date the action was scheduled, but due to ambiguity in naming, like 'start' or 'date' or 'first', the data was sometimes used to refer to the scheduled date, and sometimes the first instance of a recurring schedule. While unifying the properties, their nomenclature has also been changed to avoid ambiguity. Fixes #330 and associated issues - #256, #258, #291, #293 and #296.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
See woocommerce/woocommerce#23373
The text was updated successfully, but these errors were encountered: