I've built an app for Shopify which displays in a page in a store's admin section. The way that works is that an html page from my server is displayed inside an iframe on the Shopify admin.
When any page is loaded in the Shopify admin, a blue progress bar displays at the top; usually it progresses across the page pretty quickly and is gone. On my page, however, the bar progresses across the page very slowly and never finishes. My page is very small, and it displays almost instantaneously.
It seems like Shopify is looking for something in the background, but I don't know what it is. Do you know?
You can stop the blue loading bar by calling ShopifyApp.Bar.loadingOff(). It would also be stopped if your app uses ShopifyApp.Bar.initialize(config).
Related
I notice that if I put a Vue website in the URL of an Instagram profile, when you click the link, as you click around the site using the Instagram inline-browser (using vue-router), the back/next buttons are disabled.
The only instance of this I can find online is here, but no other details:
https://github.com/swup/swup/issues/403
Does anyone know how this might be fixed?
If you actually click settings in browser, and then close it, all the sudden the back buttons are re-enabled, including all the previous pages you went to in tact in the history... very bizarre.
I'm working on a project and using AOS animation but all div blocks that have an animation on them disappear whenever I refresh the page. I want to trigger a function whenever the page is refreshed so I can use the AOS.refresh(). Is there any way to do this in nuxt.js or maybe a way to go around this AOS bug?
UPDATE:
here's an example this is how the page looks before reloading:
then after reloading:
As you can see. the elements that still appear after the reloading are the ones without AOS animation.
Additionally, if you focus your eyes on the sidebar, notice I have a home page. this problem happens literally everywhere except the home page. When I go to the home page then I go back to other pages the problem basically disappears.
Not sure where is your bug coming from but so far, the homepage of the library achieves to have an animation on a page refresh. Maybe it is a lifecycle code issue at some point. Maybe post some for us to help you debug this one.
To my knowledge, there is no way of watching if your webpage is actually refreshed because there is nothing related to state before this. The only somehow useful thing that may be used sometime is this.$router.history._startLocation, which will give you the first path your webapp was loaded on.
Not sure if it may help you anyhow.
Also, you can maybe give a shot to this library in VueJS and wire it to Nuxt. Should behave pretty much the same.
I have been using Nuxtjs for a while in many of my projects, but I can't seem to figure how to achieve this. I want to prevent the user from viewing a content web they load my website until everything is ready, like what happens in the Google Adsense website https://ads.google.com. I want to display an animation until everything is loaded before removing the animation
We are developing an app which will display a button on product details page to perform some actions. We are using product.metaifields for displaying the same based on a condition. So basically the button display toggles depending upon the metafield value.
The issue we are facing is, activate the feature from admin section and then the button will not show up on the user side unless we do a hard refresh on the browser. What happens here is Shopify caches the metafield value so the condition checking will not work.
Is there any way to remove the page caching while we perform some action on the app?
When you render a page in Shopify, it renders everything including the metafield resource values you may access while rendering. There is no special caching of a metafield value. If you render a metafield "AAA" on a client-facing page, change the metafield using an App or the Admin to be "BBB" there is no signal to the already rendered page to redraw anything.
If you want dynamic behaviour, like rendering a button with a value based on a metafield resource, you will have to either do a callback to an App, get the new contents, and update the DOM, or use a push strategy like WSS:// to keep a channel open to a backend that monitors these things.
So to sum up, your problem is not one of cached data, but instead the fact that you're rendering a non-dynamic value, and expecting your UX to be dynamic.
This is the first Facebook App i've created since the Timeline changes. Everything appears to be working the same, except for adding the app to my page's Timeline "Favorites"(?) (the boxes at the top near the About section). A large majority of the traffic to this app will come from visitors seeing the app tab on our page.
I'm attempting to add it using the following URL:
http://www.facebook.com/dialog/pagetab?app_id=MYAPPID&redirect_uri=MYAPPURL
Then I select the page, and click "Add Page Tab".
This works fine - I can then swap it's position, view the app, edit settings, etc.
I set up the tab how I want it, and then log out and visit my Facebook Page directly to view the app tab as a visitor would. The app is no longer there. Log back in, everything is fine, log back out, it's gone. It appears that if you do not already Like the page, you cannot see the app. If you do like the page, you can see it. I'd like the app to be viewable by people who do not like the page as well, as the app has a fan gate of it's own.
I've disabled Sandbox mode as well so i'm not sure what's left to do.
Any help is appreciated.
You mentioned in the comments that the app is restricted to US users:
Because your app is restricted, it won't be displayed to logged-out browsers - this is expected because unless the user is logged-in, their location and age can't be determined in order to check the restrictions you've set
If you must have the app visible to logged-out users, remove the API-level restriction and use the details passed in the signed_request to show or hide the app's content
{edit} I missed the edit to your question {/edit} - it may also be that your existing signed_request processing code is failing for logged out users