No. Not crud. CRUD. Create, Read, Update, Delete. The basic operations a web app needs to do on database records.
I’ve been working on the Provisionator module, which helps with institutional-scale deployments of Drupal sites on a shared hosting server. The module began life as a separate PHP application, and evolved into a Drupal module wrapping those functions. It essentially managed a table within a Drupal site’s database, adding rows for each website deployed.
I was just working on adding the rest of the CRUD support (it already handled Create and Read OK, but not Update (edit) nor Delete). I was looking for The Drupal Way™ when it hit me. I don’t know why I didn’t see it before.
I don’t need to manage a table, nor do I need to manually implement CRUD operations.
All I need to do is define a custom content/node type, and let Drupal take care of the basic CRUD operations. The Provisionator module will then simply implement relevant bits of the node API and have it get called when nodes of the appropriate type are inserted, edited, or deleted. I can add whatever “fields” I want as properties of the custom node type, so it should be easier to extend than the current hard-coded table.
I’m going to attempt converting to the Drupal node + hooks + node API pattern ASAP. I think it’s going to be relatively straightforward, and offers some pretty cool benefits. Instead of having an essentially static list of sites in a custom database table, I’ll be able to add sites (as nodes) to various taxonomies, enable comments on the site node, and easily implement various permissions (user can create sites, user can list sites, user can edit all sites, user can edit own sites, user can delete all sites, user can delete own sites, etc…)
No. Not crud. CRUD. Create, Read, Update, Delete. The basic operations a web app needs to do on database records.
I’ve been working on the Provisionator module, which helps with institutional-scale deployments of Drupal sites on a shared hosting server. The module began life as a separate PHP application, and evolved into a Drupal module wrapping those functions. It essentially managed a table within a Drupal site’s database, adding rows for each website deployed.
I was just working on adding the rest of the CRUD support (it already handled Create and Read OK, but not Update (edit) nor Delete). I was looking for The Drupal Way™ when it hit me. I don’t know why I didn’t see it before.
I don’t need to manage a table, nor do I need to manually implement CRUD operations.
All I need to do is define a custom content/node type, and let Drupal take care of the basic CRUD operations. The Provisionator module will then simply implement relevant bits of the node API and have it get called when nodes of the appropriate type are inserted, edited, or deleted. I can add whatever “fields” I want as properties of the custom node type, so it should be easier to extend than the current hard-coded table.
I’m going to attempt converting to the Drupal node + hooks + node API pattern ASAP. I think it’s going to be relatively straightforward, and offers some pretty cool benefits. Instead of having an essentially static list of sites in a custom database table, I’ll be able to add sites (as nodes) to various taxonomies, enable comments on the site node, and easily implement various permissions (user can create sites, user can list sites, user can edit all sites, user can edit own sites, user can delete all sites, user can delete own sites, etc…)
I've just moved the Provisionator module onto Drupal.org's CVS server. The current version of the module is far from complete, but it does function. Specifically, it does:
- create database for new site
- populate database with selected mysqldump template file
- copy template site directory (with settings.php, files, modules, themes)
- modify settings.php as needed
- create symlink to expose Drupal via Apache for the new site (as a subdirectory of a server, currently)
- add a new record to the database, describing the site
- list all records in the Provisionator database table
It's got a lot of room for improvement, and more than likely needs some tightening down for security and Doing It The Right Way, but it works. It also currently assumes MySQL, and a very specific shared hosting pattern where Drupal isn't in wwwroot itself, but is exposed by adding multiple symlinks within the wwwroot directory.
I'm having difficulty creating the actual Project on Drupal.org – I get an Access Denied error. So, until that's resolved, it's available via CVS at least. Once the Project is created, there will be an issue tracker, etc…
Oh, and don't laugh too hard at the code. I know most/all of it could be done cleaner/better/faster, but I'm cobbling it together as I learn. Also, I'll be working on better documentation so others can use the module or contribute code.
PS. Man, does CVS suck! I’ve been using SVN for source code management for over a year. Feels like being dropped back in MS-DOS or something now that I’m using CVS again. Ick. Hopefully, Drupal.org will migrate to SVN sometime soon?
Update: The permissions issue on my Drupal.org account has been cleared up, so Provisionator.module is now on the air!
I've just moved the Provisionator module onto Drupal.org's CVS server. The current version of the module is far from complete, but it does function. Specifically, it does:
- create database for new site
- populate database with selected mysqldump template file
- copy template site directory (with settings.php, files, modules, themes)
- modify settings.php as needed
- create symlink to expose Drupal via Apache for the new site (as a subdirectory of a server, currently)
- add a new record to the database, describing the site
- list all records in the Provisionator database table
It's got a lot of room for improvement, and more than likely needs some tightening down for security and Doing It The Right Way, but it works. It also currently assumes MySQL, and a very specific shared hosting pattern where Drupal isn't in wwwroot itself, but is exposed by adding multiple symlinks within the wwwroot directory.
I'm having difficulty creating the actual Project on Drupal.org – I get an Access Denied error. So, until that's resolved, it's available via CVS at least. Once the Project is created, there will be an issue tracker, etc…
Oh, and don't laugh too hard at the code. I know most/all of it could be done cleaner/better/faster, but I'm cobbling it together as I learn. Also, I'll be working on better documentation so others can use the module or contribute code.
PS. Man, does CVS suck! I’ve been using SVN for source code management for over a year. Feels like being dropped back in MS-DOS or something now that I’m using CVS again. Ick. Hopefully, Drupal.org will migrate to SVN sometime soon?
Update: The permissions issue on my Drupal.org account has been cleared up, so Provisionator.module is now on the air!
I've been involved with a shared Drupal hosting project with BCIT and BCCampus. Part of it is based on an easy way to create new Drupal sites via a web interface, complete with database creation and population, Drupal site directory creation and settings modification, symlink creation to make the site visible to Apache, and management of a Drupal Sites Manifest table to keep track of sites.
At first blush, it seems rather similar to both sympal_scripts and the Drupal 5 installer, except for the management of a sites manifest table, and creation of the symlink to expose the site to Apache in a shared setting.
I'm investigating ways to better integrate with either/both of those, but in the meantime, I've got a working Drupal module that will do the whole shooting match. Not everything is fully implemented yet, but I've got the various bits working as a Drupal module, and most of it working as a standalone PHP application.
Currently, it reads available database profile templates from a directory of .sql files created via mysqldump. It creates a new database on demand, and populates it with the contents of the specified profile.
Future versions will let you customize the admin user/pass, and create an additional user/pass at install time. I also need to add site decommissioning (freeze-dry to static html, delete database and site config directory, etc…)
Writing this module has been an interesting exercise in learning the Drupal forms API and module programming in general. I've had a few false starts on both fronts, but think I finally grokked it this time. This is the only real code I’ve written in something like 6 months. Yikes.
Provisionator (alpha)
Update: We’ve committed to sharing this openly, so I’ll be cleaning it up a bit and setting up a project on Drupal.org so others can play with it if they like. I’ll likely wait until after the Drupal.org project reorganization though.
I've been involved with a shared Drupal hosting project with BCIT and BCCampus. Part of it is based on an easy way to create new Drupal sites via a web interface, complete with database creation and population, Drupal site directory creation and settings modification, symlink creation to make the site visible to Apache, and management of a Drupal Sites Manifest table to keep track of sites.
At first blush, it seems rather similar to both sympal_scripts and the Drupal 5 installer, except for the management of a sites manifest table, and creation of the symlink to expose the site to Apache in a shared setting.
I'm investigating ways to better integrate with either/both of those, but in the meantime, I've got a working Drupal module that will do the whole shooting match. Not everything is fully implemented yet, but I've got the various bits working as a Drupal module, and most of it working as a standalone PHP application.
Currently, it reads available database profile templates from a directory of .sql files created via mysqldump. It creates a new database on demand, and populates it with the contents of the specified profile.
Future versions will let you customize the admin user/pass, and create an additional user/pass at install time. I also need to add site decommissioning (freeze-dry to static html, delete database and site config directory, etc…)
Writing this module has been an interesting exercise in learning the Drupal forms API and module programming in general. I've had a few false starts on both fronts, but think I finally grokked it this time. This is the only real code I’ve written in something like 6 months. Yikes.
Provisionator (alpha)
Update: We’ve committed to sharing this openly, so I’ll be cleaning it up a bit and setting up a project on Drupal.org so others can play with it if they like. I’ll likely wait until after the Drupal.org project reorganization though.