Jump to content

Community

Search tool doesn't search archived posts... Ridiculous...


Recommended Posts

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.

Link to post
Share on other sites
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."

Link to post
Share on other sites
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. :)

Edited by openfire
Link to post
Share on other sites
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.

Link to post
Share on other sites

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.

Link to post
Share on other sites
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. 

Link to post
Share on other sites
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...

Link to post
Share on other sites
  • Management

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. 

Link to post
Share on other sites

@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.

Link to post
Share on other sites
  • 4 weeks later...
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.

 

Link to post
Share on other sites
  • Management

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. 

Link to post
Share on other sites

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.

Link to post
Share on other sites

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.

Link to post
Share on other sites

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.

Edited by Gabriel Torres
Link to post
Share on other sites
  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...

Important Information

We use technologies, such as cookies, to customise content and advertising, to provide social media features and to analyse traffic to the site. We also share information about your use of our site with our trusted social media, advertising and analytics partners. See more about cookies and our Privacy Policy