I've got a Drush command that I run after copying my live db into dev that reconfigures various modules and settings that are appropriate for my development environment. For Storage API, that means marking certain containers as external.

How can I do this programatically? I guess I'm after a command like

storageapi_container_external($container_id, true);

Comments

ianthomas_uk’s picture

Project: Environment » Storage API
coreyp_1’s picture

I, too, would like to know if there is a best practice for this. Doing dev/stage/prod workflow with Storage API has turned into quite a headache that I'm not sure of a best way to solve.

Perignon’s picture

Issue summary: View changes
Status: Active » Postponed

I will be the first to tell you that doing dev->stage->test->prod is hard and nearly impossible with Storage API in some cases. The way settings have been stored in Storage API makes programmatic changes hard at the moment. This is a major feature request that I haven't even "sniffed" yet.

Basically, this module needs a lot of work to make it more developer friendly.

emmonsaz’s picture

+1 for this functionality or at least some guidance on how to use Storage API when cloning a prod site to dev/local.

Since the setting isn't in the variable table, I can't set it via settings.php, Features, Strongarm, etc. so I use our environment configuration tool to run the following command after syncing a prod database to a non-prod environment:

drush sql-query "UPDATE storage_container SET external=1 WHERE service_id='storage:s3'"

...obviously not ideal

emmonsaz’s picture

FYI: for those using https://www.drupal.org/project/habitat here's a custom module that does the same thing: https://gist.github.com/anonymous/48de54997b71cf19f107

Perignon’s picture

The problem is how the data is currently being stored in Storage API for the containers. It is a serialized array in a large VARCHAR field. So the only way to do the dev->prod will be some SQL queries, string operations, and updates.

My concern is the use of storage container credentials from Dev->prod and Prod->dev.

kaa4ever’s picture

How about a "simple" fix, like adding a global configuration "Mark all containers as external", and saving it with variable_set?

This way, you could in a specific development settings.php file, make a conf settings, like $conf['storage_api_force_external'] = TRUE;, and never have to worry about overriding production stuff again?

Perignon’s picture

That might be an option.

I am also trying to get at some code that was developed for Storage API by Mediacurrent. Weather.com uses Storage API and I had heard that Mediacurrent did some work to improve the dev->prod aspects of Storage API.

I am going to be doing some work on Storage API once I finish up my project with another module (Facebook Tracking pixels).

kaa4ever’s picture

Alright that sounds very interesting. So basically we should hold our horses, until you get back :-)

If weather.com have solved the dev->prod issue, im quite certain their solution will fit my needs..

Perignon’s picture

Yeah just hoping I can get the code. I asked about it months ago and so far have not got any news.

I been very busy with this module for five months. It is consuming all of my development time (I do Drupal stuff part time and not for a living).

Perignon’s picture

Adding a related issue. This may be a great starting point for this work.

Perignon’s picture

Perignon’s picture

I do not like the widget they use for related issues here on D.O

Perignon’s picture