Pages created with different Page Type do not appear in Search Index

Hello, I’ve discovered an issue on a ConcreteCMS v9 site I’m developing for a historical society. I’ve used the Migration Tool to generate hundreds of pages and all of the generated pages are missing from the search index. At first I thought it was something to do with the import, but now I think it’s more to do with the Page Type.

I manually created a page with the same Page Type as the imported pages and sure enough, it does NOT appear in search index.

If I go through the same process and just choose ‘Page’ page type, it appears in seach index right away.

It’s helpful to determine that the Page Type is probably the root of the issue. However, I can’t find any settings that would prevent one Page Type from having it’s pages excluded from search index.

There are hundreds of pages missing from the PageSearchIndex table and the common factor seems to be the page type.

Any ideas?

did you try reindexing content in the systems and settings tasks?

1 Like

Yes, I’ve tried rebuilding page search index. It does not solve the issue.

Take a look at the page attributes and see if it has the exclude from search ticked.

Yes, I’ve looked at the page attributes, there are no added attributes, including no added ‘exclude from search index’ attribute. It’s very peculiar, the index is just skipping pages with page types I’ve setup. Could this be related to using Atomik theme somehow?

I’ve just done another test. It may not be just the Page Type. I changed one of the pages generated by the Migration Tool to Page Type ‘Page’ and re-ran the index. It still does not appear in the Search Index.

Two behaviours I’ve found that lead to not appearing in Search Index:

  • If I manually create a page and set the Page Type to one of my new page types, it doesn’t appear in Search Index after re-indexing.
  • If I import pages with Migration Tool, they do not appear in Search Index. Even if I change their Page Type to ‘Page’ after import and re-index.

I forget how the migration tool works, so this question may not be relevant. I assume that the Page Type you created for those imported pages has one or more templates. As you know, the page templates contain the areas, which are ultimately what Concrete picks up to index. Can you see the page templates listed under Pages & Themes → Page Templates? How about under System & Settings → Search Index. Are the area names from your page templates listed there?

Also, just out of curiosity, did you manually create your new Page Type, or did that get imported with the Migration Tool?

Thanks for the reply. I’m using the ‘Full’ page template, with a pair of new page types. I manually created the page types before creating the pages with Migration Tool. All of the content is in the ‘Main’ page areas, which are checkmarked in ‘Search Index’ page in the ‘System & Settings’ section. Same page area that is used throughout site. Content is indexed on other pages, just not the pages created with ‘Migration Tool’ and also not the pages manually created using any of the two new page types.

I just did a test. I created a new page using the Migration Tool with the Page Type ‘Page’, moved it to the same path as the others I’ve been trying, then ran the re-index. It did successfully add this page to the search index table. This leads me to believe once more that there’s some kind of fault with the page type.

If I then change the page type on this new test page to one of my newly created page types, re-run the indexing, it still remains in the search index table.

The main reason I’m using a custom page type for the imported pages is so it sets up the default blocks I need on the pages. Manually adding all the blocks to each page sounds painful.

I think I found something useful in ‘Failed Messages’ under ‘Automation’

“Handling “Concrete\Core\Page\Command\ReindexPageTaskCommand” failed: Target class [Application\Block\ExpressEntryDetail\EntityManager] does not exist.”

Lots of these errors.

This is related to some custom code in the express_detail block that ‘andrew’ helped me develop.