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.Scenario:
- "Event" node type with registration field
- Various Registration Types defined, overridden on production site. (Let's say "ticket type A")
- A few dozen Event node instances are assigned registration types
Procedure:
- Pull down database and code from production
- Run features-update to grab all the registration settings
- Do some work locally on some unrelated stuff (views)
- Push feature to production
- features-revert --force on production to update the view
Expected behavior:
- only the view gets updated
Observed behavior:
- the view gets updated (good)
- Event nodes which had been assigned "ticket type A" have the assignment removed; registration got disabled during the features revert.
My wild guess is that somehow in the process of removing the registration type from database to revert it, something in the content layer thought the registration type had been deleted, and removed it from the nodes it had been assigned.
Filed as support request, but may well be a bug - i haven't found any explanation yet.
Anyone have this issue before?
Any pointers would be appreciated.
| Comment | File | Size | Author |
|---|---|---|---|
| #6 | Screen Shot 2019-09-06 at 2.42.11 PM.png | 47.7 KB | mariacha1 |
| #6 | feature-revert-delete-2910305-6.patch | 6.82 KB | mariacha1 |
Comments
Comment #2
nghai CreditAttribution: nghai commentedHi @aaronbauman,
I am also facing the same issue with the module.
On features-revert-all the value for the chosen "Registration type" fields get cleared.
I didn't get enough time to go more deeper. But have found a working by excluding the created "registration entity" feature from the "features revert all" command in the deployment script.
drush features-revert-all registration_entity_feature --yes --forcewhere "registration_entity_feature" features contains only "registration entity" module configuration.
Comment #3
Fool2 CreditAttribution: Fool2 commentedThis is still an issue for me as well! It's very dangerous and frustrating... Luckily I have not tried to do this on a live site yet.
Comment #4
mariacha1 CreditAttribution: mariacha1 at ThinkShout commentedThis is still a problem. The cause is that running a feature-revert to change a Registration type works by deleting the original registration type and re-adding it. That's default features behavior, so the problem is with this module.
A workaround is to not put registration types into a feature that might need to be reverted for other reasons. I didn't say it was a good workaround :).
I'll also look into a patch.
Comment #5
Chris Matthews CreditAttribution: Chris Matthews commentedComment #6
mariacha1 CreditAttribution: mariacha1 at ThinkShout commentedHere's a patch. It adds a confirmation screen that asks if you want to delete all references to the registration type. In the example in this screenshot, the Registration type was 'Unpaid Event' so the confirmation says:
"If checked, all 3333 registrations of type Unpaid Event will be set to NULL.
If you have a large number of fields referencing Unpaid Event, this may cause a timeout. Use with caution.
Click confirm to delete the contact type Unpaid Event. This operation cannot be undone."
When doing a feature revert, the value of that checkbox is always set at FALSE, so you don't accidentally delete all references to your registration when doing the revert.
Comment #7
Fool2 CreditAttribution: Fool2 commented@mariacha1 can you explain more what's happening here? Will your patch fix the issue? Or does it just add a confirmation to prevent accidentally reverting the reg type?
It sounds like checking the checkbox and hitting confirm will just have the current behavior without patch, correct?
If you hit "Confirm" without checking the checkbox, what happens?
Comment #8
john.oltman CreditAttribution: john.oltman at SiteBasin, Inc. commented