Posted by mongolito404 on January 27, 2010 at 7:02am
| Project: | OpenSocial Shindig-Integrator |
| Version: | 6.x-2.1 |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs review |
Issue Summary
ShindigIntegratorDbFetcher does not properly load the to the Drupal database.
It includes severals Drupal files (including settings.php). The proper method is to load only bootstrap.inc from Drupal then call the drupal_bootstrap function.
The attached patch does exactly this. It also does it in the ShindigIntegratorDbFetcher::__constructor instead of at script top. There is no need to load the database on script load. Loading the Drupal database in the constructor should also allow a better error handling by Shindig (if any).
| Attachment | Size |
|---|---|
| ShindigIntegrator_bootstrap.patch | 2.85 KB |
Comments
#1
This second patch uses drupal_bootstrap to fully initialize, including all enabled modules. It then use it to offers Drupal Hooks to alter results of get methods. It also offers Hooks for data insertion methods. For these, the shindig_integrator DB is used as fallback if no hooks returned a true value.
An example use case for the results alteration is to allow a module to provides custom logic for thumbnail image. While the patch in #685182: support for user_picture_default for THUMBNAIL_URL is fine for basic use case, the site administrator may want to use ImageCache to resize, crop, add watermark to, etc. user picture when used in an opensocial gadget.
Another use case is the Address fields of the person. The patch in #673756: support for opensocial.Address field in ShindigIntegratorDbFetcher::getPeople rely on tow additional Profile fields. With this patch, hooks could be provided to set user addresses using the different existing addresses solutions (eg. Location, Postal + a href="http://drupal.org/project/content_profile">Content Profile, Addresses, etc.).
And finally, the insertion hooks could be used in addition to the alter hook to provides access to third party modules as AppData or activities (eg. store AppData in a Content Profile node).
#2
In the patch, the loop to set $this->drupal_dir doesn't work if the module realpath is not in under the Drupal dir. This is the case, for instance, when Drupal is installed with Debian package. Drupal dir is /usr/share/drupal6 but /usr/share/drupal6/sites is a symlink to /etc/drupal/6/sites. So the loop doesn't work. Ends up in '/' and rhe require_once throws a fatal error.
To fix this, the drupal_dir can be set in the generated local.php and retrieved in ShindigIntegratorDbFetcher. The
<?phpclass ShindigIntegratorDbFetcher {
//...
private function __construct()
{
global $base_url;
//Initiliaze Drupal
if(!defined(DRUPAL_BOOTSTRAP_FULL)) {
$base_url = ((isset($_SERVER['HTTPS']) && $_SERVER['HTTPS'] == 'on') ? 'https' : 'http') . '://'. $_SERVER['HTTP_HOST'];
try {
$base_path = Config::get('drupal_base_path');
if($base_path) {
$base_url .= $base_path;
}
}
catch(Exception $exc) {
//Ignore config exception for drupal_base_path
}
$dir = getcwd();
try {
$this->drupal_dir = Config::get('drupal_dir');
chdir($this->drupal_dir);
}
catch(Exception $exc) {
//Walk the directory tree to Drupal root
//This doesn't work if this file realpath is not under the Drupal root
chdir(dirname(__FILE__));
$this->drupal_dir = getcwd();
chdir('..');
while(!file_exists('cron.php') && $this->drupal_dir != getcwd()) {
$this->drupal_dir = getcwd();
chdir('..');
}
$this->drupal_dir = getcwd();
}
require_once './includes/bootstrap.inc';
drupal_bootstrap(DRUPAL_BOOTSTRAP_FULL);
//Return to original dir
chdir($dir);
}
$this->url_prefix = $base_url;
}
// ...
}
?>
The attached patch provides this fix. It also fix all db_query calls to use {} around table name.