Digital Point Search

Digital Point Search [Paid] 2.0.0

No permission to buy ($150.00)
Overview Updates (7) Reviews (3) History Discussion
xfrocks said:
Yes, it's a bit hacky but there is no other way to alter the metadata for XenForo_Search_DataHandler_Thread::_insertIntoIndex:

PHP: 
$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.
Click to expand...
So rather than trying to extend the source handler and globally do it for all content types (even ones you aren't necessarily trying to alter), why not simply replace the search_handler_class for threads and just extend it like a normal PHP class from XenForo_Search_DataHandler_Thread? Then it's just a matter of editing the search handler for that content type in the xf_content_type_field table, rather than trying to mess with the source handler? $metadata is passed to the source handler from the data handler like normal, so you should be able to do it there (which in my opinion would be the better place to do it anyway)...

MattW said:
xcache.size="256M"
Looking at the cache settings, there is currently 54.05 M free.
Click to expand...
What if you add this to your config?
PHP: 
$config['cache']['frontendOptions']['automatic_serialization'] = true;
 
digitalpoint said:
What if you add this to your config?
PHP: 
$config['cache']['frontendOptions']['automatic_serialization'] = true;
Click to expand...
Then it breaks the whole site

Code: 
An exception occurred: unserialize() expects parameter 1 to be string, array given in /home/z22se/public_html/library/XenForo/Model/DataRegistry.php on line 117

XenForo_Application::handlePhpError()
unserialize() in XenForo/Model/DataRegistry.php at line 117
XenForo_Model_DataRegistry->getMulti() in XenForo/Dependencies/Abstract.php at line 144
XenForo_Dependencies_Abstract->preLoadData() in XenForo/FrontController.php at line 127
XenForo_FrontController->run() in /home/z22se/public_html/index.php at line 13
 
digitalpoint said:
So rather than trying to extend the source handler and globally do it for all content types (even ones you aren't necessarily trying to alter), why not simply replace the search_handler_class for threads and just extend it like a normal PHP class from XenForo_Search_DataHandler_Thread? Then it's just a matter of editing the search handler for that content type in the xf_content_type_field table, rather than trying to mess with the source handler? $metadata is passed to the source handler from the data handler like normal, so you should be able to do it there (which in my opinion would be the better place to do it anyway)...
Click to expand...

I would avoid replacing an entire class or method. Imagine two add-ons trying to replace a method, one will definitely break. With my approach, two add-ons will still be able to work together.

That said, I'm still wondering what you did within search_source_create? Do you "return false" there? Try to remove that to see if it works?
 
MattW said:
Then it breaks the whole site

Code: 
An exception occurred: unserialize() expects parameter 1 to be string, array given in /home/z22se/public_html/library/XenForo/Model/DataRegistry.php on line 117

XenForo_Application::handlePhpError()
unserialize() in XenForo/Model/DataRegistry.php at line 117
XenForo_Model_DataRegistry->getMulti() in XenForo/Dependencies/Abstract.php at line 144
XenForo_Dependencies_Abstract->preLoadData() in XenForo/FrontController.php at line 127
XenForo_FrontController->run() in /home/z22se/public_html/index.php at line 13
Click to expand...
Oh, you probably have the wrong data type in your existing cache when you change it. What if you change it to true, and then flush your cache (easiest way would be to restart the PHP process... php-fpm if you use it that way)?
 
digitalpoint said:
Oh, you probably have the wrong data type in your existing cache when you change it. What if you change it to true, and then flush your cache (easiest way would be to restart the PHP process... php-fpm if you use it that way)?
Click to expand...
You da man (y)

Works perfectly now (just needed to restart apache after changing it)
 
xfrocks said:
I would avoid replacing an entire class or method. Imagine two add-ons trying to replace a method, one will definitely break. With my approach, two add-ons will still be able to work together.
Click to expand...
Uhm, clearly not. :) Your method requires users to alter the PHP files of other addons and the end result is still breakage when XenTag is running with other addons that use the event listener as designed.

xfrocks said:
That said, I'm still wondering what you did within search_source_create? Do you "return false" there? Try to remove that to see if it works?
Click to expand...
You don't have to replace the entire class/method... you just extend the class like normal and use the normal parent:: inheritance for the method.

Yes, we are intentionally returning false on listener because otherwise XenES's listener will fire, which we don't want since search_source_create is not something you extend like other classes. The underlying issue is that XenTag is trying to internally extend the SOURCE handler, when it's a non-extendable class in XenForo.

The reality is from a design standpoint, you aren't trying to alter the source (storage engine) for search, rather you are trying to add data to a specific type of data (threads). Extending the data handler for threads really would be the better way to do it since that's ultimately what you are trying to do. Doing it that way would be much simpler on your end (you don't need to mess with passing meta data to static variable to be picked up later in the execution chain).

The way you do it now, your setup requires users to manually edit PHP files, and even then it will break things (as you can see in this case) when other addons use the class as intended. Extending the XenForo_Search_DataHandler_Thread class (just via normal PHP class extending) really would be a better way to do it.

MattW said:
You da man (y)

Works perfectly now (just needed to restart apache after changing it)
Click to expand...
Nice... added a note about that on the download page.
 
digitalpoint said:
Uhm, clearly not. :) Your method requires users to alter the PHP files of other addons and the end result is still breakage when XenTag is running with other addons that use the event listener as designed.

You don't have to replace the entire class/method... you just extend the class like normal and use the normal parent:: inheritance for the method.

Yes, we are intentionally returning false on listener because otherwise XenES's listener will fire, which we don't want since search_source_create is not something you extend like other classes. The underlying issue is that XenTag is trying to internally extend the SOURCE handler, when it's a non-extendable class in XenForo.

The reality is from a design standpoint, you aren't trying to alter the source (storage engine) for search, rather you are trying to add data to a specific type of data (threads). Extending the data handler for threads really would be the better way to do it since that's ultimately what you are trying to do. Doing it that way would be much simpler on your end (you don't need to mess with passing meta data to static variable to be picked up later in the execution chain).

The way you do it now, your setup requires users to manually edit PHP files, and even then it will break things (as you can see in this case) when other addons use the class as intended. Extending the XenForo_Search_DataHandler_Thread class (just via normal PHP class extending) really would be a better way to do it.
Click to expand...

As I said, you cannot alter the metadata variable which is locally initialized, XenTag does extend XenForo_Search_DataHandler_Thread actually. Calling parent method will not work in this case (because the variable is locally initialized blah blah). Anyway, it looks like there is no easy way to change metadata for a search data handler. Given that this hacky approach caused too many troubles, I will find another hacky way to do it then.
 
  • Like
Reactions: HWS
Quick question.

How quickly should conversation data be available in the search then?

I'm done a test for "PVD" which was posted earlier this morning. It's not finding it in the conversation.

Also, I've been picking random words to test with, and it's finding them in some conversations, and no others.

Example:

christmas

This is in 2 different conversations, because I pasted the same text into a different PC to another member. It's finding it for one, but not the other.

It's almost like certain PC's can't be searched.
 
MattW said:
Quick question.

How quickly should conversation data be available in the search then?

I'm done a test for "PVD" which was posted earlier this morning. It's not finding it in the conversation.

Also, I've been picking random words to test with, and it's finding them in some conversations, and no others.

Example:

christmas

This is in 2 different conversations, because I pasted the same text into a different PC to another member. It's finding it for one, but not the other.

It's almost like certain PC's can't be searched.
Click to expand...

Did you adjust the MySQL setting that is mentioned on DigitalPoints purchase page? Could have something to do with conversation length.
 
xfrocks said:
As I said, you cannot alter the metadata variable which is locally initialized, XenTag does extend XenForo_Search_DataHandler_Thread actually. Calling parent method will not work in this case (because the variable is locally initialized blah blah). Anyway, it looks like there is no easy way to change metadata for a search data handler. Given that this hacky approach caused too many troubles, I will find another hacky way to do it then.
Click to expand...
Well the XenForo_Search_DataHandler_Thread::_insertIntoIndex() method (I believe this is the one you are ultimately trying to get at) really isn't so big/complex... might just be worth it to overwrite that method straight up or something... not sure the best way to do it, but mucking with downstream classes/methods (the source handler) in the way that's happening just seems like it's going to be more headache than anything. Even if my addon didn't conflict with it, the fact that you need to have users edit the file in XenES is a bit silly when it comes down to it. :) If you are going to have them make a single file edit, just have them edit the
XenForo_Search_DataHandler_Thread file and then not have to mess with weird workarounds that still require file edits.

But personally, I'd just replace the XenForo_Search_DataHandler_Thread::_insertIntoIndex() method completely, and then not have to support users editing PHP files.

MattW said:
Quick question.

How quickly should conversation data be available in the search then?

I'm done a test for "PVD" which was posted earlier this morning. It's not finding it in the conversation.

Also, I've been picking random words to test with, and it's finding them in some conversations, and no others.

Example:

christmas

This is in 2 different conversations, because I pasted the same text into a different PC to another member. It's finding it for one, but not the other.

It's almost like certain PC's can't be searched.
Click to expand...
It's available for search instant, but MySQL has a thing where the group_concat_max_len variable defaults to 1024... this means that a default MySQL config will only index the first 1024 characters of conversations (this actually took me quite awhile to figure out wtf was going on when we were running into the same issue on my site). There's a note about it on the download page...

The MySQL variable group_concat_max_len affects how many characters of conversations are indexed for search. By default this is set to 1024. You may want to increase this value in your /etc/my.cnf file (we have it set to 102400 here).
Click to expand...
 
You must log in or register to reply here.

Similar threads

4
  • Question Question
XF 2.0 Xenforo Enhanced Search vs Digital Point Search
Replies
0
Views
393
420
4
RAHSTYLES
  • Locked
Paid help me put g adsense with Digital Point Ad Positioning
Replies
3
Views
1K
Paul B
Paul B
Top Bottom