cannot build index

  • wpsolr
    Keymaster
    4 years ago #18693

    If you uncheck option “Index custom fields” in screen 2.2, your custom fields will not be added to your document content. You’ll need then to reindex all your documents.

    kuangli0409
    Participant
    4 years ago #18694

    Yes, I uncheck already. But it exceeds quota still. Or, can I remove all Taxonomies first, after index done, then click Taxonomies?

    However, this way can help me to index the current products. However, when I add products in the future, I think new products may have the same problem. Besides, I notice that in the Algolia, almost all contents have three copy (in different language, something like this. However, I have only one language. I don’t use WPML or any similar plugins. The only translate plugin is GTranslate, which will not create this new term.

    wpsolr
    Keymaster
    4 years ago #18695

    Yes, your limit of 10K could be a long-term problem:
    https://www.algolia.com/doc/guides/sending-and-managing-data/prepare-your-data/in-depth/index-and-records-size-and-usage-limitations/

    Your other indexes are probably replicas of your main index, created automatically by WPSOLR to perform sorts. In Algolia, each sorted field requires its own index for performance/optimisation reasons:
    https://www.algolia.com/doc/guides/managing-results/refine-results/sorting/#backend-implementation-replicas

    • This reply was modified 4 years ago by wpsolr.
    kuangli0409
    Participant
    4 years ago #18697

    But what caused Algolia exceeds quota is the page which WPSolr generated. How to avoid it? Thx

    wpsolr
    Keymaster
    4 years ago #18698

    Edit the page, and check the WPSOLR meta box “Do not search”. The page will not be indexed.

    kuangli0409
    Participant
    4 years ago #18699

    Yes, I did. But this search page really causes the problem.

    I try to use new slug to create a new search page, then

    Posts excluded from the index:<br><b>184073,184086</b><br><br>******** DEBUG ACTIVATED – Beginning of new loop (batch size) *******<br><br>******** DEBUG ACTIVATED – Query documents from last post date *******<br><br>Query:<br><b>SELECT ID, post_modified, post_parent, post_type FROM wpyuepu_posts AS A WHERE ((post_modified = ‘2020-03-18 01:32:57’ AND ID > 390) OR (post_modified > ‘2020-03-18 01:32:57’)) AND ( post_status IN (‘publish’) AND ( post_type = ‘product’ ) ) AND ID NOT IN (184073,184086) ORDER BY post_modified ASC, ID ASC LIMIT 1</b><br><br>Last post date:<br><b>2020-03-18 01:32:57</b><br><br>Last post ID:<br><b>390</b><br><br>Post to be sent:<br><b>{ “id”: 378, “PID”: 378, “type”: “product”, “meta_type_s”: “post_type”, “displaymodified”: “2020-03-18T01:42:14Z”, “title”: “\u5b8c\u5168\u97f3

    ——————————–
    id: 184073 and 184086 are both search page (mydomain/search-wpsolr and mydomain/searhwp)

    However, both pages are “页面 are not indexable. You can change that in wpsolr settings.”

    So I don’t know how to avoid passing this page’s information to Algolia.

    wpsolr
    Keymaster
    4 years ago #18700

    What makes you think the search pages are indexed?

    kuangli0409
    Participant
    4 years ago #18704

    When index contents to Algolia, it shows the error message as above. In the first line, the problems occurs at first line “184073,184086”, which you asked me what it was, are the search pages which WPSolr generate. And the last four lines are

    “modified_ds_i”: 14, “comments”: [], “numcomments”: 0, “categories_str”: [], “categories_t”: [], “flat_hierarchy_categories_str”: [], “non_flat_hierarchy_categories_str”: [], “tags”: [], “tags_t”: [], “categories”: [] }</b><br><br>{“nb_results”:0,”status”:0,”message”:”(Algolia) "Record at the position 0 objectID=378 is too big size=14942 bytes. Contact us if you need an extended quota"\n”,”indexing_complete”:false}

    The contents in this error message are related to search page. So it is weird for me.
    (In the first error message, there is only 184073, which you ask me what it is. This is mydomain/search-wpslr). I don’t know if this is true, so let WPSolr generate another search page, then that is 184086, which occurs in the error message again.)

    wpsolr
    Keymaster
    4 years ago #18705

    The debug shows that 184073,184086 are excluded from the index, as they should.

    If you look further in the debug message, you will find the details of the product currently indexed with the error.

    kuangli0409
    Participant
    4 years ago #18706

    OK. Let me try it. Thank you!

    kuangli0409
    Participant
    4 years ago #18707

    Thank you for solving my problem. Is it possible to let all product’s content not searchable?

    wpsolr
    Keymaster
    4 years ago #18709

    It is not possible to prevent product descriptions to be indexed.

Viewing 12 posts - 16 through 27 (of 27 total)

You must be logged in to reply to this topic.