V20.1

  • ekimunal
    Participant
    # 1 month, 3 weeks ago

    Settings exist yet new post or update fires warning:
    “(WPSOLR) Error while indexing this post type:

    The search index is missing. Configure one in the Solr indexes, and select it in the default search Solr index list.”

    I can confirm settings already exist and re saving them verifies settings:
    admin.php?page=solr_settings&tab=solr_option
    admin.php?page=solr_settings&tab=solr_indexes

    Has both staging and prod settings. Removed prod settings and left staging only. Saved it again.
    Still same warning in posts.

    Any idea where to look?

    wpsolr
    Keymaster
    # 1 month, 3 weeks ago

    In screen 2.1, you should select your index in the drop-down list.

    ekimunal
    Participant
    # 1 month, 3 weeks ago

    Yeah setting is configured yet it still warns, I saved it again and again to make sure it is saving. We updated from 20.0 to 20.1

    wpsolr
    Keymaster
    # 1 month, 3 weeks ago

    Can you send here a screen shot of your 2 screens: 2.1, index settings?

    ekimunal
    Participant
    # 1 month, 3 weeks ago

    https://gyazo.com/b243918e78009807358a5852a06eb9d7

    Index is configured, verified by saving again, and set in 2.1

    wpsolr
    Keymaster
    # 1 month, 3 weeks ago

    Can you index the same index in screen “3. Send your data”?

    ekimunal
    Participant
    # 1 month, 3 weeks ago

    I have a warning on indexing because staging server is blocking flushall requests. I will work on that in a little bit. Do you think indexing is relevant to settings not finding themselves on post save?

    wpsolr
    Keymaster
    # 1 month, 3 weeks ago

    No.

    ekimunal
    Participant
    # 1 month, 3 weeks ago

    What might cause settings to fail to be found? Any pointers for me to look at?

    wpsolr
    Keymaster
    # 1 month, 3 weeks ago

    If nothing appears in debug.log, or in js console errors, no.

    Except perhaps deleting your index configurations, checking that the 2.1 list is empty, and creating a new index configuration.

    ekimunal
    Participant
    # 1 month, 3 weeks ago

    Thank you for immediate response and assistance.

    This update is on a 45 site multisite environment, if possible I would love to avoid removing settings for each site and reentering. I tried to do it on a single site, removed all settings, reentered. Indexing works yet on post update or new post, it shows warning.

    wpsolr
    Keymaster
    # 1 month, 3 weeks ago

    Indexing works yet

    Probably not. When an error occurs during search, WPSOLR goes back to the default WP search. But then, you should see an error in Chrome JS console.

    ekimunal
    Participant
    # 1 month, 1 week ago

    Looking at the code to debug things:

    This is a multi site environment. And somehow sites are getting options/configuration from other sites:

    error_log(“Solr_indexes:” . print_r($solr_indexes,1));
    error_log(“Solr_indice:” . print_r($solr_index_indice,1));

    Sample below:
    [18-Dec-2019 21:52:40 UTC] Solr_indexes:Array >> Called from Blog10 somehow gets other site (Blog2)
    (
    [6470A573416D46226F852F8E1FB7CC96] => Array
    (Data Removed)
    )

    [18-Dec-2019 21:52:40 UTC] Solr_indice:35E2ACC9D1CEA63734037E5A2C98549F >> ACTUAL INDEX FROM SETTINGS(Blog10)
    [18-Dec-2019 21:52:40 UTC] Solr_index set: As Index ID does not match, it cant find index.
    [18-Dec-2019 21:52:41 UTC] Options:Array >> Blog10 Options Return Blog2 Options.
    (
    [solr_indexes] => Array
    (
    [6470A573416D46226F852F8E1FB7CC96] => Array
    (
    [index_engine] => engine_solr
    [index_name] => 680-stage
    )))

    [18-Dec-2019 21:52:41 UTC] Solr_index expected indice:35E2ACC9D1CEA63734037E5A2C98549F
    [18-Dec-2019 21:52:41 UTC] get_indexes:Array
    [6470A573416D46226F852F8E1FB7CC96] => Array returned wrong index. This belongs to Blog10.

    Looking at this, any idea why and how this is happening?

    We updated to Version 20.1 which was using a zip file for settings, then after issues we rolled back to version 20, still not working. Maybe somehow settings got corrupted, reconfiguring index does not fix it. I looked at also tables; here are options from tables, I hope I am looking at correct key:
    ROW : wpsolr_solr_indexes

    Blog2:
    a:1:{s:12:”solr_indexes”;a:1:{s:32:”6470A573416D46226F852F8E1FB7CC96″;a:16:{s:23:”managed_solr_service_id”;s:0:””;s:10:”index_type”;s:0:””;s:12:”index_engine”;s:11:”engine_solr”;s:10:”index_name”;s:9:”680-stage”;s:11:”index_label”;s:0:””;s:14:”index_protocol”;s:5:”https”;s:10:”index_host”;s:21:”us-east-1.websolr.com”;s:10:”index_port”;s:3:”443″;s:10:”index_path”;s:18:”/solr/keyRemoved”;s:26:”index_elasticsearch_shards”;s:1:”5″;s:28:”index_elasticsearch_replicas”;s:1:”1″;s:23:”index_solr_cloud_shards”;s:1:”1″;s:35:”index_solr_cloud_replication_factor”;s:1:”1″;s:32:”index_solr_cloud_max_shards_node”;s:1:”1″;s:9:”index_key”;s:0:””;s:12:”index_secret”;s:0:””;}}}

    Blog10:
    a:1:{s:12:”solr_indexes”;a:1:{s:32:”35E2ACC9D1CEA63734037E5A2C98549F”;a:16:{s:23:”managed_solr_service_id”;s:0:””;s:10:”index_type”;s:0:””;s:12:”index_engine”;s:11:”engine_solr”;s:10:”index_name”;s:23:”citynews-toronto-wp-npe”;s:11:”index_label”;s:0:””;s:14:”index_protocol”;s:5:”https”;s:10:”index_host”;s:21:”us-east-1.websolr.com”;s:10:”index_port”;s:3:”443″;s:10:”index_path”;s:18:”/solr/keyRemoved”;s:26:”index_elasticsearch_shards”;s:1:”5″;s:28:”index_elasticsearch_replicas”;s:1:”1″;s:23:”index_solr_cloud_shards”;s:1:”1″;s:35:”index_solr_cloud_replication_factor”;s:1:”1″;s:32:”index_solr_cloud_max_shards_node”;s:1:”1″;s:9:”index_key”;s:0:””;s:12:”index_secret”;s:0:””;}}}

    ekimunal
    Participant
    # 1 month, 1 week ago

    Indexing works on both blogs to expected indices if run manually from backend.

    Indexing works when posts are posted from Blog2, new posts are indexed.

    Indexing somehow gets Blog2 settings on all other blogs on the network on the post level.
    Trying to add a new post or update a post tries indexing on the wrong index and fails.

    ekimunal
    Participant
    # 1 month, 1 week ago

    function __construct() {
    $this->_options = self::get_option_data( self::OPTION_INDEXES, [] );
    error_log(“Options:” . print_r($this->_options,1));
    }

    Somehow wrong options are returned or common options used for all sites on blog level.

    Thanks a lot for your time and assistance on this.

    If I resolve anything, I will share here immediately.

Viewing 15 posts - 1 through 15 (of 23 total)

You must be logged in to reply to this topic.