We work within multiple Drupal dev/staging/production environments in which we sync the dev and staging databases to prod quite often. This brings up an issue where the Optimizely ID number that's set on prod can be back-ported to these other environments, messing with test results. Would you be open to a drush command that would set the ID? This would allow us to throw it into the shell file that we run for sync'ing environments. I'd be willing to take a crack at the code for such.

CommentFileSizeAuthor
#8 optimizely-drush-2569691-8.patch3.4 KBSeeWatson

Comments

SeeWatson created an issue. See original summary.

DeeZone’s picture

DeeZone commented

Sounds great, a patch for review would be fantastic.

SeeWatson’s picture

SeeWatson commented

I see two approaches:

  1. Take the variable setting and DB update out of optimizely_account_settings_form_submit, creating a new function _optimizely_update_oid that is called from the form_submit and drush
  2. Copy the variable setting and DB update over from optimizely_account_settings_form_submit to a new function only used by Drush

Thoughts? The first seems more sustainable long term, but the second would be more isolated in its changes.

DeeZone’s picture

DeeZone commented

I vote for #1, nobody wants DRY in the code :)

DeeZone’s picture

DeeZone commented
Assigned: Unassigned » DeeZone
DeeZone’s picture

DeeZone commented

@SeeWatson Do you plan to submit a patch to add the Drush functionality you're requesting? Otherwise I can add it to the 2.18 maintenance release.

SeeWatson’s picture

SeeWatson commented

Yeah, I'm finishing it up now. I'll post it by tomorrow.

SeeWatson’s picture

SeeWatson commented
StatusFileSize
new optimizely-drush-2569691-8.patch3.4 KB

Patch attached.

SeeWatson’s picture

SeeWatson commented
Status: Active » Needs review
DeeZone’s picture

DeeZone commented
Status: Needs review » Patch (to be ported)
DeeZone’s picture

DeeZone commented

@SeeWatcon, looking at optimizely_set_id() in your patch.

What are your use cases? The few that I can think of are:
- set Optimizely ID via Drush when the default project is not enabled. This would require manually enabling the default project via the admin UI. I'm not sure there's value in this considering the need for the manual step.
- set Optimizely ID via Drush when the default project is enabled. This would require clearing a cache_clear_all('*', 'cache_page', TRUE) to apply the change to the site.

Would there be value in a Drush command that enabled/ disables projects by Optimizely project ID? In the case of an initial project this would be the first oid entry but could also support additional project IDs enabled/ disable as well as updating the actual ID?

I've added you patch changes to the dev branch of 7.x-3.x. Depending on your response above I might adjust / expand before releasing.

Thanks for your contribution. Looking forward to your thoughts.

DeeZone’s picture

DeeZone commented
Status: Patch (to be ported) » Needs work
DeeZone’s picture

DeeZone commented
Version: 7.x-2.17 » 7.x-3.x-dev
SeeWatson’s picture

SeeWatson commented

Our use case is that we are using Optimizely across dev/staging/production environments and want to be able to swap out the Optimizely project ID for one targeting the environment as we're building the fresh environment. As we're back-syncing the database from prod, the default project will always be enabled with the prod ID, and so we're just looking to swap that ID out. For us, as the environments are built out using a shell file, it would be really helpful to be able to swap that default ID via a Drush terminal command.

I don't ever see us using any custom projects beyond the default as we're using a single project ID across the site, so the ability to enable a project by ID wouldn't be particularly helpful for me in particular. I suppose we could have one project set up for each environment and then disable/enable the one we wanted, but it seems to me that swapping the default ID would be a more efficient solution for that.

I could potentially see an enable/disable by ID being helpful to someone running a domain access multisite setup with different project IDs or for a large organization with different projects with different users or something similar, but I don't think it's core functionality.

DeeZone’s picture

DeeZone commented
Status: Needs work » Needs review