provision_dns GUI should be in hosting_dns
anarcat - January 29, 2009 - 21:24
| Project: | Provision |
| Version: | 6.x-0.4-alpha1 |
| Component: | Code |
| Category: | task |
| Priority: | normal |
| Assigned: | anarcat |
| Status: | closed |
Jump to:
Description
A proper fix for #366363 would be to have the UI in hosting and the work actually done in provision.
This would require to first migrate the GUI into the hosting_dns module, then create a bridge between the two modules through proper drush hooks and actions.
#1
So I saw some code committed regarding this:
http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/hosting/dns...
... but a lot more will be required. Namely, the biggest issue is how to drive the engine from the hosting module. This can and probably must be done through drush, our prime mean of communication between the front and back end. From what I understand in the existing code, what would be required would be to get rid of the existing calls like this:
function provision_dns_zone_form_submit($form_id, $form_values) {if ($form_values['zid']) { # Update an existing zone
provision_dns_zone('update', $form_values);
} else { # Create a new zone
provision_dns_zone('add', $form_values);
}
...and transform that into tasks that would talk to drush. Then the provision_dns.api.inc needs to be extended to expose its API through drush (which is probably the hardest part). I would suggest looking at how backups or restore are configured for inspiration.
Note I have commented out a include that was broken:
#include_once(drupal_get_path('module', 'hosting_dns') . '/hosting_dns.admin.inc');Keep up the good work.
#2
I've done a second (more thorough) round of hacking on this stuff, and the commits are here:
Lots of TODO marks and other question/doc comments added in that code, in preparation for working through the final pieces over the coming days. Feedback greatly appreciated :)
#3
The frontend is now functional. The backend still needs to be reshuffled and ported to 0.3/0.4 APIs.
#4
Automatically closed -- issue fixed for 2 weeks with no activity.