ElasticPress plugin sync and search issue

[sszaveljev]

Describe the bug
The ElasticPress Sync fails under certain circumstances, and even if it does work, admin post search still uses MySQL instead of ES due to errors

To Reproduce

• Set up an ElasticSearch server instance
• Start a .NET wordpress
• Install ElasticPress plugin - in the install wizard, Post Search and Protected Content must be enabled

The first problem arises when the content is successfully Synced into an ElasticSearch instance, and we try to perform searches in the admin post list.
Since the ElasticPress hooks into wp_query, these searches should use the ES instead of myssql, but, there's an error in the ElasticPress plugin, and it falls back to use SQL queries.

This is the error logged by ElasticPress:

Error
Fielddata is disabled on text fields by default. Set fielddata=true on [post_date] in order to load fielddata in memory by uninverting the inverted index. Note that this can however use significant memory. Alternatively use a keyword field instead.
Recommended Solution
It seems you saved a post without doing a full sync first because post_date is missing the correct mapping type. Delete all data and sync to fix the issue.

We managed to find out that the post_date field's type in the ES mapping is text instead of date, and we guess this causes thise error.

Unfortunately, we cannot change the mapping, it is automatically created by the ElasticPress during the first Sync.

This wrong type mapping seemingly only occurs with Peachpie Wordpress - when we use a vanilla PHP wordpress with the same versions(6.0.1 for WP and 4.4.1 for ElasticPress)

everything works just fine.

The other error:

We have a quite big post dataset in a legacy system, which we migrate into wordpress.

We use several meta fields for custom data.

We can migrate it successfully, the posts can be opened in the editor, the post list is searchable with the build-in SQL-based search, so everythings seems fine, though its quite slow - the dataset is hundreds of thousands of posts, actually that's the reason we try to use ElasticPress, to speed up the searches.

But, with this migrated post data, even the Sync fails.

(The first error with successful sync was produced with posts created in the wp, not on the migrated dataset)

The error log is the following:

System.IndexOutOfRangeException: Index was outside the bounds of the array.
2023-02-08 14:11:34 at Pchp.Library.DateTime.Scanner.GetNextToken()
2023-02-08 14:11:34 at Pchp.Library.DateTime.DateInfo.Parse(String datestr, DateTime refdate, TimeZoneInfo& localtz, String& error)
2023-02-08 14:11:34 at Pchp.Library.DateTime.DateTimeValue.Parse(Context ctx, String timestr, TimeZoneInfo timezone)
2023-02-08 14:11:34 at Pchp.Library.DateTime.DateTime.__construct(Context ctx, String datetime, DateTimeZone timezone)
2023-02-08 14:11:34 at Pchp.Library.DateTime.DateTimeFunctions.date_create(Context ctx, String time, DateTimeZone timezone)
2023-02-08 14:11:34 at ElasticPress.Indexable.prepare_date_meta_values(PhpValue meta_types, PhpValue meta_value) in /src/wp-content/plugins/elasticpress/includes/classes/Indexable.php:line 722
2023-02-08 14:11:34 at ElasticPress.Indexable.prepare_meta_value_types(PhpValue meta_value) in /src/wp-content/plugins/elasticpress/includes/classes/Indexable.php:line 698
2023-02-08 14:11:34 at <>.prepare_meta_value_types(Indexable , PhpValue )
2023-02-08 14:11:34 at prepare_meta_value_types#1(Closure , Context , Object , PhpValue[] )
2023-02-08 14:11:34 at Pchp.Library.Standard.Arrays.array_map(Context ctx, IPhpCallable map, PhpArray[] arrays)
2023-02-08 14:11:34 at ElasticPress.Indexable.prepare_meta_types(PhpValue meta)
2023-02-08 14:11:34 at ElasticPress.Indexable.Post.Post.prepare_document(PhpValue post_id)
2023-02-08 14:11:34 at ElasticPress.Indexable.bulk_index_dynamically(PhpValue object_ids)
2023-02-08 14:11:34 at CallSite.Target(Closure , CallSite , PhpValue , Context , PhpValue& )
2023-02-08 14:11:34 at ElasticPress.IndexHelper.index_next_batch()
2023-02-08 14:11:34 at ElasticPress.IndexHelper.index_objects()
2023-02-08 14:11:34 at ElasticPress.IndexHelper.process_sync_item()
2023-02-08 14:11:34 at ElasticPress.IndexHelper.full_index(PhpValue args)
2023-02-08 14:11:34 at CallSite.Target(Closure , CallSite , PhpValue , Context , PhpArray )
2023-02-08 14:11:34 at ElasticPress.Screen.Sync.action_wp_ajax_ep_index()
2023-02-08 14:11:34 at <>.action_wp_ajax_ep_index(Sync )
2023-02-08 14:11:34 at WP_Hook.apply_filters(PhpValue value, PhpValue args)
2023-02-08 14:11:34 at WP_Hook.do_action(PhpValue args)
2023-02-08 14:11:34 at wp-includes.plugin_php.do_action(Context , PhpValue hook_name, PhpValue[] arg)
2023-02-08 14:11:34 at wp-admin.admin-ajax_php.

(Context , PhpArray , Object this, RuntimeTypeHandle )
2023-02-08 14:11:34 at wp-admin.admin-ajax_php.`0(Context , PhpArray , Object this, RuntimeTypeHandle )
2023-02-08 14:11:34 at Pchp.Core.Context.ScriptInfo.Evaluate(Context ctx, PhpArray locals, Object this, RuntimeTypeHandle self)
2023-02-08 14:11:34 at Peachpie.AspNetCore.Web.RequestContextCore.ProcessScript(ScriptInfo script, String path_info)

That's what we have so far.

System information:
Peachpie version: Peachpie.Net.Sdk 1.1.4; WpDotNetVersion 6.0.1 rc010
(underneath the WP version is 6.0.1)
ElasticPress version: 4.4.1
ElasticSearch docker image: docker.elastic.co/elasticsearch/elasticsearch:7.1.0

[jakubmisek]

Thank you for reporting the bug!

Are you able to debug the instance? So we could get details about the System.IndexOutOfRangeException?

It would be helpful to inspect the arguments passed to the Pchp.Library.DateTime.DateInfo.Parse() method.