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
{{ message }}
Repository navigation
cPanel: renaming an account's main domain loses the zone on the secondary #87
WHM's Modify an Account can change an account's main domain, and that fires Whostmgr::Accounts::Modify, which we do not listen to. The old zone goes away on the panel and the new one is never announced — so the zone disappears from the secondary permanently, with nothing in /var/log/seconddns.log to say so.
This is the same defect that was found and fixed for DirectAdmin in #78: the panel fires no DNS create event on a rename, only the deletion of the old name plus a rename event of its own.
CyberPanel is not affected — it has no rename operation at all.
What a fix needs
register Whostmgr::Accounts::Modify (stage post)
from its payload, queue the removal of the old domain and the creation of the new one, the way hosting-panels/directadmin/domain_change_post.sh does
a test with a stand-in queue asserting both operations and their order, matching tests/test_domain_change_hook.sh
Why this is filed rather than fixed
There is no cPanel server to verify on: the trial is unavailable on the test IP (a previous holder used it) and no licence has been bought. Writing the hook from documentation alone would give code with tests but no live evidence — unlike the DirectAdmin fix, where every step was watched on a real server. Holding until a cPanel box exists.
Until then the cPanel integration carries Status: Beta in its README and in the panel table.
Fixed in #91, merged into develop. GitHub did not close it automatically because Closes only fires on a merge into the default branch.
Confirmed on a live cPanel 136 server, which is what this issue was waiting for. WHM sends only the new name on both stages of Whostmgr::Accounts::Modify:
pre domain=my999domain.com user=my123domain
post domain=my999domain.com user=my123domain
so the hook runs at pre, takes the old main domain from the account's userdata while it is still on disk, and pairs it with the new one from the payload — the same approach cPanel's own ChangeDomains framework uses.
One thing the issue did not anticipate: WHM fires this event on every account change — quota, package, contact address — so the hook queues nothing unless the two names differ. A mutation removing that comparison fails the test.
Four other defects turned up on the same server while getting here, each of which made the cPanel integration non-functional on its own: #88, #89, #90.
Activity
0kaba0 commentedon Sep 6, 2026
Fixed in #91, merged into
develop. GitHub did not close it automatically becauseClosesonly fires on a merge into the default branch.Confirmed on a live cPanel 136 server, which is what this issue was waiting for. WHM sends only the new name on both stages of
Whostmgr::Accounts::Modify:so the hook runs at
pre, takes the old main domain from the account's userdata while it is still on disk, and pairs it with the new one from the payload — the same approach cPanel's ownChangeDomainsframework uses.One thing the issue did not anticipate: WHM fires this event on every account change — quota, package, contact address — so the hook queues nothing unless the two names differ. A mutation removing that comparison fails the test.
Four other defects turned up on the same server while getting here, each of which made the cPanel integration non-functional on its own: #88, #89, #90.