Gabriel Torres Posted December 22, 2015 Posted December 22, 2015 Got this information today from the support: Quote Searches to not search through archived content on the site. Really? So what is the use of a search engine if users can't find our contents? It is very stupid not to present results to our users for something they are looking for. They won't find what they are looking for and will leave our forums and go to our competitor's.
eGullet Posted December 22, 2015 Posted December 22, 2015 A workaround may be to use a Google Custom Search engine. DawPi developed a plugin to integrate directly into your board.
Gabriel Torres Posted December 22, 2015 Author Posted December 22, 2015 Excellent! Will do! I looked for this and couldn't find it before... Weird! Many thanks!
Management Charles Posted December 22, 2015 Management Posted December 22, 2015 Archived content is archived and therefore segregated and not available to many functions including search. If you do not want it archived then you should not archive it.
Machsterdaemon Posted December 22, 2015 Posted December 22, 2015 Then why do I get search results for archived topics on this forum?
Machsterdaemon Posted December 22, 2015 Posted December 22, 2015 I entered a search term and got returned results from archived topics on this site. Search result: The archived topic:
eGullet Posted December 22, 2015 Posted December 22, 2015 8 hours ago, Charles said: If you do not want it archived then you should not archive it. I think you are using a very specific definition of "archive" here, which seems to be synonymous with "not valuable anymore, but not quite worth deleting." To me, "archive" means "still valuable, but not changing anymore."
openfire Posted December 22, 2015 Posted December 22, 2015 9 hours ago, Charles said: Archived content is archived and therefore segregated and not available to many functions including search. If you do not want it archived then you should not archive it. You ASSUME that there are no scenarios where such an option might be useful... even though your customers are here telling you otherwise! This is yet another example of a situation where the views of IPS are at odds with many of their customers, and it could be resolved with a simple yes/no option in the admincp. Why do you force your customers to do things your way, when you could easily provide an option and let us decide what is best for our communities? This way everyone is happy.
Gabriel Torres Posted December 22, 2015 Author Posted December 22, 2015 9 hours ago, Charles said: Archived content is archived and therefore segregated and not available to many functions including search. If you do not want it archived then you should not archive it. Seriously? That is the best answer you can come up with? I want archived topics segregated but still searcheable. Your answer is still lame and, quite frankly, very disrespectful.
Mark Posted December 22, 2015 Posted December 22, 2015 The archive feature removes posts from the main posts database table and puts them into a separate location which is not read or written to unless you specifically view the topic. It is a very low-level feature designed for extremely large sites. If archived posts were searchable, we'd either have to read from the archive table (and combine the results with the main table) every time someone runs a search, or keep the archived posts in the search index - both defeats the point of the system. We try to make this clear on the page where you set it up: Quote If you have a very large site, it can be beneficial to reduce the size of the database table storing posts. Archiving topics is an alternative to deleting which allows them to still exist and be viewed as normal, but moves them to a separate database table. Archived topics cannot be posted in or edited, and will not show in search results. You can unarchive topics after they've been archived if you change your mind. In an ideal world, the feature wouldn't be necessary at all - it is only intended to solve a technical problem for large sites (and to be honest, with the MySQL advances since we introduced it, is becoming increasingly less necessary). If you're just looking for a way to make it so old content cannot be replied to, but is still treated like normal, I'd recommend locking the topics (on that note: there is a free modification which has a feature similar to the archive system but which locks old topics). With regards to this site: I assume there is an old bug affecting this (we often use beta versions on this community so sometimes strange issues like this crop up on this site) - we have the archive system turned off on this site.
jaeitee Posted December 23, 2015 Posted December 23, 2015 On 22 December 2015 at 11:35 PM, Charles said: Archived content is archived and therefore segregated and not available to many functions including search. If you do not want it archived then you should not archive it. Archived content is content that is no longer changing, no longer current, but this doesn't mean it's no longer relevant. In fact the search is probably the most valuable tool for accessing that "archived" content.
Shariq Ansari Posted December 23, 2015 Posted December 23, 2015 1 hour ago, N4H said: Archived content is content that is no longer changing, no longer current, but this doesn't mean it's no longer relevant. In fact the search is probably the most valuable tool for accessing that "archived" content. Agreed on all counts; search almost makes MORE sense for archived content, since that's likely to be the primary means of discovery...
Management Lindy Posted December 25, 2015 Management Posted December 25, 2015 The issue is, in order to efficiently search across a large site with all applications installed and do neat things like the activity stream, we use a search index which allows a single table reference vs scanning content across 7+ tables. Archived content is not included in this search index as the purpose behind archival (for our purposes) was to compensate for MySQL shortcomings in dealing with very large tables on larger sites. Including archived content would defeat the purpose of the feature to begin with. As mentioned, it's less relevant now than it was when it was first implemented. MySQL 5.6 (properly configured) pretty much eliminates the need for the archive system. We're just using different definitions of archive. When we say archive, we mean the physical equivalent of not shredding or burning your papers, but instead boxing them up and putting them in the storage closet. It's not intended to be like an archive.org where it's still there as a searchable historical reference. If that's your goal, we would recommend either 1) Locking the topic. 2) Creating an archive forum with appropriate permissions and moving topics to it. Again, the archive feature in IPS4 is putting the content in a box and storing it away. We're open to suggestions on rebadging or clarifying this feature to avoid future confusion.
Gabriel Torres Posted December 27, 2015 Author Posted December 27, 2015 @Mark @Lindy thanks for the improved answer; that is the kind of answer I came to expect from your team! And yes, I decided to go to this route of disabling archiving. This new 4.1.x series is much "lighter" than the 3.4.x series, so I figured that I could unarchived everything with minimum penalty. Thank you also for pointing out the plugin for locking old topics, I will most definetely use it.
openfire Posted December 27, 2015 Posted December 27, 2015 Agreed. The clarification from IPS is refreshing, and much appreciated.
InsideEdge Posted January 23, 2016 Posted January 23, 2016 On 12/25/2015 at 2:51 AM, Lindy said: The issue is, in order to efficiently search across a large site with all applications installed and do neat things like the activity stream, we use a search index which allows a single table reference vs scanning content across 7+ tables. Archived content is not included in this search index as the purpose behind archival (for our purposes) was to compensate for MySQL shortcomings in dealing with very large tables on larger sites. Including archived content would defeat the purpose of the feature to begin with. As mentioned, it's less relevant now than it was when it was first implemented. MySQL 5.6 (properly configured) pretty much eliminates the need for the archive system. We're just using different definitions of archive. When we say archive, we mean the physical equivalent of not shredding or burning your papers, but instead boxing them up and putting them in the storage closet. It's not intended to be like an archive.org where it's still there as a searchable historical reference. If that's your goal, we would recommend either 1) Locking the topic. 2) Creating an archive forum with appropriate permissions and moving topics to it. Again, the archive feature in IPS4 is putting the content in a box and storing it away. We're open to suggestions on rebadging or clarifying this feature to avoid future confusion. So then are you suggesting we should not archive topics or choose something like 5 years instead of 18 months? It would be usefull if that box stored away could still be searchable via "Achived content" specifically as a tag or something of that sort. The only way to look for a specific old topic now is via manual view - page by page.
Management Lindy Posted January 23, 2016 Management Posted January 23, 2016 I'm reluctant to make blanket statements as it always seems to come back to bite me, but we have not found a strong need for archiving on our community or our larger enterprise clients since MySQL 5.6 started supporting fulltext innodb. Granted, our environments are heavily optimized - so your mileage may vary.
InsideEdge Posted January 23, 2016 Posted January 23, 2016 @Lindy Thanks, so with that, I unarchived topics until suggested otherwise to archive again.
Gabriel Torres Posted January 23, 2016 Author Posted January 23, 2016 Just be prepared, as the unarchiving process takes forever. You may want to edit the task default running frequency from 5 minutes to 1 minute. To do that, you have to manually update the database through an SQL query.
AutoItScript Posted January 23, 2016 Posted January 23, 2016 Yeah I was going to log a bug/feedback ages ago because the archiving runs under the normal task scheduler every 5 mins and only does a few posts each cycle. When I tried it I moved it to every minute and then edited the task to do a few thousand at a time. Otherwise the estimated time was measured in weeks :/ It should be a background task really like the post rebuilds after a new upgrade. In the end I realised that archived topics couldn't be searched and that searches on IPS 4 happen in a separate table now so archiving wasn't as important so I unarchived everything.
Gabriel Torres Posted January 24, 2016 Author Posted January 24, 2016 You were lucky... For us would take months... Even editing and running faster it took around 20 days... LOL
cyndisa Posted January 25, 2016 Posted January 25, 2016 The search in archived threads is something we've dealt with, too, and ultimately decided to unarchive everything. On 1/23/2016 at 5:33 PM, Lindy said: I'm reluctant to make blanket statements as it always seems to come back to bite me, but we have not found a strong need for archiving on our community or our larger enterprise clients since MySQL 5.6 started supporting fulltext innodb. Granted, our environments are heavily optimized - so your mileage may vary. So has MySQL 5.6 been implemented for the cloud communities yet? Just curious because our community is waiting on this so we can switch to innodb, and so far, I've been told that the upgrade to MySQL 5.6 will happen sometime this year. Am not sure where to go for updates on when/if this has been done.
Gabriel Torres Posted January 26, 2016 Author Posted January 26, 2016 By the way, guys... IPS has a major bug with its search engine. After unarchiving the archived posts/topics, is still doesn't find certain keywords, even after re-creating the search engine database. The answer from the support department is below. Quote I apologize for the inconvenience. I have confirmed this is a limitation presently if you are using an InnoDB search index table, and have raised an internal discussion to look into ways to resolve the issue for an upcoming release. The only work around presently would be to switch your core_search_index table to MyISAM, however I do not generally recommend doing so for performance reasons. We will investigate the issue and look to work around it in an upcoming release. Now, what really frustrates me with the Tier I support here is that they usually blame our configuration off the bat instead of testing what we are saying, so we go through a lot of back and forth until they finally escalate to someone who actually tests the issue and confirms that there is a bug, what we've been saying for (in this case) over 20 days.
Recommended Posts
Archived
This topic is now archived and is closed to further replies.