Support for old local storage entries

[bastianallgeier]

Description

The ModelView checks for old content changes in local storage and sends those to the changes API when the view is being loaded.

Summary of changes

• New panel.content.legacy module with methods to check for legacy changes, to import them and clean up local storage afterwards.
• New watch method for the api prop in the model view component to import legacy changes whenever the api endpoint changes
• The isActive is now being added to the lock object. This makes it possible to check if the lock already expired, which we need in order to decide if the changes in local storage should still be imported.

How to test?

This is pretty tricky, because a couple things have to be true for this to work. Here's the best way that I found so far:

1. Switch to the demo lab
2. Go to https://sandbox.test/panel/pages/blog+exploring-the-universe
3. Open the browser console and add some legacy changes to localStorage with this:

panel.content.legacy.simulate({ subheading: "Test"}, "/pages/blog+exploring-the-universe")

4. Create an old .lock file in /public/content/blog/exploring-the-universe/.lock with the following content:

/blog/exploring-the-universe:
  lock:
    user: test
    time: 1732545399

5. Adjust the timestamp to be not older than 10 minutes ago.
6. Reload the view

You should now see the Test subheading and active changes. The following should be true:

1. The localStorage entry is gone
2. The "Test" subheading is visible in the form and changes have been correctly stored in the _changes folder of the article
3. You should be able to see a log of what happened in the browser console.

Ready?

• In-code documentation (wherever needed)
• Unit tests for fixed bug/feature
• Tests and CI checks all pass

For review team

• Add lab and/or sandbox examples (wherever helpful)
• Add changes & docs to release notes draft in Notion

[distantnative]

@bastianallgeier What happens if there are multiple users with local storage changes? Or if one user already has made edits in the new content but an outdated legacy local storage form another user appears?

[bastianallgeier]

I've converted the PR to a draft for now while we still need to discuss the details.

The current state assumes that locking is handled properly on the backend and that those changes could not be saved if someone else locked the content in the meantime. To support the old .lock files would be a second part of the puzzle.

But to compare it with the old v4 setup, the effects should be very similar. If two editors get into a race and both make changes on their ends, the first one to store the changes wins.

The second scenario that you describe cannot happen as far as I know. Since localStorage is bound to the browser, there cannot be any unexpected changes from other users.

[distantnative]

I think we need to plan both together to make sure it really works at the end:

v4 locks have been indefinite while v5 locks are just temporary. How do we ensure the v4 behavior when we migrate the .locks to v5 locking?

Previously,our system should have prevented that two different users both create a localStorage (due to locking). But with the migration, it's easily to imagine one user starting a v5 changes version and another user coming around a day later with an old v4 localStorage.

In v4 we offered to download the localStorage if any newer changes were made by another users (e.g. via unlock). I think our migration would also need to consider if the localStorage changes are still the most recent changes and not newer changes already have been applied to the content and would be overwritten by old stuff.

[bastianallgeier]

Idea:

• As long as an old .lock file exists, our new lock class will use that to determin the lock state. We have the timestamp and the user id in there as well and can translate that quite easily into the same state that we need for our new system.
• By honouring the old .lock files, we can still make sure that new changes cannot be made in the meantime by another user.
• the localStorage import only happens when the view is not locked.

[distantnative]

I like the idea. And when the localStorage data is sent, we could then trigger the removal of the .lock file.

Worst case with that: a page is constantly blocked because that one colleague who started the lock never signs in.

[bastianallgeier]

We could either use the same timeout that we currently use for the new locks or we could have a second longer one for those older changes.

[distantnative]

But then we would have the danger again that this colleague returns after two weeks and their changes are automatically sent (as lock has expired) and overwrite all the work their colleagues made in the meantime.

So I am thinking that the .lock file triggers an indefinite lock instead and we would then need to talk to our colleague to sign in and resolve his localStorage that way first. Would be the safer way, but maybe difficult if a colleague has left the company etc.

[bastianallgeier]

We could always check whether there are changes or a latest version with a later modification timestamp. In both cases, the old content from local storage would not be applied.

[distantnative]

So to summarize (can be handled in additional PR, if preferred):

1. Lock class reads .lock files and uses them for active locked state
2. We probably need a separate endpoint (or query flag) for legacy changes
3. For legacy changes, the backend checks the modification timestamp of the Lock (from .lock) and only saves the legacy changes if that timestamp is not older than $model->version('changes')->modified()/$model->version('latest')->modified()

[bastianallgeier]

@distantnative I'm continuing more of the backend stuff over here: #6816

[afbora]

@bastianallgeier Supported multi languages? Works with single language but I couldn't achieve for multi languages env.

[bastianallgeier]

@afbora it really should. If it's not working, I have to check again.

[afbora]

@bastianallgeier It doesn't work or I can't tested correctly 🙈 I think we should make sure that.