API Path is hardcoded
Open, LowPublic
Actions

Assigned To

Authored By

	Alaub81
	Jan 12 2023, 8:15 PM

Description

Hi!

Since I am using MediaWiki 1.39 with the newest related RelatedArticles Version, they were not shown at the end of my articles. With the 1.38 Version everything was fine.
Browsertools gave me a good hint. The API call was done against a URL with /w/api.php, but in my setup the api.php is not laying under /w . After searching I found, that in the extension.json there was this:

"RelatedArticlesUseCirrusSearchApiUrl": {
                        "description": "During development use a different API for sourcing related articles.",
                        "value": "/w/api.php"

After I deleted /w everything is working fine on my setup.

I don't know if that is a bug, but perhaps the URL should not be hardcoded. I know, that the new standard mediawiki path is /w and I also know, that I should change my setup to that new path.

cheers
Andreas

Related Objects

Duplicates Merged Here: T333388: Regression: RelatedArticlesUseCirrusSearchApiUrl should use script path by default
T330990: [Regression] RelatedArticles don't display on wikis not using /w as $wgScriptPath due to hard-coded path

Event Timeline

Alaub81 created this task.Jan 12 2023, 8:15 PM

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJan 12 2023, 8:15 PM

You can set this configuration variable to anything you want in LocalSettings.php
Try adding:

wfLoadExtension('RelatedArticles');
$wgRelatedArticlesUseCirrusSearchApiUrl = 'api.php';

Let me know if that doesn't work.

Jdlrobson edited projects, added Reading-Web-Third-Party-Support; removed Local-Wiki-Template-And-Gadget-Issues.Jan 12 2023, 10:02 PM

Hi @Jdlrobson,

thank you for the hint!

I changed the extension.json back to /w/api.php and changed the configuration to:

$wgRelatedArticlesUseCirrusSearchApiUrl = '/api.php';

seems to work :-)

cheers
Andreas

Awesome glad to hear it!

Jdlrobson merged a task: T330990: [Regression] RelatedArticles don't display on wikis not using /w as $wgScriptPath due to hard-coded path.Mar 2 2023, 2:44 PM

Jdlrobson added a subscriber: Ciencia_Al_Poder.

Aklapper renamed this task from API Path is hardcodes to API Path is hardcoded.Mar 2 2023, 2:50 PM

I'm going to be bold and reopening this task, for multiple reasons.

There's a regression in this extension, that worked pretty well in MediaWiki 1.38 and it doesn't work in 1.39 when upgrading, unless the setting described in T326859#8521925 is set. Setting that variable is a workaround, not a fix.

That setting, which breaks upgrades, isn't prominently documented, at least, as a breaking change.

The change that introduced it doesn't even mention it changes the default behavior.

While I understand this setting is useful for testing, the default value should be unset and automatically configured to use the current location of the api. MediaWiki already knows where's the api entry point, it's used in a lot of places in the UI (enhanced Recent Changes, watch and unwatch, edit stash, early upload validations...). This setting contradicts the "use sane defaults" rule.

The default value for the setting isn't even the default value of $wgScriptPath. It has been specifically tailored to not break WMF production wikis. That's probably why this went unnoticed.

Please implement a default value that doesn't need to be set on production websites (outside of WMF wikis where it coincidentally uses /w/api.php).

Jdlrobson merged a task: T333388: Regression: RelatedArticlesUseCirrusSearchApiUrl should use script path by default.Mar 29 2023, 2:42 PM

Jdlrobson added a subscriber: alistair3149.

I don't think it's unreasonable to expect reconfiguration with a new release. This happens quite frequently from my experience with MediaWiki and I do not see any guidance in https://www.mediawiki.org/wiki/Stable_interface_policy prohibiting it.

I agree it could be documented better but I'm not sure how to do that in an obvious way since this extension does not have release notes. It doesn't look like the major version number was bumped so perhaps that would be one signal? What exactly, would we recommend?

If we want to change the default value no issues with that but it should not make use of $wgScriptPath as I want this extension to support external APIs.

Another option, if maintenance scripts exist, might be to read $wgScriptPath from LocalSettings.php and update LocalSettings.php so others don't run into this issue.

As the only active maintainer of RelatedArticles I'm happy to consider any patch towards resolving this issue in a more satisfactory way.

Meanwhile I updated the MediaWiki page with this information https://www.mediawiki.org/w/index.php?title=Extension%3ARelatedArticles&diff=5807604&oldid=5686241&diffmode=source

Would it work if RelatedArticlesUseCirrusSearchApiUrl is default to null?

When the config flag is null, RA would fallback to $wgScriptPath/api.php like before, providing a zero config experience.

When the config flag is defined, RA would simply use the value instead.

In T326859#8738554, @Jdlrobson wrote:

I don't think it's unreasonable to expect reconfiguration with a new release. This happens quite frequently from my experience with MediaWiki and I do not see any guidance in https://www.mediawiki.org/wiki/Stable_interface_policy prohibiting it.

What about Manual:Upgrading#Other variables?

Some variables may be obsolete or even removed. Having them in LocalSettings.php usually won't have any effect. New variables may be added in newer versions, or some existing variables changed their type. We usually try to use sane defaults for them, and in case of type change, be backward compatible. In any case, take a look at the release notes to see those changes.

Setting a different path for the api by default than the actual api location used in various places by MediaWiki itself doesn't look reasonable to me.

Would it work if RelatedArticlesUseCirrusSearchApiUrl is default to null?

@alistair3149 that works for me if it works for @Ciencia_Al_Poder . Patch very much welcome!

What about Manual:Upgrading#Other variables?

The language used here doesn't seem to prohibit this or enforce this in any way. "We usually try" being the most problematic, and I promise you I did try here - I was just didn't realize that script path differed from Wikipedia :-).
The note about the release notes only applies to MediaWiki core as we currently don't add release notes for extensions - it would be nice if we did!

API Path is hardcodedOpen, LowPublicActions

Description

Related Objects

Event Timeline

API Path is hardcoded
Open, LowPublic
Actions