Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make the names of the wikibase instance and WDQS adjustable in the settings #293

Draft
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

DavidFichtmueller
Copy link
Contributor

@DavidFichtmueller DavidFichtmueller commented Jan 5, 2022

These commits make the names of the wikibase instance and the query service adjustable via the .env file and the names are then properly displayed in Wikibase (added to the LocalSettings), Quickstatements (name of the wikibase to edit) and the query service (which is displayed in the front-end).

I created these changes for a project I am working on and thought they are useful and generic enough to benefit everybody who is installing a new wikibase. Please let me know what you think.

users can now adjust the name of the wikibase instance with just the .env file and without the need to add an additional settings file in LocalSettings.d/
until now, when creating a new batch in Quickstatements above the input field it said: "Create new command batch for" followed by an empty dropdown menu. Now the name of the wikibase instance is shown here. Though the user can not choose an alternative, but at least they know they are working on the correct wikibase instance. This is in particular important when one works on multiple different wikibase instances.
the name of the WDQS that is displayed in the frontend is now adjustalbe via the .env file. It used to be "DockerWikibaseQueryService", which is still the default in template.env.
Copy link
Contributor

@toban toban left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey, thanks for the PR I left some comments but will probably not have that much time to go back and forth going forward.

@@ -4,6 +4,7 @@
"logfile" : "/var/log/quickstatements/tool.log" ,
"sites" : {
"${MW_SITE_NAME}" : {
"label" : "${MW_SITE_NAME}",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not really sure I understand this change, isn't $MW_SITE_NAME in this file a couple of times already?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The ${MW_SITE_NAME} in sites is the id for this particular configuration and the one in site: defines the default configuration. These two need to be the same, though it doesn't matter what they are. The could as well just be called "default". However the one in "label" is the one that is actually displayed in the user interface. See https://quickstatements.toolforge.org/config.json for another example.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I noticed another issue regarding this change with Quickstatements: When a name with capital letters (or leading/tailing white spaces) is used, QS has issues, because it handles the cleanup of the names different in different parts of the code. I made a PR about it: magnusmanske/quickstatements#30 . Until this is resolved we either might have to wait or add anothers sed replacement line in the QS Docker file: https://github.com/wmde/wikibase-release-pipeline/blob/main/Docker/build/QuickStatements/Dockerfile#L35

sed -i "s/$site = strtolower ( trim ( get_request ( 'site' , '' ) ) ) ;/$site = get_request ( 'site' , '' ) ;/g" /var/www/html/quickstatements/public_html/api.php

@@ -15,7 +15,7 @@
"urlShortener": "tinyurl"
},
"brand": {
"title": "$BRAND_TITLE",
"title": "${WDQS_NAME}",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree $BRAND_TITLE isn't a great choice for the env var here, but would probably maybe require updating some documentation too if you search for $BRAND_TITLE in the repo it occurs a couple of times.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought BRAND_TITLE was clear enough and find it clearer than WDQS_NAME. Note how the JSON calls it "brand title" as well, so there also is the consistency aspect.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah on a second glance I agree that consistency should have priority here, lets not do this change.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The reason I changed this is to have all of the user adjustable settings in .env file start with WDQS_. While this brakes a bit of consistency within this template file, it increases the consistency for the user in the .env file, where they would have BRAND_TITLE next to WDQS_FRONTEND_HOST and WDQS_FRONTEND_PORT. Maybe this could be renamed to WDQS_FRONTEND_NAME though.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fair point, maybe a compromise could be WDQS_FRONTEND_BRAND_TITLE, just rolls off the tongue ;)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds good. Now that we found a compromise, the only piece of documentation that needs to be adjusted is the README.md. I can add another commit to this PR, but not before next week.

Docker/build/WDQS-frontend/Dockerfile Show resolved Hide resolved
example/docker-compose.yml Show resolved Hide resolved
@toban
Copy link
Contributor

toban commented Jan 6, 2022

And this should be confirmed by building locally and running tests, or on the fork. We aren't running the pipeline on external PR:s which isn't ideal.

@DavidFichtmueller
Copy link
Contributor Author

I build this locally on the server I run my wikibase instance on and it works there. But of course it would be nice to have somebody else confirm this.

@addshore
Copy link
Contributor

I'm almost ready to try and merge this pull request, but I need to resolve #317 first so that CI actually runs for this PR.

@addshore
Copy link
Contributor

addshore commented Mar 2, 2022

CI should now be set up to run on this pull request, but you may need to re push to the branch / rebase on the latest main.
Once that is done I can look at reviewing this and getting it in!

DavidFichtmueller added a commit to DavidFichtmueller/quickstatements that referenced this pull request Mar 14, 2022
within run_single_command, the site name is checked against the currently available sites. This was done, using the functions strtolower() and trim() to clean up the file name. The only problem is that at no other point in the app are the site names adjusted this way, causing issues, when the site name uses upper case letters or spaces in the beginning and end. 
In wmde/wikibase-release-pipeline#293 I suggested using the same variable to full the site name, as the label, go show to the user which wikibase instance the user is going to write to with the current quickstatement page. For this branding however, users might be inclined to use a name that contains capital letters causing Quickstatements to fail when writing to the API.
@DavidFichtmueller
Copy link
Contributor Author

See my other comment/reference PR above, this might either need to wait until the PR in QS is merged or require further adjustements as a workaround. Updating this to the latest main shouldn't be a problem. Also I need to adjust some of the variable names as we agreed in the discussion. I will do this, but probably not this or next week.

@addshore
Copy link
Contributor

See my other comment/reference PR above, this might either need to wait until the PR in QS is merged or require further adjustements as a workaround.

Right you are, I'll wait until being poked again then!

@addshore addshore marked this pull request as draft March 22, 2022 12:20
@addshore
Copy link
Contributor

Hey @DavidFichtmueller, just checking, whats the status of this?

@DavidFichtmueller
Copy link
Contributor Author

Now that magnusmanske/quickstatements#30 has been merged, this is no longer blocking. However I currently don't have the resources to rebase this to the current main release. Maybe somebody else wants to take care of this, if not I might be able get onto this in January (earliest).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants