# Including the Document Library block in search engine

**URL:** <https://forums.concretecms.org/t/including-the-document-library-block-in-search-engine/1706>\
**Category:** Developing with Concrete\
**Created:** [November 24, 2021, 5:22pm UTC](https://forums.concretecms.org/t/including-the-document-library-block-in-search-engine/1706 "2021-11-24T17:22:33Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![mesuva](https://forums.concretecms.org/user_avatar/forums.concretecms.org/mesuva/32/6303_2.png) [@mesuva](https://forums.concretecms.org/u/mesuva)\
**Post date:** [November 24, 2021, 5:22pm UTC](https://forums.concretecms.org/t/including-the-document-library-block-in-search-engine/1706/1 "2021-11-24T17:22:33Z")

</div>

Does anyone know if there’s a reason the Document Library doesn’t by default have a `getSearchableContent` function, and therefore isn’t included in the page search index?

I’m wondering if it’s a performance concern, or whether it’s just not something that’s been considered.

I whipped up a solution for this earlier via an override, which looks like this:

```auto
<?php
namespace Application\Block\DocumentLibrary;

use Concrete\Block\DocumentLibrary\Controller as DocumentLibraryBlockController;
use Concrete\Core\File\File;
use Concrete\Core\File\FolderItemList;

class Controller extends DocumentLibraryBlockController
{
    public function getSearchableContent()
    {
        $list = new FolderItemList();
        $list = $this->setupFolderFileSetFilter($list);
        $list = $this->setupFolderFileFolderFilter($list);
        $list->ignorePermissions();
        $list->setItemsPerPage(100000);

        $list = $this->setupFolderAdvancedSearch($list);

        $pagination = $list->getPagination();
        $results = $pagination->getCurrentPageResults();

        $output = '';

        foreach($results as $f) {
            if ($f instanceof \Concrete\Core\Tree\Node\Type\File) {
                $fileID = $f->getTreeNodeFileID();
            } else {
                $fileID = $f->getTreeNodeID();
            }

            $file = File::getByID($fileID);

            if ($file) {
                $output .= $file->getTitle() . ' ' . $file->getDescription() . ' ';
            }

        }

        return $output;
    }
}

```

---

<div class="post-metadata">

**Author:** ![Myq](https://forums.concretecms.org/user_avatar/forums.concretecms.org/myq/32/4281_2.png) [@Myq](https://forums.concretecms.org/u/Myq)\
**Post date:** [November 26, 2021, 1:52am UTC](https://forums.concretecms.org/t/including-the-document-library-block-in-search-engine/1706/2 "2021-11-26T01:52:48Z")

</div>

I’m not aware of any reason, but if you submitted a pull request to add that, if there is a reason, you’ll hear about it 😛

---

<div class="post-metadata">

**Author:** ![JohntheFish](https://forums.concretecms.org/user_avatar/forums.concretecms.org/johnthefish/32/3767_2.png) [@JohntheFish](https://forums.concretecms.org/u/JohntheFish)\
**Post date:** [November 26, 2021, 9:26am UTC](https://forums.concretecms.org/t/including-the-document-library-block-in-search-engine/1706/3 "2021-11-26T09:26:17Z")

</div>

The above is a reasonable solution for some sites in some circumstances, but is not a sufficiently broad solution for all applications.

With a lot of documents, it would create a big spike in processing when the block is saved and within one slice of the indexing job (or task), then run out of resources.

Bundling the searchable content for all documents into the index for one page that only shows 10 or 20 documents at a time could be misleading when the document in question is on the 30th pagination within the block. So the solution would also need to directly link into a pagination of the block from the search results.

---

<div class="post-metadata">

**Author:** ![mesuva](https://forums.concretecms.org/user_avatar/forums.concretecms.org/mesuva/32/6303_2.png) [@mesuva](https://forums.concretecms.org/u/mesuva)\
**Post date:** [November 26, 2021, 9:29am UTC](https://forums.concretecms.org/t/including-the-document-library-block-in-search-engine/1706/4 "2021-11-26T09:29:37Z")

</div>

I had these thoughts as well, and perhaps these are the reason why we don’t have it in the core by default.

For what my client needed and has on their site it works fine, but yes, I could easily see how it would cause a processing overhead that could max out the indexing.