I'm in charge of a website developped with symfony. This website is in prod.
I would like to know how to reinstall the front-end console, because im completely blinded in my task.
I suspect you're talking about the "Web Debug Toolbar":
You can control the visibility of the Web Debug Toolbar in the settings.yml. Set the web_debug parameter to true for the environment you're using. After clearing the cache with symfony cc the toolbar should be visible.
But be warned: enabling the toolbar, will make this visible to all visitors! You probably don't want this!
So depending on your problem I'd first go for enabling logging in production, and analyze the logfiles. If that doesn't solve your issue, copy the frontend_dev.php file to your production server, update it's IP to match your own, and set the environment to test. Next, set the web_debug property in test to true. Clear the cache, and navigate to this scriptfile. This way you can test, while normal users can't access the debug bar.
Related
I have received for maintenance a rather primitive react app hosted on firebase (developed by someone else). Now weird things are happening:
I change content of a file (even simple text change)
Run deploy (hosting) - I see in firebase console that deploy was successful
Still: page content is still old, without changes!
How can it be? I use Chrome incognito mode to ensure no cache on browser side, and Firebase docs say that deployment clear server cache.
Turns out it is about cache setttings of firebase. I've seen people wrote default it is about one hour (sic!) so I overridden the cache header settings as referenced and now it is immediately visible after publishing.
https://firebase.google.com/docs/hosting/manage-cache
I wonder if it is possible to automatically show the GTM debug bar when loading GTM with a specific environment and/or other GTM variable?
I have set up a new environment in GTM to be used for dev/testing purposes. When setting up this environment there is a checkbox with the option to "Turn on debugging when previewing". I first thought that this did just this, but no debug bar appears by default even though I checked it and is loading GTM with the code that the environment applies. What does this do then?
I actually can get what I want, sort of, by adding the parameter gtm_debug=x to the implementation code, however this feels hacky maybe, and also causes the console to log a weird 400 error to GTM:s api domain, which doesn't feel so good...
Does anyone know how I can achieve this?
I've came across a similar (or maybe even the same) problem. I've wanted to enable the QA team to access/show the GTM debug toolbar (i.e. enable/disable it) on their behalf and without going into tag manager.
This is the solution I came up with:
https://www.googletagmanager.com/set_cookie?uiv2
&id=GTM-XXXXXXX
>m_debug=x
>m_auth=AUTH
>m_preview=env-0
&url=https%3A%2F%2Fwww.example.com%2F
(enable debug)
where "GTM-XXXXXXX" has to be replaced with your container ID and "url" is an optional parameter.
This URL sets the necessary cookies to switch GTM into debug mode and also provides a link to leave debug mode again ("Exit preview and debug mode").
https://www.googletagmanager.com/set_cookie?uiv2
&id=GTM-XXXXXXX
>m_auth=
>m_preview=
>m_debug=
(leave preview and debug mode, i.e. remove cookie)
The values for "gtm_auth" and "gtm_preview" are different per container/environment and you can find them via "Get Snippet" from the "Actions" menu of each environment on the "Environments" view ("Admin" -> "Environments"). You can also get them for the two default environments, i.e. "Live".
When setting up this environment there is a checkbox with the option
to "Turn on debugging when previewing". I first thought that this did
just this, but no debug bar appears by default even though I checked
it and is loading GTM with the code that the environment applies.
What does this do then?
"Turn on debugging when previewing" is from the "Share preview" screen. On the "Environment Configuration" screen, it says "Enable Debugging by Default" and also Google's documentation suggests what you (and me) expect:
Optional: Check Enable Debugging by Default if you need the environment to always use preview mode.
But it doesn't work for me neither. :(
The preview & debug mode relies on 3rd party cookies (i.e. cookies on www.googletagmanager.com and even if the checkbox is checked they are not set. The missing cookies are also the reason for the 400 error you were mentioning.
all!
I need to disable the "Analyze Application" button in Nexus' component view before this software is ready for our production systems. For various reasons, we can't allow that function to work on production servers.
Is there a convenient way to disable it that I am missing? I've perused the user manual and the function is only even mentioned once. Additionally, there is no configuration option to disable it. I even went so far as to pull a network traffic report and run it through Wireshark to try to find an IP/Port to block, but no such luck.
If anyone has experience disabling this function I would greatly appreciate any guidance that can be offered.
I contacted Sonatype. There is no application setting to disable this functionality. What you can do is add clm.sonatype.com to your hosts file on whatever machine is hosting Nexus. The functionality will still appear operational on the front end, but a quick look at nexus.log will reveal that it is unable to resolve the hostname and throws a stack trace to the log instead.
Also, they opened a JIRA request for the functionality and marked it as high, so this may become an option in the future.
It's me again,
I just found out that Reload module became active and there is no way to turn it off. Its nowhere in module lists and so on. Is this some kind of new implementation, because it's not fair to enforce me using a module which I don't want to use.
Also I'm on 2nd type paid account and it costs me dearly for the services I get.
Please respond because I'm loosing precious time because of your fault.
Regards,
Ivan Popjelev
you can disable Reload by unchecking the core.general.reload checkbox in the App config section in your Toolkit.
Or, you can edit the config.json file to set reload: false if you prefer.
If you've migrated an app across from v1.4 to v2.0.0, we respect the Reload setting in the original app: we don't automatically enable Reload during the migration or anything like that.
This is a new one for me. I upgraded a Drupal site from 6.20 to 6.22. After the core upgrade, the block visibility settings are all goofed up. Quite a few that were enabled prior to the upgrade are now disabled. Additionally, the "Page specific visibility settings" are missing for those blocks.
One other clue in this mystery is that, on the main block admin page (/admin/build/block), my three active themes are in a different order. I'm not sure whether that's related, but I've never seen it before.
I do upgrades on a staging server, so my production site is still intact. For now, I'm going to restore the blocks, comparing the prod with staging settings. I'll see if that restores it to fully functional. Regardless, it makes me nervous. I saw no errors or warning during upgrade.
FYI, my general order for doing the upgrade was:
Empty staging site files and dbase.
Take production site offline.
Copy entire prod site to staging.
Dump prod dbase, restore to staging dbase.
Disable all non-core modules. Switch to core theme (Garland).
Upload and expand drupal-6.22.
Move 'sites' directory from old to new.
Run /update.php.
Enable necessary non-core modules.
Run /update.php.
Switch back to custom theme.
Bam, lots of blocks disabled.
This is a bug. See http://drupal.org/node/1173012