Petition: Setting for the number of revisions stored in the database

I’ve just started a petition…

I was told on Slack that this didn’t really need a petition, I could have just submitted a PR. But since both writing the code for this and submitting a PR are beyond me I’ll leave it there. I also found this a little confusing as I had assumed that every change had to go through the petition process.

4 Likes

And this comment was just made on Slack…

3 Likes

Minor changes do not need a petition. See https://www.classicpress.net/democracy/#democracy-exceptions

Whether this change in particular is a minor change is debatable, it sounds straightforward but quickly grew more complicated than expected. This is not going to make it into 1.1.0, there are several questions outstanding around how this should work by default and with various existing constants applied.

In particular, @williampatton has been talking to some business users who really need this to not be an option available to users, so that their content history remains fully auditable. From that perspective, just the presence of this option would be off-putting.

More generally, there are several very good reasons to use the petitions system, for which a PR or especially a Slack discussion is not adequate:

  1. We can easily end up with a (more) incoherent mess in the admin dashboard unless we plan carefully
  2. Petitions help us weight features against each other, the upvote count is the most important feature when we are planning changes for future versions
  3. I don’t think it’s a good idea to have the agenda of ClassicPress driven by whether something gets a PR
  4. We need to be able to keep discussion about a given feature in a single place, Slack in particular is not suitable for this
3 Likes

X was speaking specifically about business clients in the financial services sector.
This is a heavily regulated sector.
Audit trails are absolutely crucial.

For other clients, database size and optimal performance may be more important.

I propose:

  • Full audit mode: All revisions are kept indefinitely.
    This is suitable for items like Terms of Service and so forth, which ought to be kept for legal reasons.
  • Limited audit mode: Only changes to each version are saved.
  • Backup: 3 previous revisions are saved.
  • None: No revisions are saved.

This gets more into plugin territory.

Although I would propose considering it as a core plugin if it is written and put through some decent testing.
It would fit in well with the CP core value proposition to business users.

3 Likes

Yeah the 2 people I spoke to about this outside of CP were from financial sector which is regulated as far as they possibly can. They were not keen on seeing the option exposed for their kinds of uses (which may be minimal in terms of the actual CP target market). Thinking about them made me realise that we need to consider both exposing the option and making the option to expose it an option of it’s own. That extra complexity makes it a bit less appealing to implement.

My own personal opinion is that I DO WANT to see this exposed for end users.

The method where it could be set on a per-post basis sounds more preferable to having it set globally for all posts and post types site-wide. The example I though up for this is that for a privacy policy page I may want revisions retained indefinitely but blogposts may be fine with just 3 revisions (or for blogposts I may not care at all). Optionally we could add a per post-type default value and allow it to be filtered so that each post-type could have it’s own default set independently.

In my mind this kind of thing would be good to start as a plugin and then we could evaluate how useful it is and if we would want to roll the features back into core. There is additional complexity in managing this all in core (especially if it’s on a post-per-post basis) but I think that could be worked in as part of the next major version bump if it was indeed deemed suitable and useful to be directly in core.

4 Likes

Given this extra complexity this is no longer a minor change

This is why we have the petitions process, the direction for v2 has already been set. In the meantime:

  • users who are comfortable editing their config file can change it there
  • there needs to be a plugin built to explore other cases
2 Likes

Totally agree. When I asked some questions in Slack I did not expect this subject to reach that level of complexity :slight_smile:

I thought about that, too. So in my PR this option becomes readonly (if already defined in wp-config). That has sense because user can at least view current setting without digging in files and code. But at the same time the option still present and may be overriden/enabled any time by those, who have direct file access (e.g. devs).


And once there is no definition in config, option simply enables itself:

4 Likes

Yes, this quickly turned into something “not simple” - definitely not for 1.1. I still think we should do it as it fits the overall direction for CP, but it needs a little more thought first.

4 Likes

OK. I understand this is way more complex than I had imagined.

I was thinking along the same lines as @norske about this. So, the setting in config would act as an override. The default is to save all revisions, and display a setting so that the user could change it. BUT if the dev puts a line in the config file, then that takes priority over everything and the defined value is simply shown as an unchangeable display to the user.

3 Likes

This plugin exists already: https://wordpress.org/plugins/wp-revisions-control/

1 Like

Hmm… yes. Thanks Joy. That does exactly what I was proposing.

I guess I’m starting to agree that this is something that should be left for individual users to enable via a plugin.

I may have to down-vote my own petition. :crazy_face:

2 Likes

Using https://wordpress.org/plugins/rvg-optimize-database/ which also offers control over revisions on all my sites, CP and WP

3 Likes