I still have one question:
What must be done so that it is also taken into account when updating from Joomla 4 to Joomla 5?
Or rather who takes care of it?

please review the submitted code to ensure that the copy pasted copyright and doc blocks have been updated for the submitted code

please review the xml additions to ensure that they match the codestyle of the rest of the xml file

please review the submitted code to ensure that the copy pasted copyright and doc blocks have been updated for the submitted code

before you do this, we have to talk about the concept and the usecases and if they fit the needs of us and 3rd party extensions

please review the submitted code to ensure that the copy pasted copyright and doc blocks have been updated for the submitted code

before you do this, we have to talk about the concept and the usecases and if they fit the needs of us and 3rd party extensions

in that case this is my comment to say that in its current form it should be an extension and not something for the core as in the real world this will be more of a pia than a problem solver.

it doesnt take into account if the user has authored any content or even if the user was an approved user and not a fake spam registration

it also doesn't work as it doesnt change the modified field

I would love to have such a feature because currently I struggle with lots of websites where I get the error that the user id was not found.
This can't be a core behaviour. When deleting an user the article should at least get the information that no user is assigned, but not an error "User Id Not found". It's possible now in core to assign "no user" so why is still the old user id assigned even the user is deleted?

In additioning to the previous comments:
Take a closer look at the date , version , since data if they match what is common within Joomla. Use __DEPLOY_VERSION__ if needed.

For some inspiration see #40553, there you will find good examples of the coding to be used.

Thanks for your work.

I have a 2 note about the feature.

1. The reason

The reason why people request such kind of feature is the message "user not found blabla", that is very annoying message.
The fix as easy as removing this line:

2. Not deleting user

If we stilll want to prevent user from deleting. Then we should do what is com_privacy doing: rename user data to random values. Instead of deleting and then creating new user with a loot of overhead for replacing old IDs.

We already have an API for that:

I am not a professional in programming, so this is not the "Eierlegende Wollmilchsau" (as we say in Germany).
However, if com_privacy provides that, maybe we should put the developer on it.

This feature is just to implement the function that Worpress already has for a long time.

When a user is deleted and he is used in pages or posts, a replacement user must be selected.

For Joomla just a little more elaborate, but in principle the same concept.
I could not find a process for this in Joomla, hence my PR.

However, if the feature is not needed, or does not meet the wishes of all, I hope it finds a professional who can implement it.

I have reached the limits of my abilities.
Gladly someone from the German-speaking area can get in touch, who knows all Joomla interfaces and who can take the time to make this better with me.

I would be happy, because I like to learn.

I would be very happy to have a solution for this and I am very glad you like to help in Joomla Core because you have great solutions all over the place. I think maybe a good thing would be to have a "delete user" which does not delete the user but all his personal data, and a permanent delete user which is only possible when all his data is reassigned?

I have an additional wish that if a user has been inactive for a certain period of time (for example a year), this user will automatically be anonymized and his data will be deleted.

I have an additional wish that if a user has been inactive for a certain period of time (for example a year), this user will automatically be anonymized and his data will be deleted.

Sounds great and could be maybe managed with com privacy?

....maybe managed with com privacy?

Indeed, GDPR reasons.

I have an additional wish that if a user has been inactive for a certain period of time (for example a year), this user will automatically be anonymized and his data will be deleted.

In my opinion this would be more like a scheduler plugin

In case if it helps I have prepared a list of all table columns in 5.0-dev which contain a user ID:

TABLE_NAME               COLUMN_NAME
#__action_logs           user_id
#__action_logs_users     user_id
#__banner_clients        checked_out
#__banners               checked_out
#__banners               created_by
#__banners               modified_by
#__categories            checked_out
#__categories            created_user_id
#__categories            modified_user_id
#__contact_details       checked_out
#__contact_details       created_by
#__contact_details       modified_by
#__contact_details       user_id
#__content               checked_out
#__content               created_by
#__content               modified_by
#__extensions            checked_out
#__fields                checked_out
#__fields                created_user_id
#__fields                modified_by
#__fields_groups         checked_out
#__fields_groups         created_by
#__fields_groups         modified_by
#__finder_filters        checked_out
#__finder_filters        created_by
#__finder_filters        modified_by
#__guidedtour_steps      checked_out
#__guidedtour_steps      created_by
#__guidedtour_steps      modified_by
#__guidedtours           checked_out
#__guidedtours           created_by
#__guidedtours           modified_by
#__history               editor_user_id
#__menu                  checked_out
#__messages              user_id_from
#__messages              user_id_to
#__messages_cfg          user_id
#__modules               checked_out
#__newsfeeds             checked_out
#__newsfeeds             created_by
#__newsfeeds             modified_by
#__privacy_consents      user_id
#__scheduler_tasks       checked_out
#__scheduler_tasks       created_by
#__session               userid
#__tags                  checked_out
#__tags                  created_user_id
#__tags                  modified_user_id
#__ucm_content           core_checked_out_user_id
#__ucm_content           core_created_user_id
#__ucm_content           core_modified_user_id
#__update_sites          checked_out
#__user_mfa              user_id
#__user_notes            checked_out
#__user_notes            created_user_id
#__user_notes            modified_user_id
#__user_notes            user_id
#__user_profiles         user_id
#__user_usergroup_map    user_id
#__workflow_stages       checked_out
#__workflow_transitions  checked_out
#__workflows             checked_out
#__workflows             created_by
#__workflows             modified_by

No guarantee that it's complete.

The "checked_out" might be not relevant since there should nothing be checked out by a not existing user, and if so, a global checkin should handle that.

Completely reworked.

The user plugin has been removed and introduced as a trait for the plugins in the "beforedeleteuser" plugin group. This gives the developers of third party extensions more flexibility to intervene in the exchange process themselves.

All core extensions are now combined into one "beforedelteuser" plugin.
"Modified By" is now also taken into consideration.

The global configuration of the settings has been removed, instead a popup is opened before deletion and the required settings are requested.

All adjustments could only be realized because @bembelimen gave me some good tips.

Surely there is still room for improvement, but I hope you are a bit proud of me ;-)

Please review the errors reported in the php cs by drone https://ci.joomla.org/joomla/joomla-cms/67021/1/7

@brianteeman Thx for for your effort!

I made alternative fix, please test #41048

Tested this feature and I like it very much. I am very happy to have it now. Hope it finds the way in Core. Had many sites where I had to fix this manually in the database.
Specially when migrating older sites with many contents I had this problems. Now for the future this could be solved and a great time saver.
Thank you!!!

This pull request has been automatically rebased to 5.1-dev.

I have tested it but it does not work correctly. The deleted user is still assigned to the article with the ID but does not replace it with the chosen one.

Can you finish this, so that we can test this during PBF?

@degobbis I would love the Feature in 5.1 :-)

I am closing this, we discussed this today and came to the conclusion that we want to go a different way. We think it is better to anonymise the user data instead of hard delete a user account. With this we not only fix it for com_content, also other extensions don't run into the problem of not existing user account. Essentially we do what we do in other areas and trash user accounts instead of delete. There will be an option for remove a user from the database, this will come with a warning that there can be site effects.

Thank you Guido for proposing this feature and working on this.

Too bad, I just finished the fix, including the action log.

@rdeutz Will this different way handle the Author rights (copyrights as said in PR intro)?
This PR using an Alias to preserve these rights did seem to provide a solution to that, although it didn´t seem necessary to go as far as always have a blanco user (spam regs and such.)