cannot build index
- kuangli0409Participant4 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.
wpsolrKeymaster4 years ago #18695Yes, 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.
kuangli0409Participant4 years ago #18697But what caused Algolia exceeds quota is the page which WPSolr generated. How to avoid it? Thx
kuangli0409Participant4 years ago #18699Yes, 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.
kuangli0409Participant4 years ago #18704When 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.)kuangli0409Participant4 years ago #18706OK. Let me try it. Thank you!
kuangli0409Participant4 years ago #18707Thank you for solving my problem. Is it possible to let all product’s content not searchable?
You must be logged in to reply to this topic.