You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When I reboot the server, all pads that I have deleted with the plugin are again in the list at /admin/pads.
Is this a bug of the plugin? It happens with the plugin "adminpads2" and "adminpads3".
I have just tested it:
Created a backup of the database (A)
Used the plugin to delete about 30 pads
Created another backup of the database (B)
Result: Backup (A) contains the same pads as backup (B) inside db etherpad.
But at /admin/pads it shows only the pads that were not deleted.
Either the Postgresql db dump has an issue, or the deletion does not really delete.
I could not find the source for socket.emit('delete', padID); to check what is going on with the deletion.
Notes:
When restarting the Etherpad Docker, the deleted pads do not show up (as expected).
When restarting the Postgresql Docker, the deleted pads do not show up (ax expected).
However, when rebooting the server, the deleted pads show up again (!)
So some "data recovery" seems to happen with the server reboot?! ... and all new changes to pads are also there.
Could this have to do with the issue:
Extensions and Custom Code: If you have custom extensions or code that is run during server startup or shutdown, it could potentially cause changes. For example, if you have a script set up to run on server startup that performs some data modifications, those changes would occur during the restart.
The text was updated successfully, but these errors were encountered:
Originally posted at adminspad3: HarryBleckert/ep_adminpads3#14
When I reboot the server, all pads that I have deleted with the plugin are again in the list at
/admin/pads
.Is this a bug of the plugin? It happens with the plugin "adminpads2" and "adminpads3".
I have just tested it:
Result: Backup (A) contains the same pads as backup (B) inside db
etherpad
.But at
/admin/pads
it shows only the pads that were not deleted.Either the Postgresql db dump has an issue, or the deletion does not really delete.
I could not find the source for
socket.emit('delete', padID);
to check what is going on with the deletion.Notes:
When restarting the Etherpad Docker, the deleted pads do not show up (as expected).
When restarting the Postgresql Docker, the deleted pads do not show up (ax expected).
However, when rebooting the server, the deleted pads show up again (!)
So some "data recovery" seems to happen with the server reboot?! ... and all new changes to pads are also there.
Could this have to do with the issue:
The text was updated successfully, but these errors were encountered: