cb integration user not enabled - confirmed

Yes, the Skip Activation setting should do exactly what you're saying (approve all Facebook users, since you should have a 'good' email for them anyways), but force Joomla users to have to activate first.

This is usually caused because CB is unable to save the user. That's usually because their profile isn't filled out completely. Please check the following post about CB and required fields, about 4 questions in:
www.sourcecoast.com/extensions/jfbconnec...s#CB-required-fields

We're working on a way to let admins add the required fields to the registration page (when the "Full Joomla User" setting is enabled.

If that doesn't work, let us know, and we can investigate further. Good luck!

I'm unsure which way you want it to work. Are you trying to use Skip CB Activation, or not? If so, then no email will be sent because they should be automatically activated. However, for it to work properly, the user's profile can't have required fields. Can you try, temporarily, disabling all required fields to see if registration works properly when they're disabled? Even if there are defaults, try making the fields not required for now.

If you're trying to force the user's to activate their account, the email should be sent, but only if their profile can be properly saved by CB. Please try the same thing as above in this case as well (disabling required fields).

In both cases, you'll need delete any users that have been created before in CB by JFBConnect that weren't automatically activated. We only attempt to skip activation on the initial registration, not subsequent logins.

Hope this helps, and let us know if a fresh registration works when required fields are disabled. If not, we may need to look into the issue more on your site and would need super admin credentials to do so.

Thanks!

The blank white page can help us a bit if you can enable error reporting and let us know what the error that's being generated is. To learn how to enable error reporting, please see the top article in:
www.sourcecoast.com/extensions/troublesh...ng-joomla-extensions
Please enable that and let us know what appears on the white page you mention above. That will likely help us determine the error very quickly.

Also, what version did you upgrade from? That could aid us in determining where something may have changed and/or broke.

For super admin credentials, please private message them to me. You can do so by clicking the arrow under my name (<----) and clicking the mail icon.

Thanks!

Serena,
I've done some research on the error you mention above. It has to do with improper, or non-functioning, GZip compression either on your server or the site that you're trying to communicate with. I believe the issue is that your server is forcing GZip compression on all requests, and not all requests to Facebook can use GZip compression.

In the Joomla configuration, GZip is not enabled, but the page itself is definitely compressed. Do you have control over the server, or can you contact your hosting provider to see if they can temporarily disable GZip compression to determine if that fixes the issue? This isn't a permanent solution, but I don't know what the cause is from what's happening.

There's nothing in the changes from 3.1.1 to 3.1.2 that would have affected how the page is compressed or sent between Facebook and your server. Facebook is constantly changing things on their end, so it's very possible they updated something on their end that is causing this issue.

We'll keep investigating and let you know what we find. If you're able to disable GZip, let us know if that resolves your issue.

Thanks!

Gzip is still enabled. If I look at the headers from your page, this is what I see:

---

Response Headers - www.il-dono.org/
Server: nginx
Date: Fri, 04 Feb 2011 02:24:21 GMT
Content-Type: text/html; charset=utf-8
Transfer-Encoding: chunked
Connection: keep-alive
P3P: CP="NOI ADM DEV PSAi COM NAV OUR OTRo STP IND DEM"
Expires: Mon, 1 Jan 2001 00:00:00 GMT
Last-Modified: Fri, 04 Feb 2011 02:24:21 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Content-Encoding: gzip
Vary: Accept-Encoding

200 OK

---

If you'd like us to send you the 3.1.1 package, we can gladly send that to you to install (you won't need to uninstall first), and see if that actually improves the situation. If so, we'll investigate what could possibly have caused the difference. Until then, please try to determine what's gzipping the output as we still think that's the ultimate cause of the problem based on the error your seeing.

Thank you, and please keep us posted on what you find.