I have implemented Google's Link Checker Script into my account and, although it runs without errors, it frequently flag URLs having issues but when manually checked, those URLs are working fine.
When we receive an email saying that there is an error found, we go and check the Google sheets where the scripts would log the errors and it is usually "Address not Available" . It then logs the actual URLs and the related ad groups, keywords etc.
I don't really understand why the script keeps flagging the url as not available when it is working fine.
Link to the script -> https://developers.google.com/google-ads/scripts/docs/solutions/link-checker
thanks.
The main issue here is that we wrote a custom script that will check if any url erros has occurred as a result of the link checker and, if so, we would pause the related ad groups and we do not want to be pausing adgroups without a genuine reason.
Related
I'm following this tutorial to create a simple web app with a Microsoft 365 login. I'm currently getting this error when debugging locally (http://localhost:8080):
Warning:
mgt-loader.js:61 A parser-blocking, cross site (i.e. different eTLD+1) script, https://unpkg.com/#microsoft/mgt/dist/bundle/wc/webcomponents-loader.js, is invoked via document.write. The network request for this script MAY be blocked by the browser in this or a future page load due to poor network connectivity. If blocked in this page load, it will be confirmed in a subsequent console message. See https://www.chromestatus.com/feature/5718547946799104 for more details.
In Azure, I have the Redirect URIs set up to match (http://localhost:8080).
After some googling, I tried adding async, but then I get this warning and the login button doesn't appear:
mgt-loader.js:61 Failed to execute 'write' on 'Document': It isn't possible to write into a document from an asynchronously-loaded external script unless it is explicitly opened.
What would be causing this warning and how can I fix it?
First, check out how document.write works: https://developer.mozilla.org/en-US/docs/Web/API/Document/write
You will understand why you cannot run document.write in asynchronous context (try running document.write('Hello world!'); in console on any page).
Warning tells you that a parser blocking (synchronous), cross site (not coming from the same domain as website) scripts can be blocked by Chrome in the future if someone has unstable or bad internet connection.
If you want it to run synchronously without that warning, you have to bundle that JS code with your own, or just serve it from your own origin, same as your website (e.g. localhost:8080). You can download #microsoft/mgt npm package and for bundling - use gulp, webpack or other tool of your choice.
https://unpkg.com/#microsoft/mgt#2.4.0/dist/bundle/wc/webcomponents-loader.js
This script tries to differentiate between async and sync contexts (line 175) and run document.appendChild (instead of write) for async context - but for some reason the check fails (readyState === loading).
https://developer.mozilla.org/en-US/docs/Web/API/Document/readyState
How to check if an Javascript script has been loaded Asynchronously (Async) or async attribute is present?
If you want to run this in non-blocking manner, you could try to fix the script by yourself.
There is a Github repo for that toolkit (https://www.npmjs.com/package/#microsoft/mgt), but there is no issue regarding async loading, nor regarding the warning that you have noticed - so maybe nobody else has noticed or thought about it yet.
I have an add-on that worked for years inside my domain/company until Google decided to change stuff.
I republished it and now I can run it but nobody else in the company can.
The error they receive is:
"Authorisation is required to perform that action".
I cannot pinpoint exactly where the error is because the GCP Log only tells me the function not the line, but it seems most of the times the error appears when showing a sidebar.
I do not use any kind of API, simply GAS but "just in case " I added in OAuth consent screen these scopes: .../auth/script.container.ui and .../auth/spreadsheets.
In Google Workspace Marketplace SDK OAuth Scopes I've just left the default.
Also I tried adding in appscript.json this (at top level):
"oauthScopes": [
"https://www.googleapis.com/auth/script.container.ui",
"https://www.googleapis.com/auth/script.external_request",
"https://www.googleapis.com/auth/script.scriptapp",
"https://www.googleapis.com/auth/spreadsheets",
"https://www.googleapis.com/auth/userinfo.email"
]
What else can I try ?
Update: as requested in comments here's the offending code:
// clientside
google.script.run.
withSuccessHandler()
.withFailureHandler(failureHandler) // failureHandler gets called
.aServerFunc()
//serverside
function aServerFunc(){
Logger.log('REACHED') // NO REACHED APPEARS IN CLOUD LOGS !
var docProp = PropertiesService.getDocumentProperties();
return docProp.getProperty(key)
}
So I guess the problem is nobody else but me can run google.script.run in an add-on !
Update 2:
I've removed the PropertiesService calls so it's just a blank function on the server. So it's clear that nobody but me can run google.scripts.run.
Update 3:
As required in the comments here's the procedures I did to publish the add-on:
I created a google cloud project, then configured the OAuth consentscreen (with the same scopes as appsscript.json - see above list), then in Google Workspace Marketplace SDK I've set the script ID and deployment number and the same scopes and published.
It turns out the add-on was just fine !
It's just this 4 years old bug that Google refuses to fix
If the user is logged in with multiple accounts the default one will be used.
If the default account is non-domain and the add-on is restricted to a domain the add-on will fail to authorise.
In a test, I click a link (SSL Cert) link that does not actually load the expected URL page. It hangs and as far as I can tell no issues when I look at network or console. Is there a known issue with TestCafe and clicking certain kinds of links. Clicking the same link with Selenium and Robot Framework successfully takes you to the expected URL.
This information is not sufficient to reproduce the problem. Please create a separate issue in the TestCafe Github repository using the following form
I would appreciate it if you provide us with your project or url to your site and your test code. It will help us determine the cause of the issue efficiently.
Whenever I open a Colaboratory Document I always get the same error message:
NotSupportedError: Failed to register a ServiceWorker: The user denied permission to use Service Worker.
This is happening on chrome and my browser allows for ServiceWorkers (chrome://serviceworker-internals/), what's going on? Because the thing is all the code still runs.
Colab's output frames use service workers to support some functionality such as displaying richer graphs (Altair and Plot.ly).
The error message indicates that third-party cookies are disabled in your browser, this will prevent the browser service workers from working. The option should be configured under chrome://settings/content/cookies.
I tried white-listing in chrome link (chrome://settings/content/cookies) the following:
https://[*.]googleusercontent.com:443
[*.]colab.research.google.com
Here it was the best approach, better than simply liberatin the 3rd part cookies
Seems to work so on.
Usually there are two causes for this error:
1- you didn't allow cookies on colab domain, so you need to change you browser settings
2- you are using an adblocker
When I run the examples I get a pretty picture showing the flow and I can monitor as it executes. With my application it doesn't show the diagram and if I click on "Step" it displays nothing.
Adding screenshot of Job log. No warnings or errors. BTW, I assumed the icon on the log entry with an "i" stands for Info level, but when I change the level from BASIC to ALL many more entries are added and they all have the same icon. That is confusing. Icons should be more clear and should have hover tips, IMO.
I'm on the Dataflow team. I'm sorry that you are encountering this issue.
I believe this is occurring because of the custom step names you're code is using.
From your screenshot of the job logs, it appears that some of these steps have been given names that represent a GCS storage path location.
I noticed this from this message in the logs:
Executing operation "gs://datalake/landing/...."
This fails to render in the monitoring UI and likely hits an assertion because slashes are disallowed characters.
In order to work around this issue would you please try removing the custom step names used in your code. Which seems to be set to gs:// style paths. You could also try specifying names for each step, without using special characters.
Please try running the job again after that change and see if the graph renders properly in the dataflow UI.
I have created a github issue to track this bug and prevent these slash characters from sent in the future in the dataflow SDK code.
Please let me know if you encounter any more issues.