Skip to content
Merged
28 changes: 14 additions & 14 deletions docs/dev-environment.md
Original file line number Diff line number Diff line change
Expand Up @@ -2,9 +2,12 @@

There is a [docker-compose file](../docker-compose.yml) in the root directory that allows for serving multiple development sites locally.

These are currently not using the real api but rather gets their settings from the static json files included in the data folder.
These are currently not using the real API but instead get their settings from the static JSON files included in the data folder.

The fake api is served by the [server.php](test/server.php) script and reads the corresponding [subdomain](data/WikiInfo-site1.json) from each request.
The fake API is served by the [server.php](test/server.php) script and reads the corresponding [subdomain](data/WikiInfo-site1.json) from each request.
Comment thread
dati18 marked this conversation as resolved.

> [!NOTE]
> You may find you have to refresh the page a few times before changes are reflected in Elasticsearch. Unlike [wmde/wbaas-deploy](https://github.com/wmde/wbaas-deploy/), this setup doesn't have a dedicated job runner. Jobs queued up, such as ones from CirrusSearch and WikibaseCirrusSearch, are completed as part of web requests (see [wbstack/src/Settings/LocalSettings.php#L147-L151](https://github.com/wbstack/mediawiki/blob/ebac07a4a4096d8fd973ebd43ebe342f34b87803/dist-persist/wbstack/src/Settings/LocalSettings.php#L147-L151)), so refreshing the page ensures that all jobs in the queue are run.

### Start the dev environment

Expand All @@ -29,8 +32,8 @@ Wait until both sites are accessible:
Once the sites are accessible you can perform secondary setup (_The request takes a while to execute_):

```sh
curl -l -X POST "http://site1.localhost:8001/w/api.php?action=wbstackElasticSearchInit&format=json"
curl -l -X POST "http://site2.localhost:8001/w/api.php?action=wbstackElasticSearchInit&format=json"
curl -sS -H "Content-Type: application/json" -X POST -d '{}' "http://site1.localhost:8001/w/api.php?action=wbstackElasticSearchInit&format=json" | jq
curl -sS -H "Content-Type: application/json" -X POST -d '{}' "http://site2.localhost:8001/w/api.php?action=wbstackElasticSearchInit&format=json" | jq
```

Removing the installation:
Expand All @@ -43,16 +46,13 @@ Understanding special configuration for the `docker compose` environment:

When `$wwDockerCompose` is set some special settings are used. It is set from the environment variable `WBSTACK_DOCKER_COMPOSE` and is always true in the `docker compose` environment. Examples of this include disabling captchas, disabling the normally required email confirmation and automatically granting sysop rights to all users.

### Debugging Elastic
### Elasticsearch

General overview of the cluster
- Overall stats: http://localhost:9200/_stats
- Indices: http://localhost:9200/_cat/indices
- Aliases: http://localhost:9200/_aliases
- Entries in the content index (Items, Lexemes) for `site1.localhost`: http://localhost:9200/mwdb_somedb1_content_first/_search

```
http://localhost:9200/_stats
```
In [wmde/wbaas-deploy](https://github.com/wmde/wbaas-deploy/) Elasticsearch is configured so all Wikis share the same indices. In contrast, this docker compose environment is configured so each wiki has its own indices. This is how Elasticsearch was configured when this docker composer development environment was created. As MediaWiki isn't creating new indices, whether Elasticsearch uses shared indices via aliases or not is inconsequential. Investing time to change this is likely not worth it and having separate indices is a simpler setup.

Entries in the content index (Items, Lexemes) for `site1.localhost` can be found by going to the following url

```
http://localhost:9200/site1.localhost_content_first/_search
```
The index names are based on the MediaWiki database name (not the domain). This is why indices appear in the format `{db_name}_content_first` and `{db_name}_general_first`, for example `mwdb_somedb1_content_first`.
Loading