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
Using the Rewrite & Republish feature with unsupported page builders or other plugins that "break" the flow of the republishing can end up in having R&R copies whose content has already been used to overwrite the originals, but they haven't been correctly deleted after the overwriting.
This is also something that might happen for a JS glitch, because at the moment the R&R copy is deleted when the browser is redirected to a certain WP action: if the redirect isn't triggered for any reason, the copy is not deleted.
Another possible scenario might happen if Elementor (or Divi, when https://yoast.atlassian.net/browse/P3-517 will be fixed) gets an update that breaks the flow.
The copy then stays in the post list with the dp-rewrite-republish status instead of draft. This is not clear to the user, who wil see the R&R copy in the list without the expected Draft marker after the title, and they might assume it has a publish status and it's visible in the front-end. This is very confusing and might lead users to think that the rewriting has not been successful.
There are a number of things that we might decide to do to address this scenario and help users to be sure about their content, and avoid resorting to the support to clean up these copies. They are not mutually exclusive and they might be implemented together to minimize the impact to the users:
we could hide the R&R copies with dp-rewrite-republish status from the post overview so they can’t be accessed. This would mean that they stay in the DB, though, with no way to delete them from the UI;
we could change the notice when editing an original having a R&R copy with dp-rewrite-republish status, reassuring that the bulk of operation has been done and that there was a minor glitch. We could also provide a link to click to manually trigger the deletion of the R&R copy. This is probably the nicest solution but might be not enough when undeleted R&R copies are the result of scheduled republishing (where the users might not be visiting the edit screen of the original anytime soon after the republishing)
we might provide a "garbage collector" in the options or somewhere else, where we warn the users of the existence of N such R&R copies and provide a button to click to delete all of them in one go
The text was updated successfully, but these errors were encountered:
Moved from: https://yoast.atlassian.net/browse/IM-1764
Reporter: @enricobattocchi
Description
Using the Rewrite & Republish feature with unsupported page builders or other plugins that "break" the flow of the republishing can end up in having R&R copies whose content has already been used to overwrite the originals, but they haven't been correctly deleted after the overwriting.
This is also something that might happen for a JS glitch, because at the moment the R&R copy is deleted when the browser is redirected to a certain WP action: if the redirect isn't triggered for any reason, the copy is not deleted.
Another possible scenario might happen if Elementor (or Divi, when https://yoast.atlassian.net/browse/P3-517 will be fixed) gets an update that breaks the flow.
The copy then stays in the post list with the
dp-rewrite-republish
status instead ofdraft
. This is not clear to the user, who wil see the R&R copy in the list without the expectedDraft
marker after the title, and they might assume it has apublish
status and it's visible in the front-end. This is very confusing and might lead users to think that the rewriting has not been successful.There are a number of things that we might decide to do to address this scenario and help users to be sure about their content, and avoid resorting to the support to clean up these copies. They are not mutually exclusive and they might be implemented together to minimize the impact to the users:
we could hide the R&R copies with
dp-rewrite-republish status
from the post overview so they can’t be accessed. This would mean that they stay in the DB, though, with no way to delete them from the UI;we could change the notice when editing an original having a R&R copy with
dp-rewrite-republish
status, reassuring that the bulk of operation has been done and that there was a minor glitch. We could also provide a link to click to manually trigger the deletion of the R&R copy. This is probably the nicest solution but might be not enough when undeleted R&R copies are the result of scheduled republishing (where the users might not be visiting the edit screen of the original anytime soon after the republishing)we might provide a "garbage collector" in the options or somewhere else, where we warn the users of the existence of N such R&R copies and provide a button to click to delete all of them in one go
The text was updated successfully, but these errors were encountered: