Snippets missing from page after update to 1.1 release [#2843155]

I try to update the module using
drush up google_tag
then
drush updatedb

Then script and noscript are not included in the page.
As far as I understand the reason is that google_tag_include_file is set as 1 by default, which means javascript files should be in the 'public' directory of the site

But the function '_google_tag_snippets_save()' which saves them there, is called only admin settings form is submitted. Is it correct

So the only way to make it work is go to the settings page and hit 'Submit', correct?

Comments

Comment #1

12 January 2017 at 21:59

vdarozhkin created an issue. See original summary.

Comment #2

solotandem commented 12 January 2017 at 23:11

Are you saying you got an error after updating code base because now it looks for the JS files and they do not exist? Or, just that the snippet is not inserted because you did not save settings after update? So, then I need to call the submit routine from a hook_update_N.

Is this on an existing site where the container ID was set?

My thinking was that with the new settings available post the 1.0 release, you should always visit the settings page and save. This is comparable to a new install in which case the container ID is not set and no snippets are inserted.

Comment #3

vdarozhkin commented 12 January 2017 at 23:21

Yes, it was on existing site and google_tag_container_id was set.
The JS files don't exist. And I didn't save the settings.

So I have to save them.
Sure, I can do it. I just wanted to let you know that some users can update the module and lose its functionality.

Comment #4

solotandem commented 12 January 2017 at 23:31

Title:	Updating a module using drush	» Snippets missing from page after update to 1.1 release
Issue tags:	-google_tag, -drush

Expanding on above, with the logic change surrounding the response status condition, and the addition of settings, I am of the opinion you should be forced to revisit the settings page to have the snippets inserted. This is by design. Will change status as such pending any convincing arguments to the contrary.

Comment #5

solotandem commented 25 January 2017 at 22:17

Version:	7.x-1.1	» 7.x-1.x-dev
Assigned:	Unassigned	» solotandem
Status:	Active	» Fixed

This is fixed in 1.2-rc1 release.

Thank you for mentioning it.

Comment #6

8 February 2017 at 22:24

Status:

Fixed

» Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

Comment #7

chrowe commented 1 March 2017 at 23:53

I seem to be having this problem even after saving the form.
We are using https://www.drupal.org/project/s3fs and wondering if that would cause issues.
Will try updating the module shortly but thought I would make a note here.