Extension talk:CirrusSearch

Discussion related to the CirrusSearch MediaWiki extension.

See also the open tasks for CirrusSearch on phabricator.

How to search for ASCII translated Umlaut handling in URLs in source code using quotes?

I have template source code using external URLs. Some contain ASCII-translated Umlauts like fl%C3%BCgel for flügel.

When searching via API using insource and quotes it doesn't find it.

insource:"/path/fl%C3%BCgel"

It only finds it without quotes insource:/path/fl%C3%BCgel

92.50.65.235 16:59, 28 January 2025 (UTC)

Elasticsearch

Looking on the Elasticsearch website and having trouble. Elastic Cloud costs a fortune and Self-managed Elasticsearch options are "not suitable for production use". What gives? 81.151.8.175 15:48, 6 April 2025 (UTC)

If you're looking at documentation relating to running a single Elasticsearch instance, then it's "not suitable for production use" because there's no failover if that server goes down (e.g. if you need to reboot it). However, if you're fine with that, then running your own server is perfectly fine. ~2025-43626-1 (talk) 11:26, 21 August 2025 (UTC)

Get CirrusSearch work for chinese

Hi all, I have a site that runs on 1.43, most of the contents are simplified & traditional chinese, and I am trying to get CirrusSearch + Elasticsearch work, but still struggling..

Basically I want to make it work just like https://zh.wikipedia.org/ (not sure if it is using the same approach CirrusSearch + Elasticsearch?) The primary issue I currently have is that, for e.g. if I search for "方济各", I want the results to only show pages that has this phrase "方济各" (like if you search for the same on wikipedia: https://zh.wikipedia.org/w/index.php?search=%E6%96%B9%E6%B5%8E%E5%90%84&title=Special%3A%E6%90%9C%E7%B4%A2&profile=advanced&fulltext=1&ns0=1&searchToken=68qlm8r96e8225klwzw6fkjyd), not ["方" or "济" or "各"] (which is what it currently is doing).. Here is my current test instance if you want to try it: http://44.199.64.14/w/index.php?search=%E6%96%B9%E6%B5%8E%E5%90%84&title=Special%3A%E6%90%9C%E7%B4%A2&wprov=acrw1_-1&ns0=1&ns1=1&ns14=1&ns4100=1&ns4200=1

Here are what I have done so far:

Installed Elasticsearch 7.10.2

Installed extension CirrusSearch and Elastic

Installed Elasticsearch plugin: analysis-ik(IK Analyzer), and analysis-stconvert

I have also modified the /extensions/CirrusSearch/includes/Maintenance/AnalysisConfigBuilder.php file to include the reference to IK analyzer.

I also just read this page User:TJones (WMF)/Notes/Chinese Analyzer Analysis, that "The short version is that SmartCN+STConvert did the best on all the corpora", so... does this mean out of box (SmartCN+STConvert) it should be working fine for chinese, and I don't need IK analyszer plugin? If the SmartCN+STConvert is enough, what I am missing to make it work like https://zh.wikipedia.org/w/index.php?search=%E6%96%B9%E6%B5%8E%E5%90%84&title=Special%3A%E6%90%9C%E7%B4%A2&profile=advanced&fulltext=1&ns0=1&searchToken=68qlm8r96e8225klwzw6fkjyd?

Thank you everyone! Paulxu20 (talk) 03:12, 16 May 2025 (UTC)

Just some updates after discussion with @DCausse (WMF) in IRC:

Looks like if just to get it working like zh.wikipedia.org, I dont need the IK analyzer, so I am now reverting my code changes to AnalysisConfigBuilder.php back to the OOB version.

I do have a question now - is that do I need to install the "analysis-icu" plugin to make the chinese search work well? it looks like so but want to double check. Paulxu20 (talk) 20:21, 16 May 2025 (UTC)

Hi, analysis-icu is a useful plugin and it's generally a good idea to install it but whether or not it is useful for Chinese? I would defer this to @TJones (WMF) to answer. DCausse (WMF) (talk) 09:28, 19 May 2025 (UTC)

Thank you @DCausse (WMF) @TJones (WMF), I do have analysis-icu installed along with a few other plugins, here is the list of all plugins currently installed:

:::name           component          version
:::ip-172-26-3-55 analysis-icu       7.10.2
:::ip-172-26-3-55 analysis-ik        7.10.2
:::ip-172-26-3-55 analysis-smartcn   7.10.2
:::ip-172-26-3-55 analysis-stconvert 7.10.2
:::ip-172-26-3-55 extra              7.10.2-wmf12
:::

I have put all the stuff I did on this page: http://44.199.64.14/wiki/CirrusSearch_Test, including the plugins I installed, the LocalSettings.php, the command I ran, etc. After a week of trying and digging I think I am making some progress, for example now when searching for "方济各", it does find the page (http://44.199.64.14/wiki/TestPage2) which contains the whole phrase and show it on top of the search results, however, at the same time the search results are still showing other pages that either has "方", or "济", or "各". Not sure what I am missing..

Really appreciate all your help! Paulxu20 (talk) 13:03, 19 May 2025 (UTC)

Hello @DCausse (WMF) @TJones (WMF)

Just to follow up after more digging today, I realized that zh.wikipedia.org's search is also not working well.. it is just that there are many pages contains "方济各" and they are ranked high, so they are being list on top of the search results, but when I check more pages, for e.g. 1500 pages later (https://zh.wikipedia.org/w/index.php?limit=500&offset=1500&profile=default&search=%E6%96%B9%E6%B5%8E%E5%90%84&title=Special:%E6%90%9C%E7%B4%A2&ns0=1), it is also showing pages that has nothing to do with the phrase "方济各", for e.g. this page "https://zh.wikipedia.org/zh-cn/%E7%BE%8E%E6%B5%8E%E7%A4%81" is in the search result, it is an island name and absolutely has nothing to do with "方济各" (who is the name of Pop who just passed away).

What should happen, is that when searching for "方济各", it should be the combined results of below two queries (with duplicates removed):

• 1- https://zh.wikipedia.org/w/index.php?search=%22%E6%96%B9%E6%B5%8E%E5%90%84%22&title=Special%3A%E6%90%9C%E7%B4%A2&profile=advanced&fulltext=1&advancedSearch-current=%7B%22fields%22%3A%7B%22phrase%22%3A%22%5C%22%E6%96%B9%E6%B5%8E%E5%90%84%5C%22%22%7D%7D&ns0=1
• 2- https://zh.wikipedia.org/w/index.php?search=%22%E6%96%B9%E6%BF%9F%E5%90%84%22&title=Special%3A%E6%90%9C%E7%B4%A2&profile=advanced&fulltext=1&advancedSearch-current=%7B%22fields%22%3A%7B%22phrase%22%3A%22%5C%22%E6%96%B9%E6%BF%9F%E5%90%84%5C%22%22%7D%7D&ns0=1

The first one is the query when doing exact match for simplified Chinese "方济各", and the second one is the query to exact match for traditional Chinese "方濟各", which is the same phrase "方济各" but just traditional Chinese.

So there are two problems here:

• 1) should only show pages that contains the exact phrase "方济各"
• 2) should be able to show results for both simplified Chinese and traditional Chinese, irrespective what form the original keyword is (simplified or traditional)

Let me know if this makes sense. Paulxu20 (talk) 20:28, 19 May 2025 (UTC)

Just to add - behavior wise, I think it should work just like how it works out of box without using CirrusSearch (that is native SQL query?), but the problem with that is that it is much slower than Elasticsearch.. Paulxu20 (talk) 20:34, 19 May 2025 (UTC)

With @DCausse (WMF)'s help (Big thank you!), I was able to get it working for Chinese, below are the details just in case anyone needs it:

=== Install related Mediawiki extensions: Elastica and CirrusSearch ===

LocalSettings.php:

wfLoadExtension( 'Elastica' );
wfLoadExtension( 'CirrusSearch' );
$wgSearchType = 'CirrusSearch';

$wgCirrusSearchServers = [ 'localhost' ];
$wgCirrusSearchIndexBaseName = 'mediawiki';
$wgCirrusSearchWikimediaExtraPlugin = true;
$wgCirrusSearchLanguage = 'zh';
$wgCirrusSearchUseIcuFolding = true;
$wgCirrusSearchUseIcuTokenizer = true;
$wgCirrusSearchEnableRegex = true;

// Strongly boost exact phrase
$wgCirrusSearchPhraseRescoreBoost = 500.0;

// Rescore more top candidates    
$wgCirrusSearchPhraseRescoreWindowSize = 20;

// Only match strict phrases
$wgCirrusSearchPhraseSlop = [ 'precise' => 1, 'default' => 0, 'boost' => 0 ];

$wgCirrusSearchWikimediaExtraPlugin = [ 'token_count_router' => true ];

==== Install analysis-icu ====

sudo /usr/share/elasticsearch/bin/elasticsearch-plugin install analysis-icu

==== Install analysis-smartcn ====

sudo /usr/share/elasticsearch/bin/elasticsearch-plugin install analysis-smartcn

==== Install analysis-stconvert ====

sudo /usr/share/elasticsearch/bin/elasticsearch-plugin install https://release.infinilabs.com/analysis-stconvert/stable/elasticsearch-analysis-stconvert-7.10.2.zip

==== Install extra ====

sudo /usr/share/elasticsearch/bin/elasticsearch-plugin install https://repo1.maven.org/maven2/org/wikimedia/search/extra/7.10.2-wmf12/extra-7.10.2-wmf12.zip

==== Then restart elasticsearch ====

sudo systemctl restart elasticsearch

==== Verify plugins are installed successfully ====

curl -X GET "localhost:9200/_cat/plugins?v"

name           component          version ip-172-26-3-55 analysis-icu       7.10.2 ip-172-26-3-55 analysis-ik        7.10.2 ip-172-26-3-55 analysis-smartcn   7.10.2 ip-172-26-3-55 analysis-stconvert 7.10.2 ip-172-26-3-55 extra              7.10.2-wmf12

==== List all current indexes ====

curl -s "localhost:9200/_cat/indices?v" | less -S

==== Recreate index ====

Updates the configuration of the Elasticsearch index used by MediaWiki search, and rebuilds (reindexes) the index with a new configuration. Note that this does NOT populate (reindex) wiki content into the index. It just creates the “container” and defines how data should be indexed. It is ForceSearchIndex.php that Populates (or repopulates) the Elasticsearch index with content from your wiki — essentially "reindexing" the content pages.

php UpdateSearchIndexConfig.php --reindexAndRemoveOk --indexIdentifier now

or:

php UpdateSearchIndexConfig.php --startOver

You should run this after:

• Changing your analyzer settings in CirrusSearch config (like adding a custom IK analyzer).
• Changing the way search behaves (e.g., adding language support or synonyms).
• Installing plugins like stconvert and updating CirrusSearch config to use them.

After the command is done, check indexes again, should see the indexes are created successfully:

curl -s "localhost:9200/_cat/indices?v" | less -S

=== Other Resources ===

• Elasticsearch plugins can be installed: https://gerrit.wikimedia.org/r/plugins/gitiles/operations/software/elasticsearch/plugins/+/b39cf71d8c9d8c0c0a9326eedeabbc5003f4ee60/debian/plugin_urls.lst
• Wikipedia.org cirrus-settings-dump: https://zh.wikipedia.org/w/api.php?action=cirrus-settings-dump
• Wikipedia.org cirrus-mapping-dump: https://zh.wikipedia.org/w/api.php?action=cirrus-mapping-dump
• Wikipedia.org cirrus-config-dump: https://zh.wikipedia.org/w/api.php?action=cirrus-config-dump
• Mediawiki all settings: https://noc.wikimedia.org/wiki.php?wiki=zhwiki&format=json

Paulxu20 (talk) 11:27, 25 May 2025 (UTC)

Autocomplete not updating with new page titles

When I create a new page, I do not see it when I start typing on search bar (even after hours). Job queue empty (cron job set up ever 3 mins).

Using

wfLoadExtension( 'Elastica' );
wfLoadExtension( 'CirrusSearch' );
$wgCirrusSearchUseIcuFolding = 'yes';
$wgSearchType = 'CirrusSearch';

MediaWiki	1.39.12
PHP	8.3.20 (fpm-fcgi)
MariaDB	10.6.21-MariaDB
ICU	67.1
Lua	5.1.5
Elasticsearch	7.10.2

Spiros71 (talk) 12:17, 18 May 2025 (UTC)

@Spiros71 Few causes to explore:

• You are using the Completion suggester ($wgCirrusSearchUseCompletionSuggester), this index specialized to do autocompletion is not updated in realtime but via the maint script UpdateSuggesterIndex.php
• You may some issues writing to elasticsearch, is this page findable using Special:Search? If yes I'm not sure what could have happened and might require more investigations. If no you might get some insights from mediawiki logs indicating why the had page failed to get indexed?

Few techniques to help debugging:

• See how the page is indexed: append ?action=cirrusDump to the page URL
• See the query sent to elasticsearch: append &cirrusDumpQuery=yes

DCausse (WMF) (talk) 09:41, 19 May 2025 (UTC)

Thank you David,

There was no $wgCirrusSearchUseCompletionSuggester = 'yes';  in LocalSettings.php (despite that, it did work without issues for quite some time). I could not find any instruction in the extension readme as for the necessity of the above (nor that it would be a good idea to run on a cron also). I ended up doing full reindexing:

php extensions/CirrusSearch/maintenance/UpdateSearchIndexConfig.php --startOver
php extensions/CirrusSearch/maintenance/ForceSearchIndex.php --skipLinks --indexOnSkip
php extensions/CirrusSearch/maintenance/ForceSearchIndex.php --skipParse
php extensions/CirrusSearch/maintenance/UpdateSuggesterIndex.php --recreate
php maintenance/runJobs.php --memory-limit=max

I also ran the below (as I had yellow status and 1 unassigned shard):

curl -X PUT "localhost:9200/_all/_settings" \
-H 'Content-Type: application/json' \
-d '{"index": {"number_of_replicas": 0}}'

# …and make it the default for any new index CirrusSearch creates
curl -X PUT "localhost:9200/_cluster/settings" \
-H 'Content-Type: application/json' \
-d '{
"persistent": { "index.number_of_replicas": 0 }
}'

Spiros71 (talk) 10:45, 19 May 2025 (UTC)

The completion suggester is optional and completion should have worked even without having it enabled, sorry if my comment made it sound like it was required.

Documentation about the completion is a bit sparse I agree, you might find some in docs/settings.txt and Extension:CirrusSearch/CompletionSuggester. DCausse (WMF) (talk) 21:10, 19 May 2025 (UTC)

/rest.php/v1/search/title does not show main namespace pages in response

Hi everyone. I'm running MW 1.43, and while I'm setting up CirrusSearch, I noticed that search responses between /wiki/Special:Search and the API endpoint GET /w/rest.php/v1/search/title differ in that the API endpoint does not return back any main namespace pages. I point this out since Vector 2022 uses the /w/rest.php/v1/search/title endpoint to fetch search results before the user submits their query. I can confirm that searching on /wiki/Special:Search works as intended. Has anyone else experienced this? Help is always appreciated.

I am running on CirrusSearch commit dfa4f2a and using ElasticSearch 7.10.2. Here is the snippet of my LocalSettings.php:

wfLoadExtension( 'CirrusSearch' );
wfLoadExtension( 'Elastica' );

$wgSearchType = 'CirrusSearch';
$wgCirrusSearchRescoreProfile = 'classic_noboostlinks';
$wgCirrusSearchUseCompletionSuggester = 'yes';
$wgCirrusSearchPhraseSuggestUseText = true;
$wgCirrusSearchCompletionSuggesterHardLimit = 200;
$wgCirrusSearchFragmentSize = 200;
$wgCirrusSearchWeights = [
        "title" => 20,
        "redirect" => 15,
        "category" => 8,
        "heading" => 5,
        "opening_text" => 3,
        "text" => 1,
        "auxiliary_text" => 0.5,
        "file_text" => 0.5
];
$wgNamespacesToBeSearchedDefault = [
        NS_MAIN => true,
        NS_USER => true,
        NS_PROJECT => true,
        NS_FILE => true,
        NS_TEMPLATE => true,
        NS_HELP => true,
        NS_CATEGORY => true,
];
// NS_MAIN defaults to 1
$wgCirrusSearchNamespaceWeights = [
        NS_USER => 0.1,
        NS_PROJECT => 0.1,
        NS_FILE => 0.05,
        NS_MEDIAWIKI => 0.05,
        NS_TEMPLATE => 0.05,
        NS_HELP => 0.1,
        NS_CATEGORY => 0.05
];

Product	Version
MediaWiki	1.43.3
ICU	70.1
MySQL	8.0.43-0ubuntu0.22.04.1
Lua	5.1.5
Pygments	2.17.2
Elasticsearch	7.10.2

Nydauron (talk) 02:27, 17 August 2025 (UTC)

A couple notes. Special:Search and /w/rest.php/v1/search/title are two different backend search implementations. Special:Search is fulltext, and title search is just searching titles. In the default configuration they work off the same search index, but that can be changed. Specificially you have set:

$wgCirrusSearchUseCompletionSuggester = 'yes';

This is a special form of title search that requires it's own backing search index (which allows it to better handle fuzzy queries). That index is not updated in real time, at WMF we build it once a day via the extensions/CirrusSearch/maintenance/UpdateSuggesterIndex.php maintenance script. You will likely either need to setup some automation to run this regularly, or disable the completion suggester. EBernhardson (WMF) (talk) 15:07, 19 August 2025 (UTC)

Migration from ES to OpenSearch

I was following the instructions on the manual and used a wmf docker image for elasticsearch. Now I see the following message

       *** ElasticSearch support is deprecated and will be End-of-Life in the next release. Upgrading to OpenSearch will be required. ***
       Scanning available plugins...

As I will probably need to rebuild my search index anyhow, I am wondering if there is also a docker image of the OpenSearch image that is used by wmf (with the custom extensions for fulltext search etc)? Physikerwelt (talk) 14:09, 3 December 2025 (UTC)

@Physikerwelt, yes the cirrussearch-opensearch-image can be used for this, please see MediaWiki-Docker/Configuration_recipes/OpenSearch as well. DCausse (WMF) (talk) 09:30, 13 January 2026 (UTC)

Opensearch on MediaWiki 1.43?

Hello,

We are trying to move from ES to Opensearch. Can you update 1.43 branch to support at least Opensearch 1.3? @DCausse (WMF) @TJones (WMF)

Thanks! Willyedoo (talk) 10:04, 9 January 2026 (UTC)

@Willyedoo would it be possible for you to test if things work OK if you simply backport https://gerrit.wikimedia.org/r/c/mediawiki/extensions/CirrusSearch/+/1093978 to 1.43, hopefully it's enough to support opensearch 1.3? DCausse (WMF) (talk) 09:43, 13 January 2026 (UTC)

Hello @Willyedoo,

Thanks for the question — a bit of context to clarify the situation.

• MediaWiki 1.43 is the current LTS, but it predates our OpenSearch migration work.
• MediaWiki 1.45 is the last release supporting both Elasticsearch and OpenSearch.
• MediaWiki 1.46 (out in May) supports OpenSearch 1.3 only; Elasticsearch support is removed there.

The next LTS after 1.43 is not planned yet (historically, likely late this year).

So at the moment there is no officially supported “LTS + OpenSearch” combination. If you need both, the options are to stay on 1.43 with Elasticsearch for now, or move to 1.46 and accept a non-LTS release until the next LTS.

That said, the suggested approach of backporting

https://gerrit.wikimedia.org/r/c/mediawiki/extensions/CirrusSearch/+/1093978 to the 1.43 branch may be sufficient to run with OpenSearch 1.3. This is not something we’ve tested or committed to support, but if you’re willing to try it and report back, that feedback would be very useful.

In short: official OpenSearch support starts with 1.46; OpenSearch on 1.43 is currently best-effort / experimental. PFischer-WMF (talk) 10:23, 13 January 2026 (UTC)

Hello and thank you all for these intereting informations.

I will test and give you update ASAP.

Regards! Willyedoo (talk) 08:33, 14 January 2026 (UTC)

Some updates to the docs wouldn't hurt. Right now if someone reads the extension page here it would seem that the switch to OpenSearch is still a long way off (the doc linked at the top wasn't updated since 2024) other than the hint in Special:Version on WMF wikis pointing to OpenSearch 1.3, which (if taken literally) is deprecated upstream anyway. It's not entirely clear (to me anyway) how one is supposed to install OpenSearch itself on a non-WMF wiki; from my end it looks like another messy process like the one to install Extension:Chart. In an ideal world OpenSearch would become part of MediaWiki core in 1.46 or soon afterwards (or become another extension), rendering obsolete the mess of Advanced Search/CirrusSearch/Elasticsearch/Elastica. Tactica (talk) 12:15, 14 January 2026 (UTC)

undocumanted Redis params

The documentation for this extension gives an example of a $wgJobTypeConf configuration for job queues in Redis, but names two undocumented parameters :

checkDelay (true): I can't find that anywhere in MediaWiki's code

order (fifo)

Could anyone clarify? Rand(1,2022) (talk) 16:01, 1 March 2026 (UTC)

I poked around and this looks like the docs are outdated:

I found a patch from 2014 that removed the need to set checkDelay, since then the redis jobqueue always supports delayed jobs, no configuration necessary.

For order, the redis jobqueue reports it supports either `timestamp` or `fifo` ordering, and that optimal ordering is `fifo`. I'm not finding where this is documented outside of brief example mentions in Manual:$wgJobTypeConf, but all JobQueue implementations accept an `order` parameter. If unset it will default to the optimal order reported by the specific implementation.

The tl/dr is that both values are now the default values and shouldn't need to be directly configured.

I've submitted a patch to CirrusSearch to remove mention of these arguments, since they are already the defaults.

Thanks for noticing, i'm sure others have wondered but not said anything about these for years. Ebernhardson (talk) 18:34, 3 March 2026 (UTC)

Thanks. In the meantime, I updated https://www.mediawiki.org/wiki/Manual:$wgJobTypeConf#Redis to remove other parameters no longer in use. It does not look like the 'JobQueueRedis' class accepts `order` (this class extends 'JobQueue' but overrides the set of parameters with a more restricted one). Rand(1,2022) (talk) 19:28, 3 March 2026 (UTC)

OpenSearch 1.3 installation no longer possible

I upgraded my MediaWiki from 1.43.1 to 1.45.1. To use Extension:CirrusSearch with OpenSearch I tried to install OpenSearch following instructions at https://docs.opensearch.org/1.3/install-and-configure/install-opensearch/debian/ . The OpenPGP signature is no longer valid. After imported it to a keyring file "apt-get update" will not work with OpenSearch. Error message is:

W: OpenPGP signature verification failed: https://artifacts.opensearch.org/releases/bundle/opensearch/1.x/apt stable InRelease: Sub-process /usr/bin/sqv returned an error code (1), error message is: Signing key on C5B7498965EFD1C2924BA9D539D319879310D3FC is not bound:            No binding signature at time 2024-12-11T21:50:47Z   because: Policy rejected non-revocation signature (PositiveCertification) requiring second pre-image resistance   because: SHA1 is not considered secure since 2026-02-01T00:00:00Z

This does not allow installation of OpenSearch 1.3. Latest OpenSearch version is 3.5. --InkluPedia (talk) 23:38, 16 March 2026 (UTC)

@InkluPedia we are in the process of upgrading CirrusSearch to support opensearch 3.x, please see phab:T420230.

Regarding opensearch 1.x apt repo I'm not sure what we could do, have you tried to seek help directly from opensearch maintainers?

The WMF uses its own apt repository and I suppose it's why haven't encountered this issue. DCausse (WMF) (talk) 17:48, 19 March 2026 (UTC)

@DCausse (WMF) Thanks for information. I opened this thread in OpenSearch forum for this issue: https://forum.opensearch.org/t/opensearch-pgp-signature-no-longer-valid-installation-of-opensearch-fails/27947/5 --InkluPedia (talk) 12:43, 23 March 2026 (UTC)

This is a problem in Debian 13. It looks like this is not affecting Debian 12. In Debian 13 SHA1 signatures are no longer valid. As a workaround I raised the expiration date for SHA1 in /usr/share/apt/default-sequoia.config to allow installation of OpenSearch 1.3.20. --InkluPedia (talk) 13:19, 27 March 2026 (UTC)

CirrusSearch against ElasticSearch 8.x

I'm running ES 8.18, and CirrusSearch seems to work well with the patch below (running MW 1.43.6). Ideally I should have used a compatibility layer as well, but I'm afraid my MW/PHP skills are not enough to do it in a reasonable amount of time.

Here's the patch in the hopes it's helpful to someone:

--- tmp/CirrusSearch-REL1_43-f8ff009/includes/Maintenance/AnalysisConfigBuilder.php	2026-03-24 06:04:58.000000000 +0000
+++ CirrusSearch/includes/Maintenance/AnalysisConfigBuilder.php	2026-03-26 17:27:04.727873773 +0000
@@ -601,7 +601,7 @@
 					'preserve_original' => false
 				],
 				'prefix_ngram_filter' => [
-					'type' => 'edgeNGram',
+					'type' => 'edge_ngram',
 					'max_gram' => CirrusSearch::MAX_TITLE_SEARCH,
 				],
 				'asciifolding' => [
@@ -627,7 +627,7 @@
 			],
 			'tokenizer' => [
 				'prefix' => [
-					'type' => 'edgeNGram',
+					'type' => 'edge_ngram',
 					'max_gram' => CirrusSearch::MAX_TITLE_SEARCH,
 				],
 				'no_splitting' => [ // Just grab the whole term.
diff -ruN tmp/CirrusSearch-REL1_43-f8ff009/includes/Maintenance/ConfigUtils.php CirrusSearch/includes/Maintenance/ConfigUtils.php
--- tmp/CirrusSearch-REL1_43-f8ff009/includes/Maintenance/ConfigUtils.php	2026-03-24 06:04:58.000000000 +0000
+++ CirrusSearch/includes/Maintenance/ConfigUtils.php	2026-03-26 17:23:02.603280037 +0000
@@ -57,7 +57,8 @@
 		}
 		$result = $result[ 'version' ][ 'number' ];
 		$this->output( "$result..." );
-		if ( strpos( $result, '7.10' ) !== 0 ) {
+		//if ( strpos( $result, '7.10' ) !== 0 ) {
+		if (( strpos( $result, '7.10' ) !== 0 ) and ( strpos( $result, '8.18' ) !== 0 )) {
 			$this->output( "Not supported!\n" );
 			return Status::newFatal( "Only Elasticsearch 7.10.x is supported.  Your version: $result." );
 		} else {
diff -ruN tmp/CirrusSearch-REL1_43-f8ff009/includes/Maintenance/MappingConfigBuilder.php CirrusSearch/includes/Maintenance/MappingConfigBuilder.php
--- tmp/CirrusSearch-REL1_43-f8ff009/includes/Maintenance/MappingConfigBuilder.php	2026-03-24 06:04:58.000000000 +0000
+++ CirrusSearch/includes/Maintenance/MappingConfigBuilder.php	2026-03-26 17:36:11.407638632 +0000
@@ -161,11 +161,11 @@
 			'properties' => [
 				'timestamp' => [
 					'type' => 'date',
-					'format' => 'dateOptionalTime',
+					'format' => 'date_optional_time',
 				],
 				'create_timestamp' => [
 					'type' => 'date',
-					'format' => 'dateOptionalTime',
+					'format' => 'date_optional_time',
 				],
 				'page_id' => [
 					'type' => 'long',
diff -ruN tmp/CirrusSearch-REL1_43-f8ff009/includes/Search/DatetimeIndexField.php CirrusSearch/includes/Search/DatetimeIndexField.php
--- tmp/CirrusSearch-REL1_43-f8ff009/includes/Search/DatetimeIndexField.php	2026-03-24 06:04:58.000000000 +0000
+++ CirrusSearch/includes/Search/DatetimeIndexField.php	2026-03-26 17:36:11.407638632 +0000
@@ -15,7 +15,7 @@
 
 	public function getMapping( SearchEngine $engine ) {
 		$config = parent::getMapping( $engine );
-		$config['format'] = 'dateOptionalTime';
+		$config['format'] = 'date_optional_time';
 		return $config;
 	}
 }

Any corrections will be gladly appreciated. Nuno Tavares (talk) 10:50, 29 April 2026 (UTC)

Glad that's working! The Wikimedia Search Team is currently migrating from OpenSearch 1.3 to 2.19 and we don't have any plans to support Elasticssearch 8.x, and it may or may not continue to work in the future. TJones (WMF) (talk) 15:32, 29 April 2026 (UTC)