When deploying sites automatically (eg. using drush) you normally don't use forms to configure things. This means the google tag snippets won't be created.
Provide a drush command and/or rebuild the snippets on cache rebuild.
(reviews needed, tests to be written or run, documentation to be written, etc.)
None
A new drush command will be available
None
| Comment | File | Size | Author |
|---|---|---|---|
| #19 | warnings_when_snippets-2843994-19.patch | 3.99 KB | dakwamine |
| #16 | warnings_when_snippets-2843994-16.patch | 4.03 KB | gro |
| #12 | d8_google_tag.warnings.patch | 3.83 KB | fago |
| #11 | re_create_snippets-2843994-11.patch | 5.08 KB | geertvd |
| #10 | interdiff-2843994-10.patch | 485 bytes | cburschka |
Comments
Comment #2
casey commentedComment #3
marcelovaniI think a drush command is not the best idea for the following reasons"
1 - We have standard scripts used for deployment, it would not make sense changing the scripts just to run a command that will be used once for a given site
2 - Many people are starting to use Drupal console instead of Drush
I am in favour of having a function that we can call on hook_update or during cache rebuild.
Comment #4
marcelovaniCreated function that is be called on:
Created function that is be called on:
google_tag_save_snippets() can be called during deployment via update hooks.
Also, you can write a Drush command or Drupal console command that calls google_tag_save_snippets().
Comment #5
casey commentedAfter some thinking I am not sure whether rebuilding on every cache rebuild is the best way, but it does the job; This would solve automatic deployments (when cache rebuild is not part of a deployment process a custom drush/drupla console command would suffice).
For now I regard this as an acceptable solution. I am curious what solotandem and others think.
Comment #6
cllamas commentedWorking in my machine as well, I think this solution is acceptable until a better one is found, as at lets makes the module work with automatic deployments, which a majority of people use.
Comment #7
cllamas commentedI've found a problem when deploying a new site it can't find the public://js folder therefor it flags an error when saving the js snippet files.
Working in a solution
Comment #8
dmsmidtHere is a patch that fixes the problem mentioned in #7.
And it allows people to disable recreating the snippets.
This can be done via the UI or in settings.php.
Comment #9
cburschkaThe newly added rebuild_snippets setting needs to be declared in the schema as well.
Otherwise, this patch works.
Comment #10
cburschkaComment #11
geertvd commentedReroll
Comment #12
fagoI ran into a related issue on a site, where the module was installed via configuration sync. The files were missing, what lead to some empty page attachment being added to the site, consequently leading to quite ugly warnings and an empty tag being shown every page.
While it would be possible to create the files during a config sync, this would not work for cases where you installed the site from a dump or the files are missing for some other reason. That said, I think they should be just re-created when needed just as the aggregated js files. This solves the issue while making the command and cache-rebuild features unnecessary - it just works. That seems better, not? :)
Attached patch solves the problem for me and works if files are suddenly missing.
Comment #14
solotandem commentedThanks to all for the input.
Comment #15
gro commentedRe-rolled #12 for latest 8.x-dev (commit 09ce10cf)
Comment #16
gro commentedFixes patch from https://www.drupal.org/node/2843994#comment-12135228 by removing duplicate declaration of hook_rebuild.
Comment #17
gro commentedComment #19
dakwamineUsing the #16 patch, I had a 404 on the generated files because the module points on /sites/[site_name]/files/google_tag/[generated_files] but the patch creates the files at /sites/[site_name]/files/js/[generated_files].
I have added a patch with the paths which worked for me.