This how-to is taken from a response to a question that was asked on the forum about how to make files come up in search results (specifically, how you can make the file attributes -- e.g. file name and description -- searchable via the search block).

@dvodvo asks...

The issue is this -- I've got a page that shows a list of music files the client adds through the file manager. The page spits out each file's title, url, etc. according to File Attributes the client specifies in the file manager.

But, he wants a user searching for, say, a particular artist, to show up in the search results. The only place that artist text would be stored would be within the Artist custom attribute that's been created and assigned to a specific audio file.

First, what does checking "Content included in "Keyword Search"" actually do? Does is mean the file manager search or the site search. If the latter that'd be great, but what would that search result point to? The actual file?

ANSWER: As far as I can tell, 'Content included in "Keyword Search"' and 'Field available in "Advanced Search"' are only applicable to the search in the File Manager (keyword search is the textbox you type into, advanced search is when you click the little "plus sign" and choose individual fields to filter on).

Also as far as I can tell, many of the things on this documentation page are wrong (well, out of date): http://www.concrete5.org/documentation/general-topics/search/

One thing to consider is that the search block only links to pages, not files -- so even if the system's underlying file attribute search worked as you'd hope it would (that is, automatically be included in searches from the search block just by the mere existence of attributes), the search block wouldn't be able to link to it because it only links to pages, not file downloads. Ideally one day the search block would be modified to address this, but that day is not today :)

So, all that being said, here's how you can make file searching work:

1) You must alter the code of the block that is displaying the files on the page. You must add some code like this to its controller.php file:

public function getSearchableContent() {
    $files = $this->getPermittedFileObjects(); //<--this is a function you will have to write, but it is probably the same thing you're doing when retrieving files for the view. It needs to return an array of file objects.
    $content = '';
    foreach ($files as $file) {
        $content .= $file->getTitle() . ' - ' . $file->getDescription();
    }
    return $content;
}

If your files were being listed from the built-in "Content" block, then unfortunately you're out of luck and this solution won't work (because the "Content" block already has a getSearchableContent() function, and it only returns raw content -- which, if someone inserted a file from the file manager, is actually in there as a code along the lines of "CCM:CID_79", not the name or description of your file).

2) Make sure the page Area that this block lives in are included in the list of areas that get indexed for searches. Go to Dashboard -> Sitemap -> Page Search, and click the teeny tiny "Setup Index" link: If you don't know what the things on this "Setup Search Index" page mean, then just make sure none of the boxes are checked and that the "Blacklist" option is selected in the dropdown menu (then click the "Save" button in the lower-right if you had to make any changes). BTW, If you don't see the Area name that you want in the list... well then I'm not sure what to tell you (I've never not seen an area I wanted -- hopefully it's always like that).

3) Run the search index job. No, not that one -- it won't do anything! You want the super-secret search index job that actually indexes blocks other than "Content". To run this, go to the usual place (Dashboard -> System & Maintenance). But instead of just clicking the "Run Checked" button, you want to copy the URL at the bottom, paste it into your browser's address bar, then add "&force=1" to the end of it. For example, if the URL was this:

http://example.com/tools/required/jobs?auth=c5e9439560b97c3eff17893eabf72706

you would paste this into your address bar"

http://example.com/tools/required/jobs?auth=c5e9439560b97c3eff17893eabf72706&force=1

Then hit enter to go to that url. It might take a little bit depending on how big your site is and how much content there is, but eventually it will stop loading and leave you on a blank white page. Just click the back button to get back to the dashboard.

4) Success! Well, kind of... there are a few limitations on what the search block actually searches for. The biggest one is that it completely fails on spaces (if someone wanted to search for "daily specials" for example, nothing would come up). Fortunately this can be fixed fairly easily: http://www.concrete5.org/index.php?cID=112065 (Note that this fix will be included in the core system for whatever version is after 5.4.1.1, so if you're reading this in the future, you might not need to do this step).

I have also gotten tripped up because I kept trying to search on file names (which was in the file's "title" attribute, so I know it was getting added to the index), but they never came up. I eventually realized it's because there were dashes in the name (like "client-file-10.pdf"), which the search block also fails on. It basically ignores everything that isn't alphanumeric (or a space or tab or newline character if you add the fix above). So if this is going to be a problem, you'll need to tweak the regex in the above fix to include whatever characters are important to you. But I don't know if there are bad consequences to this (probably nothing more than returning too many results for certain search terms).

Ideally, the search block would strip out the characters that it's ignoring from both the content it's searching AND the query terms that were entered by the user. Maybe that can be fixed some day as well, but that day also is not today :)

Okay, I think that does it. I hope this works for you.

-Jordan