JFB connect won't work anymore

Sander,
We've never tested with Incapsula, but we use Cloudflare on this site itself and know of many other sites using Cloudflare. Using a CDN shouldn't cause any issues as long as it's not interfering with the Facebook (or other social network) scripts that must be included.

As for your issue, can you explain more about what you're testing and what isn't working? In your post, you mention "JFBConnect isn't working". There's lots of features in JFBConnect, so we'll need more details than that:
* I'm assuming you're testing Facebook authentication?
* When you try to login when it doesn't work, is there an error message or anything else you can provide?
* If not already enabled, please set the "Enable Debug Mode" setting in JFBConnect to 'Yes' and try again to see if more information of the problem is provided.

Finally, the site you linked to above won't load for me at all, so I can't test. Not sure if it's just down temporarily, or part of the problem.

Thanks,
Alex

Sander,
There are many users that use the Language Switcher plugin, and we haven't heard of this issue yet. I'm not sure if the "Remove Language Code" setting is "no" in those cases, but that's the default setting, which means that most users are probably using it that way. Regardless though, it really shouldn't cause the issues you're having on your site.

As for the problem, when I try to login using Facebook, the page redirects to Facebook and then it's just a blank white page. Is that what you're seeing?

I'm not sure why that's happening, in all honesty, but some things I'd recommend checking or testing are:
* In your template settings, determine how to disable some of the social sharing features. Specifically, the file below should not be loaded:
templates/yoo_moustache/warp/js/social.js
That file is re-including the Facebook Javascript library and could easily be causing the problems you're having
* Try with a different template temporarily (preferably one of the built-in Joomla ones) to see if that changes anything.
* In the Facebook Developer Area , go to the "Status and Review" section and make sure the "Do you want to make this app and all its live features available to the general public?" setting at the top is "Yes"
* In the JFBConnect -> Configuration -> Facebook area, set the "Show Login Credentials in Popup" setting to "Yes" to test if the popup mode works.

Let me know if any of that helps, and we'll gladly continue helping however we can.

Thanks,
Alex

Sander,
2 more things to check/test:
* Please disable any Social Profile plugins you have enabled. That minimizes the amount of 'stuff' that happens during login
* In the JFBConnect -> Configuration -> Facebook area, make sure the "Additional Permission Requests" box is blank. Please don't add anything in there and test again.

Let me know how that goes. If no change, then please Private Message me an admin account to the site, we'd like to investigate further. We'll need to see you're exact settings and try to duplicate the problem on a development site to understand what's actually happening.

Thanks,
Alex

Sander,
I just took quite a bit of time to investigate what's happening on your site. Unfortunately, I don't have an answer to the problem. One really odd and frustrating thing that I encountered multiple times was that when I changed a setting in the admin area, the change wasn't reflected when the page reloaded. I had to hit Refresh in the browser for it to show. I'm not sure what's happening here, but it seems like some very agressive caching somewhere is hiding some changes and could be causing some of the problems you're having. That happened in multiple areas: sh404SEF, Plugin Manager, Joomla Global Configuration area and JFBConnect itself.

As for what we found, I tried many different things to narrow down the cause, including:
* Disabling SEF URLs, both in Joomla and sh404SEF
* Disabling CloudFlare
* Disabling caching, both JotCache and in the Global Configuration area
* Disabling multiple various system and User plugins to try to narrow things down

Ultimately, none of those had any effect. To test further with the language filter plugin, I set the Returning User Redirection in JFBConnect to a different page. That way, I could detect if JFBConnect 'thought' it had logged the user in or not based on if the redirection was followed. Here are the results:
With language code removal set to "No" and using the popup for authentication
This is a working case. Here's the URLs that are loaded:
(Authentication is performed through the popup), then:
/index.php?option=com_jfbconnect&task=authenticate.login&provider=facebook&return=L2VuLw==&d67f7bf8239e25b35bf4ff25359672c5=1

/nl/?option=com_jfbconnect&task=authenticate.login&provider=facebook&return=L2VuLw==&d67f7bf8239e25b35bf4ff25359672c5=1
Login successful

With language code removal set to "No" and using no popup
This is the non-working case. Here's the URLs that are loaded:
/index.php?option=com_jfbconnect&task=authenticate.login&provider=facebook&return=L2VuLw==&dc18387624a4aebd74cef69f2543af64=1

/nl/?option=com_jfbconnect&task=authenticate.login&provider=facebook&return=L2VuLw==&dc18387624a4aebd74cef69f2543af64=1

www.facebook.com/dialog/oauth?client_id=...ation%2Cuser_website

/index.php?option=com_jfbconnect&task=authenticate.callback&provider=facebook&code=AQAH_XrX9TNbsZ0KhzPWR1dHdO8sXuEfRtIZAL6L415dN4U4It-CxJx84hzXhCWEIevcGR_-bnxhGEV9tuVwDum7T2lqE-Ab3_yPeb1NNI3STwP9KZUHznqiye_mRkVlnuXH1-9GTEvwuX7riUCYo3zwErnrlFRFn7ypfWZw8-xdEmwfNRIoDgENt9gEHPSWp-vZLNAbz42zVBPTUjAoHpo-kpY7lVhmgcqVlCces8j_5eP1UeMwmdgpOVGfW1zsPdelAtIttfk1Or24S_YgsKRFHgxnrdyMRMTimJDthCGY_P_CiHSVAuv4_bAEmDYNaD0&state=316b6c4005ffe398ac6e82be79e0fedf

/nl/?option=com_jfbconnect&task=authenticate.callback&provider=facebook&code=AQAH_XrX9TNbsZ0KhzPWR1dHdO8sXuEfRtIZAL6L415dN4U4It-CxJx84hzXhCWEIevcGR_-bnxhGEV9tuVwDum7T2lqE-Ab3_yPeb1NNI3STwP9KZUHznqiye_mRkVlnuXH1-9GTEvwuX7riUCYo3zwErnrlFRFn7ypfWZw8-xdEmwfNRIoDgENt9gEHPSWp-vZLNAbz42zVBPTUjAoHpo-kpY7lVhmgcqVlCces8j_5eP1UeMwmdgpOVGfW1zsPdelAtIttfk1Or24S_YgsKRFHgxnrdyMRMTimJDthCGY_P_CiHSVAuv4_bAEmDYNaD0&state=316b6c4005ffe398ac6e82be79e0fedf

I understand that's all a little hard to dissect. The important thing is that the only difference with the popup version and non-popup version is that there is a 'code' variable passed back from server authentication. Other things, like the URL originally going to your root and then being redirected to /nl/ are in both cases. The code is used by JFBConnect to contact Facebook again and verify the user's identity. My guess is that somewhere in your system, there's something that's stripping the 'code' value from the URL. I say that because *sometimes* when trying to login, the following message appears:

BERICHT
We waren niet in staat om uw Facebook-account informatie op te halen. Probeer het opnieuw.

That didn't appear every time (again, likely a strange caching issue). That error means that the code likely isn't being used and, therefore, JFBConnect can't authenticate the user with Facebook.

Do you know of any extension that may be using 'code' as a variable and removing it? I'm definitely confused, and not sure why the "Remove language code" setting matters.. I looked, and the normal key for the language code is "lang" not "code", so it's not the plugin that's inadvertently removing the wrong key from the URL.

From here, there's really 2 courses of action and it really depends on how you want the URLs to show:
* If you want the language code in the URLs, which is when JFBConnect doesn't work, then we'll need to get FTP access to your site to add some more debug code and determine where things are going wrong.
* If you don't want the language code in the URLs, then you'll need to contact JomSocial to figure out why their feed module isn't working when the codes are missing.

We'll gladly help, but if you know anything more about your caching, the 'code' variable, or anything else that the above info may help narrow things down with, please let me know.

Thanks,
Alex