Can you expand a little more on : Step 3 - Remove revisions in the queries

[digiltd]

I have been using V1 for a little while, and wanted to give V2 a try because the ability to rollback in the panel is very cool and something I want to implement.

However when following the initially straightforward installation instructions, suddenly I am confronted with a big wall on Step 3.

Can you expand a little on why you need to remove it from your query and perhaps provide a few more hints as to what is required to do so. Is it even required at all and what happens when you don't have one?

Is the idea to filter out anything containing revisions? Does the collection filter exclude the things it matches or everything other than what it matches?

Thanks

[digiltd]

I have been doing a little more digging on collection filters.

Am I right in thinking that they are not globally applied to all queries?

Would this mean that for each template, snippet, plugin, field query or custom field that queries content would have to be altered to include the custom filterBy to ignore the revisions folder?

I am starting to come across examples of this, for instance the enchanced textarea field has a really nice modal for linking to internal pages, but is showing all the revisions.

and when using the basic panel field "page"

It would be good to know either way how the filter is supposed to work, the changes that would need to be made and if there is a performance hit.

Thanks

[jenstornell]

why you need to remove it from your query

In the meantime I'll tell you now.

$page->children();

...in your template/snippet should not in most cases be...

$page->children()->not('revisions');

That's to prevent your menu or archive to include the revisions page. But a filter might be more complicated than needed. The not should be enough.

https://getkirby.com/docs/cheatsheet/pages/not

In conclusion it's not a global solution but a solution that is applied to every query that needs to remove revisions.

I added an issue about it to try to make it easier to remove it globally but this is what I've got:

https://github.com/getkirby/kirby/issues/487

Completely excluding pages from the collections is not going to work, it will break a lot of stuff.

Write again if you have more questions about it.

[digiltd]

Thanks for the reply

I will keep an eye on the project but at the moment the level of work needed to bend the whole site to work around this "plugin" seems (for me) very complicated. I would need to customise other custom fields and plugins. Plus there would be queries that I wouldn't be able to change myself (the page field with autocomplete for example) without lots of hacking.

And there is always the risk a future update will mean I have to go around and revert everything again

I feel like I am missing something (and correct me if I am being stupid) because the response you are getting for Revisions is amazing (so don't think I am poopoo-ing your work). Perhaps I am the only one who uses autocomplete page fields :)

The first version used a single folder, which prevented the need for all the custom queries. Is that an option for a future release?

[jenstornell]

You are probably right. I only thought that it affects the queries but in fact it affects the whole system. Maybe my third version of this plugin will be a combination of the first and the second one. Own directory but still with compare and rollback.

But don't expect a new version to be release any time soon. I have other things in the pipe before that.

Thanks for the feedback!