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.Also what does this mean: Status:Warning
primary shards are allocated but replicas are not ?
I'm just purchasing this now, and will try the above to see if it works with XenTagI 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.
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.I'm just purchasing this now, and will try the above to see if it works with XenTag
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.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).
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: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.
if (XenForo_Application::get('options')->enableElasticsearch)
if (XenForo_Application::get('options')->enableElasticsearch && false)
Yep, that worksOr in the DigitalPointSearch/Listener/SearchSourceCreate.php file, change this line:
to this:PHP:if (XenForo_Application::get('options')->enableElasticsearch)
PHP: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.
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) {
}
}
Sorry I meant to ask about search_source_create in my earlier post (not search handler, my memory failed me, sorry for the confusion).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.
XcacheWhat cache type are you using in XenForo? (Should be defined in your config.php)
$config['cache']['enabled'] = true;
$config['cache']['frontend'] = 'Core';
$config['cache']['frontendOptions']['cache_id_prefix'] = 'xf_';
$config['cache']['cacheSessions'] = true;
$config['cache']['backend']='Xcache';
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.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 ?
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
PHP:$config['cache']['enabled'] = true; $config['cache']['frontend'] = 'Core'; $config['cache']['frontendOptions']['cache_id_prefix'] = 'xf_'; $config['cache']['cacheSessions'] = true; $config['cache']['backend']='Xcache';
Yes, it's a bit hacky but there is no other way to alter the metadata for XenForo_Search_DataHandler_Thread::_insertIntoIndex: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.
$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
);
xcache.size="256M"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).
We use essential cookies to make this site work, and optional cookies to enhance your experience.