Digital Point Search [Paid] 2.0.0

[xfrocks]

Nothing fancy actually. The add-on had to extend search handler to append metadata to search index entries. I guess you also extend search handler (and return false)?

 

[Brent W]

Also what does this mean: Status:Warning
primary shards are allocated but replicas are not ?

 

[digitalpoint]

No, we aren't extending any search handlers since we just add 3 new ones (users, reports, conversations). If xenTag had it's own search handlers for any of those content types, it definitely would be a problem since I'm pretty sure you can't have multiple search handlers for a single content type.

 

[digitalpoint]

Also what does this mean: Status:Warning
primary shards are allocated but replicas are not ?

It means your search cluster is working, but you have no failover/redundancy. Elastic Search is designed for multiple nodes... So if you are running it on a single server, you would get that warning.

 

[digitalpoint]

I downloaded XenTag, and while I didn't install it anywhere (no where to install it), I did skim over some of the code to see what's going on... It appears they are using proxy classes to extend the search_source_create system, which normally isn't done/allowed (it's not normally something you extend).

It's a little tough to figure out a workaround since I don't have a setup to play on, but what happens if you disable the "search_source_create" event listener for XenES, but leave the one for DigitalPointSearch? Since we are extending the XenES one (when present), it shouldn't matter if you disable the listener for it.

 

[digitalpoint]

One thing I forgot to mention about this addon is that if you are using XF Enhanced Search, the indexing process is decoupled from the user experience. For example when a user posts a new thread or post, the new content that needs to be indexed is queued internally, and the indexing actually happens on __destruct() (so if Elastic Search is being slow or funky, it doesn't affect the user experience).

 

[MattW]

I downloaded XenTag, and while I didn't install it anywhere (no where to install it), I did skim over some of the code to see what's going on... It appears they are using proxy classes to extend the search_source_create system, which normally isn't done/allowed (it's not normally something you extend).

It's a little tough to figure out a workaround since I don't have a setup to play on, but what happens if you disable the "search_source_create" event listener for XenES, but leave the one for DigitalPointSearch? Since we are extending the XenES one (when present), it shouldn't matter if you disable the listener for it.

I'm just purchasing this now, and will try the above to see if it works with XenTag

 

[MattW]

@digitalpoint - I've tried twice to reset my password on your site, but I've not had any of the e-mails. Any chance you could look at this so I can purchase the add-on? Should be the same username on your site. Thanks

EDIT: Never mind! I'd originally signed in via FB....which is why a password wasn't working

 

[digitalpoint]

I'm just purchasing this now, and will try the above to see if it works with XenTag

One thing about the weirdness with XenTag, you could simply disable the search_source_create listener for Digital Point Search. That's the thing that's clashing with XenTag, and the only thing it does is the part to speed up indexing with XenForo Enhanced Search by decoupling the indexing process from the user experience when they post something new.

Also, if you aren't using XF Enhanced Search, there shouldn't be any conflicts with XenTag. It's just the combination of XenTag, XF Enhanced Search and Digital Point Search (all 3 would need to be running for the issue to pop up).

 

[MattW]

One thing about the weirdness with XenTag, you could simply disable the search_source_create listener for Digital Point Search. That's the thing that's clashing with XenTag, and the only thing it does is the part to speed up indexing with XenForo Enhanced Search by decoupling the indexing process from the user experience when they post something new.

Also, if you aren't using XF Enhanced Search, there shouldn't be any conflicts with XenTag. It's just the combination of XenTag, XF Enhanced Search and Digital Point Search (all 3 would need to be running for the issue to pop up).

I have XF Enhanced Search running as well. I remember when I first moved the XF ES there were some issues with XenTag that @xfrocks managed to sort out.

 

[digitalpoint]

I have XF Enhanced Search running as well. I remember when I first moved the XF ES there were some issues with XenTag that @xfrocks managed to sort out.

Well like I said, you could just disable the search_source_create listener for DigitalPoint Search. Or in the DigitalPointSearch/Listener/SearchSourceCreate.php file, change this line:

if (XenForo_Application::get('options')->enableElasticsearch)

to this:

if (XenForo_Application::get('options')->enableElasticsearch && false)

Again... the only thing disabling this addon's search source handler would be the decoupling of indexing from the user experience... functionality-wise, you wouldn't lose anything.

 

[MattW]

Or in the DigitalPointSearch/Listener/SearchSourceCreate.php file, change this line:

if (XenForo_Application::get('options')->enableElasticsearch)

to this:

if (XenForo_Application::get('options')->enableElasticsearch && false)

Again... the only thing disabling this addon's search source handler would be the decoupling of indexing from the user experience... functionality-wise, you wouldn't lose anything.

Yep, that works

 

[MattW]

Just got this error when trying to view the Areas tab

The following error occurred:
Datas must be string or set automatic_serialization = true

1. Zend_Cache::throwException() in Zend/Cache/Core.php at line 360
2. Zend_Cache_Core->save() in DigitalPointSearch/Model/Member.php at line 31
3. DigitalPointSearch_Model_Member->getPostAreas() in DigitalPointSearch/ControllerPublic/Member.php at line 11
4. DigitalPointSearch_ControllerPublic_Member->actionPostAreas() in XenForo/FrontController.php at line 337
5. XenForo_FrontController->dispatch() in XenForo/FrontController.php at line 134
6. XenForo_FrontController->run() in /home/z22se/public_html/index.php at line 13

Zend_Cache_Exception: Datas must be string or set automatic_serialization = true - library/Zend/Cache.php:209
Generated By: Matt, 1 minute ago
Stack Trace
#0 /home/z22se/public_html/library/Zend/Cache/Core.php(360): Zend_Cache::throwException('Datas must be s...')
#1 /home/z22se/public_html/library/DigitalPointSearch/Model/Member.php(31): Zend_Cache_Core->save(Array, 'post_areas13', Array, 3600)
#2 /home/z22se/public_html/library/DigitalPointSearch/ControllerPublic/Member.php(11): DigitalPointSearch_Model_Member->getPostAreas(13)
#3 /home/z22se/public_html/library/XenForo/FrontController.php(337): DigitalPointSearch_ControllerPublic_Member->actionPostAreas()
#4 /home/z22se/public_html/library/XenForo/FrontController.php(134): XenForo_FrontController->dispatch(Object(XenForo_RouteMatch))
#5 /home/z22se/public_html/index.php(13): XenForo_FrontController->run()
#6 {main}
Request State
array(3) {
  ["url"] => string(193) "http://www.z22se.co.uk/members/vocky.13/post-areas?_xfRequestUri=%2Fmembers%2Fvocky.13%2F&_xfNoRedirect=1&_xfToken=1%2C1377593721%2Ca41a7f28f4065e0bbb98eeb732e1b3bfe5c39419&_xfResponseType=json"
  ["_GET"] => array(4) {
    ["_xfRequestUri"] => string(18) "/members/vocky.13/"
    ["_xfNoRedirect"] => string(1) "1"
    ["_xfToken"] => string(53) "1,1377593721,a41a7f28f4065e0bbb98eeb732e1b3bfe5c39419"
    ["_xfResponseType"] => string(4) "json"
  }
  ["_POST"] => array(0) {
  }
}

 

[xfrocks]

I downloaded XenTag, and while I didn't install it anywhere (no where to install it), I did skim over some of the code to see what's going on... It appears they are using proxy classes to extend the search_source_create system, which normally isn't done/allowed (it's not normally something you extend).

It's a little tough to figure out a workaround since I don't have a setup to play on, but what happens if you disable the "search_source_create" event listener for XenES, but leave the one for DigitalPointSearch? Since we are extending the XenES one (when present), it shouldn't matter if you disable the listener for it.

Sorry I meant to ask about search_source_create in my earlier post (not search handler, my memory failed me, sorry for the confusion).

The add-on [Tinhte] XenTag need to listen to search_source_create to add metadata for thread and support a few features of its. However, XenForo Enhanced Search listens to that event and returns false which prevent other listeners from being run. That's why a file edit is required to run XenTag with XenES. I'm not sure what you do with search_source_create event, do you happen to also return false for that? What is your execution order for that listener @digitalpoint ?

 

[digitalpoint]

What cache type are you using in XenForo? (Should be defined in your config.php)

 

[MattW]

What cache type are you using in XenForo? (Should be defined in your config.php)

Xcache

$config['cache']['enabled'] = true;
$config['cache']['frontend'] = 'Core';
$config['cache']['frontendOptions']['cache_id_prefix'] = 'xf_';
$config['cache']['cacheSessions'] = true;
$config['cache']['backend']='Xcache';

 

[digitalpoint]

Sorry I meant to ask about search_source_create in my earlier post (not search handler, my memory failed me, sorry for the confusion).

The add-on [Tinhte] XenTag need to listen to search_source_create to add metadata for thread and support a few features of its. However, XenForo Enhanced Search listens to that event and returns false which prevent other listeners from being run. That's why a file edit is required to run XenTag with XenES. I'm not sure what you do with search_source_create event, do you happen to also return false for that? What is your execution order for that listener @digitalpoint ?

Wouldn't it be better to change the individual handlers you are trying to alter (like threads), vs trying to alter the abstract and changing it for every content type? The way XenTag is messing with the search_source_create class it's a little kludgey since it's not really intended to be extended the way XenTag is doing it.

 

[digitalpoint]

Xcache

$config['cache']['enabled'] = true;
$config['cache']['frontend'] = 'Core';
$config['cache']['frontendOptions']['cache_id_prefix'] = 'xf_';
$config['cache']['cacheSessions'] = true;
$config['cache']['backend']='Xcache';

How much memory do you have allocated to xcache (in php.ini)? I'm thinking maybe I shouldn't use the cache unless memcache (because I suspect Xcache setups are going to be using less memory allocated to it).

 

[xfrocks]

Wouldn't it be better to change the individual handlers you are trying to alter (like threads), vs trying to alter the abstract and changing it for every content type? The way XenTag is messing with the search_source_create class it's a little kludgey since it's not really intended to be extended the way XenTag is doing it.

Yes, it's a bit hacky but there is no other way to alter the metadata for XenForo_Search_DataHandler_Thread::_insertIntoIndex:

$metadata = array();
$metadata['node'] = $data['node_id'];
$metadata['thread'] = $data['thread_id'];
if (!empty($data['prefix_id']))
{
$metadata['prefix'] = $data['prefix_id'];
}

$indexer->insertIntoIndex(
'thread', $data['thread_id'],
$data['title'],'',
$data['post_date'], $data['user_id'], $data['thread_id'], $metadata
);

The variable $metadata is locally initialize and pass directly to a XenForo_Search_Indexer object, and in turn to XenForo_Search_SourceHandler_Abstract. In order to add more metadata, extending XenForo_Search_SourceHandler_Abstract is required.

 

[MattW]

How much memory do you have allocated to xcache (in php.ini)? I'm thinking maybe I shouldn't use the cache unless memcache (because I suspect Xcache setups are going to be using less memory allocated to it).

xcache.size="256M"
Looking at the cache settings, there is currently 54.05 M free.