Can you please update to the latest Joomla version (2.5.24) and check if the issue is still there? You should update anyway.
I don't make much sense to search for an issue if it was fixed already

Still it is coming. I have attached the same in screenshot. You can see circled in color red.

I have unpublished "Administrator Components" article in backend. But it is showing in auto suggest.

This comment was created with the J!Tracker Application at http://issues.joomla.org/.

Screenshot

This comment was created with the J!Tracker Application at http://issues.joomla.org/.

I am fairly certain that this is a known issue that has existed ever since
smart search was implemented. The problem is that content needs to be
reindexed before any changes in the state of an article will be reflect ed
in the suggestions . it would be good if someone could fins a way to
resolve this but no one has so far
On 19 Sep 2014 10:24, "kalyan227" notifications@github.com wrote:

Still it is coming. I have attached the same in screenshot. You can see
circled in color red.

I have unpublished "Administrator Components" article in backend. But it
is showing in auto suggest.

This comment was created with the J!Tracker Application
https://github.com/joomla/jissues at
http://issues.joomla.org/http://issues.joomla.org/
http://issues.joomla.org/.

—
Reply to this email directly or view it on GitHub
#4301 (comment).

Means should we delete all indexed items in smart search component and reindex it again.

But here also in admin end while indexing it is pointing all unpublished and published articles .

This comment was created with the J!Tracker Application at http://issues.joomla.org/.

All content is indexed regardless of its published state, that's an intended behavior (and the index data should update when an item's state is changed). However, its published state should be taken into account when performing searches.

The auto suggestions uses the #__finder_terms table to pull its data. There isn't an affiliation there with your site content or published states. There's a lot of pre-processing to get to the point where that table is populated, and it's somewhere in there that in theory the data should be checked against and added/removed if needed.

If someone is looking for a more difficult database related project to take on, start at where FinderIndexer::tokenizeToDB() is called in the indexing process and move forward through the code to correctly generate the tokens for the terms table.

This is a known problem and in theory could be "fixed" by adding/removing terms from the terms and mapping tables. However, there is a problem that needs to be resolved. To take an example, the Article Manager screen which lists articles has a column containing an icon indicating the published state of each article. This is also a link which, when clicked, changes the article from published to unpublished or vice versa. There is an expectation that this will be a fairly quick operation. It already triggers an event that is picked up by the Smart Search plugins to toggle the published state in the links table (I think), but if you were to add the code needed to add/remove entries from the terms and mapping tables too then in some cases you would be doing a lot of database updates and that can take a long time. It is likely that toggling the published state of an article containing many thousands of words/terms would cause a very long delay and in extreme cases may cause the PHP request to timeout.

The solution, I believe, is to decouple operations which involve updating the terms/mapping tables and insert a message queue so that these sometimes expensive and time-consuming processes can be carried out in the background, allowing the user to continue working without waiting for them to complete. The best/easiest way to do this is to have a cron job processing the message queues, but sadly there are many shared hosts that do not allow cron jobs. Without a cron job it's necessary to get creative and the approach that was being followed in Finder was to trigger an Ajax request from a module in the admin screens. This too, has limitations and since it wasn't working reliably it wasn't included in the Smart Search code.

In my opinion, to solve this problem we first need to come up with a reliable pseudo-cron mechanism that can be used on hosts where a regular cron or daemon process is not available.

Hello

also access levels and publish up/down are not considered, right ?

This comment was created with the J!Tracker Application at http://issues.joomla.org/.

@ggppdk Correct. Publish up/down is what we are talking about. Access levels can't be solved in the same way.

Hi,
we had this already in Joomla Issues Tracker no.
[#29143] "Smart Search Ajax suggestions do not respect static filters from module-settings"
I have a solution which works for at least for my needs. Brian closed the issue because at that time i did not have the time to provide a patch. Half a year after the issue was closed i had a little time to create a patch against 3.2.0 which i uploaded. I thought with my new comment the issue would be reopened. But it seems as if this was not the case...
Anyhow. The patch is attached there, it still works fine at the site for which i needed it, but i know that it is rather fast and dirty solution than mature code...
It does not recreate the index, but filters at the time the autosuggester runs. Probably not good for much content, but imo better than to provide deprecated or sensitive data via autosugggestions.

attaching anything to a closed issue is a guarnateed way for no one to see it which is exactly what happened. If you submit this patch as a pull request here on github then it can be reviewed

can you provide me the patch to my email (e.chakri@gmail.com)

O.k. Here we go with the pull request #4401 Changed Autosuggester

Closing as we have a PR #4401