Problems with history: e107_admin/history.php

[Alex-e107nl]

@e107help recent (last year?) there has been some changes and a admin history is added, but when you use Pages/Menus Additional and revert a change on a page you lose all the Additional info!

No hurry, it is there from the start of the history function, it was never completely done but when you place this on your todo list it would be very nice!

Being able to revert to a previous version of both news and custom pages / Menus is really important for content creators; without it, they simply skip the 107 cms and it has to work properly!

It would be even better to be able to go back directly to an item on the edit page instead of having a separate menu item in the admin!

I have tried it again, but my qwen 3.8 really has not enough context mem to oversee it all... I really don't understand why AI, as intelligent as they are, doesn't find a way to be much more efficient locally; 128GB isn't nothing, after all... :-)

[e107help[bot]]

@Alex-e107nl Copy the Additional values out of the edit form before you press Restore again, and for a page you have already restored, do not go hunting for an older history row: every row that page ever filed recorded those fields as empty, so none of them will bring the values back. A backup of the database from before the restore, or retyping them, is what is left. Filed as #6118 with the trace.

This is on current master (d5f788eaa3). release/v2.3.x has no History page at all, so a 2.3.x site is not exposed to it.

The cause, short version. The edit form nulls the page_fields column in the model so that the individual Additional inputs can carry the values, and the history snapshot is taken from that same model a moment later, on the same request. So every save of such a page files a row saying the page had no Additional fields before the edit, and restoring that row writes the emptiness back. The History list is misreporting those edits as well, which is worth knowing before you trust what it shows you.

There is a second way to lose data on the same button, and it reaches past the Additional tab. Restoring a deleted page rebuilds the row with REPLACE from a snapshot that has dropped every column the admin form does not declare a data type for. For Pages/Menus that is the whole Menu tab, so a restored deletion comes back without its menu name, title, template, button text, button link, icon or image. Both faults are in the one issue.

Your other ask, reverting from the edit screen instead of a separate admin page, is a design call rather than a defect, so that one is Deltik's rather than mine. I have kept it out of the bug report and flagged it for him here instead, so it is not sitting in the way of a fix.

I traced all of this in the code rather than running it. If your site does something different from what I have described, tell me what the screen showed and I will look again.