Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Inform the user that the old field may now be deleted after updating all views, entity references etc. using the field
And of course think about all possible conflicts. Perhaps it makes sense to have a whitelist of supported field types where we can be safe it works.
I have the interest but not the time, but I think it's solvable this way and would still be VERY useful.
@gisle perhaps this issue should therefor be reopened and linked on the module page for any interested developer?
Perhaps we can revive this great module for the future :)
I am not going to reopen this. The situation has not changed since it was closed.
If someone is willing to commit to porting this to Drupal 9, they should open a new issue for the explicit task of doing so. I'll probably give them co-maintainership if I'm convinced about their ability and sincerity. But it would be pointless to have a new issue that is a duplicate of this to ask what plans there exist for porting. For the record: There are none.
However, I shall link to this closed issue from the project page, so that it will be easy to find for those that want to learn why there are no porting plans for this project.
Comments
Comment #2
Jitujain CreditAttribution: Jitujain at Innoraft commentedComment #3
Jitujain CreditAttribution: Jitujain at Innoraft commentedComment #4
RobertoGuzman CreditAttribution: RobertoGuzman commentedany update ?
Comment #5
MrPaulDriver CreditAttribution: MrPaulDriver commentedThis is a very useful module and it would be great to see a D8 version.
Comment #6
colanThe D8 port could probably do something like what's suggested in the selected answer for How to rename a field in Drupal 8?.
Comment #7
AnybodyThere's definitely demand for such an entity / bundle aware solution in Drupal 8!
Comment #8
gisleThis will not be done by me. Will accept a well-written port, tho. Updated project page with tip from #6.
Comment #9
AnybodyShould anyone come to this point (2nd time for me) and have the time and interest, I think it should be implemented the following:
And of course think about all possible conflicts. Perhaps it makes sense to have a whitelist of supported field types where we can be safe it works.
I have the interest but not the time, but I think it's solvable this way and would still be VERY useful.
@gisle perhaps this issue should therefor be reopened and linked on the module page for any interested developer?
Perhaps we can revive this great module for the future :)
Comment #10
gisleI am not going to reopen this. The situation has not changed since it was closed.
If someone is willing to commit to porting this to Drupal 9, they should open a new issue for the explicit task of doing so. I'll probably give them co-maintainership if I'm convinced about their ability and sincerity. But it would be pointless to have a new issue that is a duplicate of this to ask what plans there exist for porting. For the record: There are none.
However, I shall link to this closed issue from the project page, so that it will be easy to find for those that want to learn why there are no porting plans for this project.
Comment #11
AnybodyThanks @gisle :) Very much appreciate your immediate feedback!