Suggestion: Have an 'end date'

[Ipstenu]

Current this runs until the heat death of the universe. It would be nice to have the ability to stop repeating on a date or after X times.

[noplanman]

I think this is a great idea! Saves from remembering to edit the original post when you don't want it to be repeated any more.

@willmot You ok with me starting to implement this?

[willmot]

Absolutely!

[noplanman]

@willmot I thought of changing the post meta field to an array in this format (values are just examples obviously):
array( 'schedule' => 'weekly', 'ending' => '2016-01-01 12:00:00' );
or
array( 'schedule' => 'monthly', 'ending' => '3' );

The first example would be a repeating post until the defined date.
The second one would be repeated the chosen number of times. This value would be decreased by 1 after every successful publish.

What do you think? I thought the word ending could be used for both scenarios, but maybe there is a more fitting one?

[willmot]

This looks sensible 👍 I'd probably use separate keys for the different options, maybe end_date and count?

[noplanman]

I was thinking about that too, but what if both keys are set by directly editing the post meta in the database? Which one would have the power?
My idea was to keep it simple and foolproof somehow. If there is a date, post until that date is reached; if it's a number, post and decrement until it's 0.

The other option would be to manage it by date only but offer both options on the front end.
i.e. You can either choose end_date or count and in the back end it does the calculation and only saves the date for example (or the count, whichever).

[willmot]

My idea was to keep it simple and foolproof somehow. If there is a date, post until that date is reached; if it's a number, post and decrement until it's 0.

This 👍, basically whichever one is hit first.

The other option would be to manage it by date only but offer both options on the front end.
i.e. You can either choose end_date or count and in the back end it does the calculation and only saves the date for example (or the count, whichever).

That's a pretty smart idea. Happy with either way tbh

[Ipstenu]

Whichever hits first seems sensible.

Repeat weekly 6 times, or until October 31st, 2015.

Then if I'm only 4 times by the 31st, it still stops :)

[noplanman]

@Ipstenu You're right, it seems like the better way to go.
Also makes it easier to define repeatable posts 😊

What do you think of these mockups?

selected

editing

I thought of going with the existing date selection method that WP uses, so it's a bit big, I know. Also, if one would like to only repeat the post, say 100x (without having the date as a second condition), the date would have to be set to a very late future, to make sure that the date isn't the limiting factor.

Any ideas on how to make a sensible input for this?

[noplanman]

I've given this some more thought and have come up with something like this:

This way, both options can be set and activated independently, or used together.
Adding some JavaScript to disable the inputs when the checkboxes aren't checked (enabling them when checked) will make it feel better. Also, if No is selected, the inputs aren't displayed at all.

What do you think?

[willmot]

I think this is slick. Although maybe those should be radio buttons instead of checkboxes, to make it obvious you choose one.

[noplanman]

@willmot I deliberately made them checkboxes, to incorporate what @Ipstenu suggested:

Whichever hits first seems sensible.
Repeat weekly 6 times, or until October 31st, 2015.
Then if I'm only 4 times by the 31st, it still stops :)

The other advantage of having checkboxes (when neither is checked), is to keep the initial idea of the plugin alive, to repeat posts _until the heat death of the universe_ 😉

[willmot]

I assumed that @Ipstenu was just suggested a method of solving the issue of having both set at once. We can avoid that issue in most cases by just having radio buttons. I don't think there's a legitimate use-case for having both set?