I want to allow users to enter their own Cloudinary creds and let the API use their creds in lieu of site wide creds.
In cloudinary_sdk.module line 104 is the config return function.
I'm thinking it would be possible to add a module_invoke_all here after it gets all the config data, to alter that config data IF a user is logged in with config data in their account? This would allow users to upload their own content to Cloudinary storage and have control over their content and account limitations?
Edit: Yes, that worked fine.
So at line 119 in cloudinary_sdk.module I added:
$config = module_invoke_all('cloudinary_config_alter', $config);
Then more or less duped the config code in a separate function in a custom module.
function mymodule_cloudinary_config_alter($config) {
global $user;
if ($user->uid) {
$wrapper = entity_metadata_wrapper('user', $user);
$cloud_name = $wrapper->field_cloudinary_cloudname->value();
$api_key = $wrapper->field_cloudinary_apikey->value();
$api_secret = $wrapper->field_cloudinary_apisecret->value();
// If we have all three elements filled in, let's replace the login data.
if (!empty($cloud_name) &&
!empty($api_secret) &&
!empty($api_key)) {
$config = array(
'cloud_name' => $cloud_name,
'api_secret' => $api_secret,
'api_key' => $api_key,
);
}
}
return $config;
}
Note: I'm using the entity modules wrapper function and I've created fields for the user account via the interface.
At this point, I'll be featurizing and moving this code into the module file of my feature.
Comments
Comment #2
mcdoolz commentedComment #3
korndevbr commentedAs far as Drupal 7 reached its EOL date, I think we can close this issue.
Comment #5
korndevbr commentedIf the issue remains relevant for D10+ versions, merge requests with proposed solutions for a new module version (D10+) are welcome in a new follow-up issue.
Thanks!
Comment #6
grask0 commentedThat makes sense, thank you!