Why no bookmark is added automatically for my canvas-app to user's app list, after the user engages with it? The same app had functioned totally fine a few weeks ago.
Starting today, application bookmarks can move "above the fold" (above the "More" link), based on how recently the user used the application. We're now displaying six bookmarks above the fold, which gives users an extra slot for one-click access to your applications.
If a user hasn't clicked a bookmark within the past 30 days, it will move below the fold. If multiple applications have been used recently and are above the fold, their order will be determined by the order in which each bookmark was added. Also, we will automatically bookmark applications for users when they visit an application that has not been bookmarked.
Source : https://developers.facebook.com/blog/post/396
There was before (with FBML) a way to create a bookmark button (See Here) but that option was removed and FBML is now deprecated.
I came across the same problem, i solved it by adding 'redirect_uri' => 'https://apps.facebook.com/your_app_name/' to $facebook->getLoginUrl array paremeters.
This then redirect back to your app url, making that app the latest used.
$dialogbox= "". $facebook->getLoginUrl(array(
'req_perms' => 'publish_stream',
'redirect_uri' => 'https://apps.facebook.com/your_app/'
));
The bookmarks are defined by usage or user preference - we as developers have no control over what icons appear as bookmarks.
Related
From: next/link
You can see that the <Link> component from next/link enables client-side transitions and link prefetching, which are great features, but maybe not for all cases.
Please see the caveat I've run into. Let's say I have the following pages:
Home - Some landing page with a nav bar
Latest - Here I can see my latest posts
Admin - Here I can add more posts
The Latest page from the example above uses getStaticProps with revalidate. Something like:
export const getStaticProps : GetStaticProps<HomeRoute> = async () => {
const preloadedState = await getPreloadedState();
return({
revalidate: 1,
props: {
preloadedState
}
});
};
In theory, after 1 second, it should send the last stale response for the next request and trigger a new static regeneration to be served for the subsequent requests. After 1 second, the process repeats and you get fresh data at least after every second, which is pretty much immediately.
Now, see the caveat I've run into with next/link:
User lands on the Home page. There is a Link on the nav bar pointing to Latest. That link will be prefetched by next/link.
In some other browser, an admin goes to the Admin page and adds one more post (which should appear on the Latest page at some point).
Now user clicks on the Latest page link. The new post is not there.
Clicks on Home again. And clicks again on Latest. New post is still not there and never will be.
The transitions in this case are blazing fast, which is nice. But from my experience so far, I think that that user is locked inside a version of my website where the new post will never be available, because that 1st prefetch happened during a time where the new post didn't exist.
The only way that user will ever see the new post is if he/she presses F5 to do a full website reload. And it might be necessary to refresh twice, because the 1st one might return the previous stale version while triggering the regeneration for the next one.
I mean, what is the workaround to this issue? Should I not use next/link for pages that contain any dynamic data? Should I just use normal <a> tags?
UPDATE
From: https://nextjs.org/docs/basic-features/data-fetching#statically-generates-both-html-and-json
From the excerpt above, we can see that indeed, client-side transitions will not trigger a page regeneration, because they'll not call getStaticProps. They only fetch the pre-built JSON object for the page to use as props.
AFAIK, it means that you'll be locked to the version of the page that existed when you first visited the website. You can go back and forth and nothing in the pages would change, because the JSON data is probably cached on client anyway.
PS: I've tested this (like I've mentioned in the question above) and this is exactly what happens.
So how to workaround that? I would like for users that keep an open tab of my website to be able to get updates for the pages when they navigate from one page to the other.
A POSSIBLE SOLUTION
Set some kind of idle time counter, and if the user gets like 10 minutes of idle time (it means that they left the tab open). Whenever he comes back and do some action, I could refresh the whole website to make sure they get the new version of the pages.
Has anyone faced that problem before?
I've posted this very same question in several forums and this is the response I've got:
It seems what you described is true. next/link caches results in the client-side and your visitor will not fetch a revalidated result out of the box unless there is a full-page reload.
Depending on the likelihood of content changes, you might want to use <a> instead or you can look at some client-side content reload strategy that kicks in after mount and query data source for updated content.
Given that fact, I'll stick to using next/link and client-side transitions. But I'll also use something like a setInterval() to do a full website reload from time to time, so I'm sure my users will keep getting revalidated pages eventually.
We have on our site a physician directory search which has been working cross platform for years. Over the last few months, we have been getting reports that the functionality is broken. My debugging into this issue has led me to find that GTM is actually stripping the URL fragments breaking the functionality in all browsers but IE.
We use Ajax calls to retrieve the directory page by page, 10 items at a time. Some results can yield up to 15 pages, but users are no longer able to get past page 2 of the result set. After page 2 it produces the search page again.
This was rewritten a number of years ago to utilize the URL hash as opposed to using the original cookie based system which simply didn't work. This can be easily reproduced using Chrome by:
Visit https://www.montefiore.org/doctors
Click Search By Specialty
Click Family Practice
Navigate to any secondary page, you will see that the hash fragments have been striped
When you try to navigate to any tertiary page, you are simply presented with the specialty list again.
I have gone through various debugging sessions and have even outsourced the issue to our outside developers, but the issue remains unresolved. Any idea on what could be causing GTM to strip out the fragments?
Any way to hide the Page Navigator that appears on the top of every App Maker produced page? When you create your own custom menu system that navigates the site then there is no longer a need for the page navigator. Also, the naming convention on the pages are not exactly user friendly (not allowing spaces for example) so that makes the page navigator look more like a developer tool than an end-user one. And last but not least, the page navigator is redundant if you only have one page in your app.
You can show/hide page chooser by setting ?console= URL parameter to 1 or 0 correspondingly.
But as Morfinismo noticed, most likely you are looking for creating a deployment which you can share with your end users, configure permissions, etc., since only you can access your Preview deployment.
I touched upon this in a question I submitted yesterday. I am not sure I clarified well what my issue is in that post, so, just to make it less confusing I thought I'd just create a new post.
This is what's happening.
If I go into Preview mode and create a new record and then refresh my browser, the record remains (as you can see I now have many records in Preview). But I realize the Preview is unique to my login.
[Inline image 2][1]
But when I do a deployment and go to the deployment url:
[Inline image 3][2]
And then I create and submit a new record, it works correctly and displays in my list view:
[Inline image 4][3]
But then, if I just stay on the same window tab and refresh my browser, my document disappears.
This could be a permissions problem. Are you using the same account when using the deployed version as when you tested with the Preview mode? If not, the account you used for the deployed version may not have permission to view the record you just entered. When you enter the new record it will appear on the form but when you refresh your browser it does not appear.
I am making changes in preparation for February 1. I have a fan page with 30000 likes. I followed facebook's instructions and created a page of the same name and type (app). The new page does not have any likes (this may take a while?). Nor does the game have the button that my other apps all have (Go to App).
I can't find where this is. I've looked through the newly created page's settings. I've also looked through the app's settings.
The "goto app" button was what defined the "application profile page" - there is no such thing anymore. No (new) applications will ever be able to have that type of page again. You'll have to just use your normal page that you created. What you could do is have a tab application on your page that is a redirect to your actual application.
As the OP has shown in his comments below, my answer above was misleading.
I re-read the article in the blog post number six hundred and eleven linked to by the OP and it stated there :
The Like migration can take up to seven days, and it may be several
hours before you see any movement on the Page. If you have a Vanity
URL associated with your App Profile Page, we will transfer the Vanity
URL to the Facebook Page so long as one doesn’t already exist for the
Page.
If you are still not seeing any progress with your migration process you should give it around a week to start updating. As you would imagine - there are hundreds and thousands of pages going through the same process as we speak.
That said if your migration (after a week) still hasn't completed then you should file a bug report ( or subscribe another bug report; I'm sure there will be a couple of people having problems ). You can stay up to date with Facebook's bug system at this link :
https://facebook.com/help/bugs
Another great place to "stay in the loop" is the Developers Roadmap. All changes will be listed there well before they are implemented. ( 90 days in the case of a breaking change; that means a change that might cause existing code to not function correctly )