Digital Point Search [Paid] 2.0.0
- Thread starter digitalpoint
- Start date
The guidelines were introduced a while ago.
We have allowed a more than reasonable grace period and any add-ons which are still not compliant will be removed until the author updates them.
We are unable to take individual circumstances into account, otherwise others would be pleading their case and there would be claims of favouritism.
Considering the discussion which took place recently in relation to another developer, we aim to treat all developers the same.
We have allowed a more than reasonable grace period and any add-ons which are still not compliant will be removed until the author updates them.
We are unable to take individual circumstances into account, otherwise others would be pleading their case and there would be claims of favouritism.
Considering the discussion which took place recently in relation to another developer, we aim to treat all developers the same.
FredC
Well-known member
I dont get the big deal all DP's addons are hosted on digitalpoint.com the only thing deleted was a redirect.. (in essence)
Robust
Well-known member
Anyone had this error and knows what the issue is? Triggered on admin.php
Code:
Server Error Log
Error Info
ErrorException: Undefined index: start_time - library/DigitalPointSearch/ControllerAdmin/Elasticsearch.php:31
Generated By: Robust, A moment ago
Stack Trace
#0 /blah/library/DigitalPointSearch/ControllerAdmin/Elasticsearch.php(31): XenForo_Application::handlePhpError(8, 'Undefined index...', '/var/www/gaming...', 31, Array)
#1 /blah/library/XenForo/FrontController.php(347): DigitalPointSearch_ControllerAdmin_Elasticsearch->actionNodeStats()
#2 /blah/library/XenForo/FrontController.php(134): XenForo_FrontController->dispatch(Object(XenForo_RouteMatch))
#3 /blah/admin.php(13): XenForo_FrontController->run()
#4 {main}
Request State
array(3) {
["url"] => string(223) "https://www.gamingforums.net/admin.php?elasticsearch/node-stats&node=blah&&_xfRequestUri=%2Fadmin.php&_xfNoRedirect=1&_xfToken=blah&_xfResponseType=json"
["_GET"] => array(6) {
["elasticsearch/node-stats"] => string(0) ""
["node"] => string(22) "blah"
["_xfRequestUri"] => string(10) "/admin.php"
["_xfNoRedirect"] => string(1) "1"
["_xfToken"] => string(53) "blah"
["_xfResponseType"] => string(4) "json"
}
["_POST"] => array(0) {
}
}
btfstone
Member
Marking this issue as breaking as it breaks the output of the nodes info api, since start_time andrefresh_interval will be replaced by default by start_time_in_millis and refresh_interval_in_millis. With the human flag start_time and refresh_interval will be returned as well and will contain the human readable variations.
digitalpoint
Well-known member
digitalpoint updated Digital Point Search with a new update entry:
Support for newer ES versions
Read the rest of this update entry...
Support for newer ES versions
Read the rest of this update entry...
kontrabass
Well-known member
Thanks for the update! Is there any way that I can disable the conversation search feature of this addon? I love/need this addon for its other features (searching post reports, soft-deleted content, users...), however another add-on we use and love for conversations (@Daniel Hood Conversation Essentials) already features searchable conversations. This results in two tabs in advanced search for Conversations...
Daniel Hood
Well-known member
I'm going to make an option to disable my tab/indexing. If mine performs differently than his and you favor it though, you'll have to see if Shawn will make a similar option.
kontrabass
Well-known member
Thanks Daniel, but yeah I would rather prefer to disable the DP convo search tab/indexing. Seeing as how yours allows searching by your addon's prefix feature and better results.
@digitalpoint do you think this could be done? Would love to disable conversation search tab and quick search checkbox, and convo indexing... Letting Daniel's addon handle conversation searches, and yours for everything else = perfect scenario for us
digitalpoint
Well-known member
For the time being, you probably want to just disable the conversation search related Template Modifications it has to remove the tab and things related to it. Going to give it some thought to see if there's a good way to disable search handlers on the fly somehow...
Daniel Hood
Well-known member
I think your easiest options would be:
- Delete the content type field when the admin wants it disabled, and add it when they enable it (obviously rebuild the cache for content types after).
- Have an option that when they disable it, your code in the handler does a return; before it calls $this->insertIntoIndex();
kontrabass
Well-known member
I disabled the modification for the "search only conversations" checkbox, but as for the advanced search tabs, it looks like if I disable the search_form_tabs it'll also disable the user and post report tabs.
Thanks for looking into it
Rob
Well-known member
@digitalpoint, I'd like to hear your thoughts on other ways to provide a convo search without maintaining a gigantic index. Each result in the conversation search index can only be seen by two people in most cases, therefore a huge search index for conversation searching seems to me like a pointless waste adding significant overhead when 99.9 percent of records are useless to 99.9 percent of people.
Additionally, when searching all content types, the conversations in the search index will impact upon relevancy and water down results as they are so numerous.
Additionally, when searching all content types, the conversations in the search index will impact upon relevancy and water down results as they are so numerous.
digitalpoint
Well-known member
There's not going to be a way to have something searchable without indexing it. If you could, you should do that for all content types and have a 0 byte index even for posts.
There is more overhead in storing conversations infinitely in your database than there is in indexing them for search. For me, I don't see any value at all in keeping old conversations in the database. On my site, conversations are auto-purged after 6 months. Mainly because I didn't want to store in the database, but doing that also solves the problem of too many conversations in search results.
Probably time to think about how you are handling the root of the problem... Storing old conversations in your database forever.
There is more overhead in storing conversations infinitely in your database than there is in indexing them for search. For me, I don't see any value at all in keeping old conversations in the database. On my site, conversations are auto-purged after 6 months. Mainly because I didn't want to store in the database, but doing that also solves the problem of too many conversations in search results.
Probably time to think about how you are handling the root of the problem... Storing old conversations in your database forever.
