Feature request: support scheduled lists

[aaslun]

Arlima currently supports schedules of individual articles and file includes. Have you considered functionality for scheduled/future publishing of entire Arlima lists? One possible scenario: an editor working on updating a list late one night and want to be able to prepare the list to be published early next morning.

Arlima is kind of prepared for this functionality by allowing to roll back the versions of lists. But one would like to be able to prepare and schedule publication of future versions of these in some way. If you are interested, we could discuss the possibilities and mutual requirements of such implementation?

[victorjonsson]

This feature have been requested before. Here's my take on how it should be implemented.

Front end

1. You make your changes to the list
2. Click on the version number down to the right in the list
3. A drop-down menu shows all the stored versions of the list. The ui shows which version that's currently open.
4. Click on "Save scheduled version" and a pop-up will be displayed with a form that you use to save current list as a scheduled version.

Something like that... would that suit your needs as well, Andreas?

Backend

Add a new database table for the scheduled versions. Use a wp event to push the scheduled version of the list over to the actual list. Keep current database structure and backend logic intact.

Downside

Wordpress scheduled events kinda sucks. This is especially noticeable when having a more complex infrastructure (several production-servers etc..)

Even if you use an ordinary cron-tab for wp-cron you can't say for sure when the scheduled version of the list will become published. It will differ with a couple of minutes everytime depending on the amount of "event listeners" that is invoked when wp-cron is called, and how long it takes for these "event listeners" to get their job done. On the other hand, a feature like this does not require an exact publish time. If you configure a version to be published at 10:00 it's okay if it actually gets published sometime between 10:00 and 10:05...

Upside

No major refactoring is required. The added logic this feature requires may fail without screwing too much with the present functionality.

[chredd]

This seems like a good feature and the suggested solution would do the job properly. +1 on this request!

[aaslun]

Victor, yes your suggested solution is very close to what I had in mind. I have some additional thoughts; should there be some kind of graphical element indicating that there are future versions of the list that are scheduled to be published? I'm concerned that there may be situations where there are multiple users working on the same list at different times and if one user creates a future version of the list, without communicating this properly to colleagues, it should be obvious by some icon/color/text in the user interface that "this list contains future versions" when the other user takes his/her seat. Also, how should the interface cope when a user wants to update an existing future list without creating a new one? And what happens in the user interface if a user is currently working on an unsaved list the exact moment a future version of the list is scheduled to publish? Should there be some kind of warning like "This list is about to be overwritten by a future list in XX minutes" or something in the interface a couple of minutes before schedule? Or should the admin page just reload to present the new list in case it a scheduled list gets published? In our case the users can have the Arlima admin page on screen for hours (maybe days) without reloading.

[victorjonsson]

That's some great thoughts! :)

Graphical element indicating a future version Maybe a small clock icon to the left of the select list would be enough? When the user hovers with the mouse over the icon a tooltip would say something like "This list has a scheduled version". I also think that we need to reload the lists that's displayed in the list manager once every fifteen minutes, as long as they're not in an unsaved state.

Editing future versions There's currently no support for updating a specific version, you can only add/remove versions. The easy solution here would be to keep the current functionality in the ui.

1. The user has a list in a default state open in the list manager
2. The user clicks on the select list and selects a future version
3. The list loads the articles of the future version and changes to an unsaved state.
4. The user makes some changes and clicks on "Save future version"
5. The user saves the current list as a future version with the same name as the version loaded on step 2 which then overwrites the old future version.

Would this be good enough? Otherwise we need to implement a new state, something like an "edit" state where we need to remember which versions that's currently open and also add methods on backend for updating versions. It's doable but it requires a lot more work.

Btw, every time you save a future version the latest published version of the list has to be loaded into the list. It would not make any sense to change back to default state and at the same time show the articles from the scheduled version.

How the UI responds when a future version gets published in the background I actually think that this won't be of much trouble if we reload all lists that's in a default state on a regular basis, once every 10-15 minutes. If a future version of a list gets published in the background while someone is editing the list the user will get notified when the list gets saved.

[aaslun]

Sounds great! :) My comments:

Graphical element indicating a future version

• Yes, a clock icon seems appropriate!

Editing future versions

• Yes, your use case scenario sounds good. I think keeping the current functionality in the ui is the way to go.
• However, when the user clicks the "+ Save scheduled version", should the user be prompted with a small form where you can set the publication time and maybe a title of the version before submitting? Otherwise, where do we collect the parameters concerning the time of schedule?

How the UI responds when a future version gets published in the background

• Good point with the automatic reload feature. It should keep the GUI up to date. Maybe the reload time parameter should be customizable as a setting?

[victorjonsson]

• Yes, a lightbox with a form where you add publish time and version name.
• Yes, the reload time would be possible to configure using a constant like define(ARLIMA_LIST_RELOAD_TIME, 600)

[victorjonsson]

I have been thinking on what's needed to make this feature possible. Here is what I suggest on backend.

Arlima_AdminAjaxManager

• Method for saving a future version
• Method for loading the articles of a future version
• Method for deleting a future version
• Method for getting all future versions of a list

New class: Arlima_VersionScheduler (... or how you want to name it)

• ... All the necessary methods for storing the versions in the db and making the above methods possible.

Arlima_ListFactory

• Add the database table to the methods createDatabaseTables() and databaseUpdates()

Arlima_Plugin

• The method adminInitHook() should create a scheduled event that takes care of publishing the scheduled versions.