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
Related
I'm hosting a web app with Firebase hosting service.
I build my app and then deploy it using firebase command tools.
The build is successful and the firebase domain shows the update:
https://calmeet-a7271.firebaseapp.com/e/-KsC5suhESWNwzYw6rtq
But the connected domain doesn't show the update:
https://calmeet.co
You can see the difference in these two links by the Settings (cog) button on the top right. https://calmeet-a7271.firebaseapp.com/e/-KsC5suhESWNwzYw6rtq has the settings button while https://calmeet.co does not
I'm not sure what I'm doing wrong, I thought this would be automatic.
DNS seem to be working alright. I don't see any error in firebase
I had this same issue. It was caused by doing back to back ng-build and firebase deploy commands in the terminal.
Turns out chrome was caching my connected site. If I opened it in a different browser (safari) it would update. Another way to fix it in chrome is to clear recent browsing data by going to your browser toolbar, clicking More and then More Tools and then Clear Browsing Data.
Short answer, Clear caching browse and try again or open another browser.
Hope this help.
Just do a hard refresh (cmd + shift + r) on your website on Chrome. That worked for me.
I just created a firebase project. And the database in the console appears empty. On previous projects, when you clicked on the empty white area, you were able to create database items by hand.
But clicking it doesn't do anything.
The rules tab is loading indefinitely, and i can't type anything.
I'm on Chrome last version, do you encounter such problems by creating new projects?
Here are some screenshots:
Ok, quick answer to my own question as i wasn't able, from my Angular2 App, to interact with database as well via websocket.
I'm working in a company with a (strong) proxy setup file. Disabled it on windows settings and all works now perfectly. Firebase website appears to rely on websockets.
Hope this information can be useful to someone else!
I am getting this weird error while setting up my cloud backend
when i deployed my app, the url Http://"app-id".appspot.com
is landing on this page
but the url http://1-dot-"app-id".appspot.com is lannding on the right page
everything else works and its not a welcome-file issue.
then in the developer console i tried to set the default version and it gives me a error.
They say its a temporary problem but i have tried this for 2 days...
Any suggestions ?
Found the solution after 3 days of googling and digging in settings.
This also works if your app engine project dosent have a default bucket.
go to the old developer console https://appengine.google.com/
goto main > versions and set the default version here.
the newer console didn't work for me !
Also,
goto application settings
scroll down completely till you see the title "Cloud intigration"
it reads: "Create a Google Cloud project as well as a Google Cloud Storage bucket and a new style service account for this application"
click create.
This option is not there in the newer console.
Let me explain a little bit:
I'm currently using a CDN to push reloads, due to some issues I've had with Trigger's reload infrastructure. For some reason, the latest reloads I'm pushing don't seem to be getting through to the app.
I don't 100% understand how the reloads work (I suspect they go by some kind of queue in the order you push reloads), but my suspicion is that it's because one of the reloads in the queue got overwritten or deleted from my CDN, so the .apk (it's an Android app) is looking for an update that no longer exists on the server, and isn't skipping ahead to future updates.
Anyway, the question is: can I wipe the slate clean somehow, so that the apps stop looking for that reload?
Or, is there a way to force all apps to get the latest pushed reload? I know the reloads only work with changed files, but is there a way to say "this is the latest official version" and force apps to reload to that one?
UPDATE: I think it might have something to do with the active configuration I'm pushing to. Is there any way to determine which config ID (i.e. the one that most users are using) in the Reload panel matches up to which reload or manifest file I have on my CDN, so I know which version those users are on?
First, a little background: when a device checks for a Reload update, it contacts the Trigger.io server to find out what the most recent applicable Reload update is, and where it is stored.
In your case, that will point the device towards a manifest file stored in your CDN, and the files referenced from it will be downloaded and swapped in.
So, the apps will automatically pick up the latest pushed Reload. If a Reload update is deleted or corrupted in the CDN, we still go back to the Trigger.io server so fixing the problem is just a case of re-pushing a newer Reload update.
There's no "out-of-the-box" way to connect which manifest files correspond to which config ID. One approach would be to install the app built from the relevant config ID, and let the Reload update occur. If you look at the debug log output as that Reload is happening, you can see what files are getting downloaded, and why.
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.