Way to turn off Newest Photos?

[tpearl5]

FYI, I installed the FB app on my other site and it appears to be working without a problem. That includes the problems I was having with sphinx.

So whatever the problem is, it's definitely because of a configuration somewhere localized to CPF

[Kyle Furlong]

I made a ticket specifically for this in the JIRA. I really hope this isn't responded with 'we don't support modifications' since it is apparently not digitalpoint's error. It sounds like a consistency issue more than anything.

Your forum appears to be misconfigured. I am getting HTTP 400 errors when trying to use the API. Please open a support ticket to troubleshoot this.

[tpearl5]

I made a ticket specifically for this in the JIRA. I really hope this isn't responded with 'we don't support modifications' since it is apparently not digitalpoint's error. It sounds like a consistency issue more than anything.

[digitalpoint]

So using vB_Search_Results::create_from_cache($current_user, $criteria); will not work with Sphinx?

It should be fine... we don't touch anything in the vB_Search_Results class, unless you are searching for something that vB doesn't normally support with search (like searching PMs or User Notes), but I assume the FB App isn't trying to do that.

[tpearl5]

btw, I opened a ticket with support regarding the newest and popular threads not working on monday but haven't received a response.

[Kyle Furlong]

At first glance it looks okay... as long as the $search_core object is being reused to call methods. After the $search_core object is initiated, there should no longer be any direct calls to the vB_Search_Core class/methods, otherwise you will end up bypassing the defined search instance.

Referencing constant variables within the class like vB_Search_Core::SEARCH_ADVANCED is fine.

There was a similar issue within the normal search.php page where we were initiating the search class, but then going back and referencing methods via vB_Search_Core::...() calls. http://tracker.vbulletin.com/browse/VBIV-8822

Long story short is as long as vB_Search_Core methods are called from the $search_core object, and not from direct vB_Search_Core calls, it should be fine. It's hard to tell/trace without seeing all the code after the $search_core object init, but that would be the first place I would look.

If it's something that isn't blatantly obvious, I could probably find the underlying cause if I had access to a test site that was exhibiting the issue.

So using vB_Search_Results::create_from_cache($current_user, $criteria); will not work with Sphinx?

[digitalpoint]

This is a relevant snippet from the only new search api method:

$search_core = vB_Search_Core::get_instance();        
$current_user = new vB_Legacy_CurrentUser();
if (!$vbulletin->options['enablesearches']) {            
    return $this->error('searchdisabled');        
}                
$criteria = $search_core->create_criteria(vB_Search_Core::SEARCH_ADVANCED);                
$userids_a = explode(',', $userids);        
$contenttypeids_a = explode(',', $contenttypeids); 

And so on, let me know if that's not enough to judge compatibility Digital.

At first glance it looks okay... as long as the $search_core object is being reused to call methods. After the $search_core object is initiated, there should no longer be any direct calls to the vB_Search_Core class/methods, otherwise you will end up bypassing the defined search instance.

Referencing constant variables within the class like vB_Search_Core::SEARCH_ADVANCED is fine.

There was a similar issue within the normal search.php page where we were initiating the search class, but then going back and referencing methods via vB_Search_Core::...() calls. http://tracker.vbulletin.com/browse/VBIV-8822

Long story short is as long as vB_Search_Core methods are called from the $search_core object, and not from direct vB_Search_Core calls, it should be fine. It's hard to tell/trace without seeing all the code after the $search_core object init, but that would be the first place I would look.

If it's something that isn't blatantly obvious, I could probably find the underlying cause if I had access to a test site that was exhibiting the issue.

[tpearl5]

Check your mobile home page settings, if you have a date cut off there that is very short, you won't see any thing. Its a long shot, but something to check. Have you opened a support ticket for this issue? Our staff can help you through any common API issues you may be having, as well as make sure your config otherwise checks out.

It's set to 30 days. No, I'll have to open a ticket.

[tpearl5]

FYI, search works on my mobile apps, but Recent and popular posts does not. I believe I'm dealing with two different issues.

[Kyle Furlong]

Recommended seems to work - it's popular and recent threads that I can't get to show up.

Check your mobile home page settings, if you have a date cut off there that is very short, you won't see any thing. Its a long shot, but something to check. Have you opened a support ticket for this issue? Our staff can help you through any common API issues you may be having, as well as make sure your config otherwise checks out.

[Kyle Furlong]

Calls to the search API work fine with third party search (which is why search works fine with the mobile app). I don't have a copy of the Facebook App myself so I can't really go digging into what the issue might be. But as long as the Facebook App is using standard vB calls for search (either normally through the standard vB_Search_Core::get_instance() method or via the mobile API), it should work fine.

This is a relevant snippet from the only new search api method:

$search_core = vB_Search_Core::get_instance();        
$current_user = new vB_Legacy_CurrentUser();
if (!$vbulletin->options['enablesearches']) {            
    return $this->error('searchdisabled');        
}                
$criteria = $search_core->create_criteria(vB_Search_Core::SEARCH_ADVANCED);                
$userids_a = explode(',', $userids);        
$contenttypeids_a = explode(',', $contenttypeids); 

And so on, let me know if that's not enough to judge compatibility Digital.

[digitalpoint]

Calls to the search API work fine with third party search (which is why search works fine with the mobile app). I don't have a copy of the Facebook App myself so I can't really go digging into what the issue might be. But as long as the Facebook App is using standard vB calls for search (either normally through the standard vB_Search_Core::get_instance() method or via the mobile API), it should work fine.

[tpearl5]

Recommended seems to work - it's popular and recent threads that I can't get to show up.

[Kyle Furlong]

That's strange, the only plugin I have installed that deals with registration is spam-o-matic. I wrapped some if statements around the plugin code. Can you try registering again?

I'm using the exact config as apache, and I'm not seeing any errors so I don't believe that's a problem.

The only other thing I can think of is I'm using digitalpoint sphinx search, which replaces the default vbulletin search. The FB app doesn't look like it's recognizing the search implementation setting.

Two categories in the app depend on the search api. (which may or may not work with that third party search) These are "Recommended" and "Friends".

[tpearl5]

Actually, regardless of the search implementation setting, I'm not getting anything on https://apps.facebook.com/cellphonef...opular_Threads