Cool thank you @Krinkle !

WOW @alex-mashin really thank you for your time. I will try your fix in my environment.

It does not seems to repeat in MW 1.31. I have changed this task to resolved status.

There aren't any gitinfo.json file created under /w/ folder.
Mediawiki 1.31.2 .

@D3r1ck01 It seems that this extension need to set Reply-To header based on condition. Only add Reply-To header when user sending email via Special:EmailUser page.

Same bug mentioned in T217816 as well.

Error log dump. Seems to be a bug in reply to:

In T217656#5001653, @Aklapper wrote:

Is this a bug report (if it is, what is the bug?) or a support question?

Is there anyway to capture the email send request before the mail sent to Sparkpost?

In T216976#4979640, @D3r1ck01 wrote:

@Zoglun, Maybe it will be a good idea to file this bug upstream? That is, on the Github repository of the Spark Post project here: https://github.com/SparkPost/php-sparkpost.

In T216973#4979500, @Liuxinyu970226 wrote:

@Zoglun Why do you think there's benefit to fix this without Growth team help or focus? I don't see any reasons to remove a tag that is added by Herald.

I'm NOT reporting bug ,but I would like to share some info that we found. It seems that the filter work as expected. The extension might need some improvement to handle even further advanced xss attack.

@Aklapper Cool! Thank you!

Cool, thank you @matmarex !

The bug still exist in extension:echo 1.31 version (commit b56ec9b435c52a744cf7bdc3217e752df8742238 Oct/12-2018). The Mediawiki 1.31 is a LTS version. Thus we wish the fix for this bug in Echo could get merged into REL1_31 branch.
Thank you in advance!

In our test, $wgGitInfoCacheDirectory = "/tmp/mw-cache-gitinfo"; has no effect on the gitinfo at all. (at least for MW 1.31.1) Mediawiki still tying to generate gitinfo.json under /wiki folder.

Thank you for update the documentation page. I will test the $wgGitInfoCacheDirectory latter today.

Hi guys,

I have reproduced exactly the same error message in MW 1.31.1 with complementary Widget extension version in my local test environment today.

In T215688#4940527, @Liuxinyu970226 wrote:

Umm, somewhat tricky. This site is licensed under CC BY-NC-SA 3.0 which, as we know, that's a non-commercial license, but in nearly all WMF cases, we require that everything must be commercial usages allowed. @Tgr Have you ever contacted e.g. WMF-Legal members for their opinions?

Reply-to function work in my test. Ула!

In T215249#4940387, @D3r1ck01 wrote:

So what are the random content errors? Any example?

Good! Reply-to function seems to work well. I will do more test on it.

In T215688#4940311, @Tgr wrote:

We have a project for Brickimedia, at least. And if nothing else you could always create a personal project.

Dear @D3r1ck01 Is there any progress on the patch? Or experiencing any difficulty?

Cool!
It's late night in China now. I will test your new code tomorrow (if patch available).

Is there some bug in the code? No matter who send user-to-user email. The reply field only contain email address password-reset@mail.example.com. It's suppose to be the emaill address of user who initiate the email through page Special:EmailUser. Not the system email address.

By far it seems that no reply_to field transferred to SparkPost. Therefore all email sent via user-to-user method does not contain sender's email address in reply-to.

The newest version work well. ;)

The extension work fine before, but not after the revert.

Interesting. Your last change before revert actually made something work.
with vriables:

$wgSparkPostOpenTracking = false;
$wgSparkPostClickTracking = false;
$wgSparkPostTransactional = true;

Finally WORKED!!!

Did you get normal link address without convert? If you do get url without convert, then there might be problem with php cache?

Still no effect. :)

I03157d57249c942e7a1bffc953aeca8226e2db9f Does not disable link tracking convert in our test.

Oh, I just realized that I am not sure what this transactional option mean in SparkPost. There were not much information about this option. I don't know whether it work or not. Sorry for that.

With SparkPost commit 4f241dc6c585ae6303a675f09fb8d3f761c60d5c & MW 1.31,

In T214664#4915495, @D3r1ck01 wrote:

@Zoglun, I've added that feature into the extension. Please test it and let me know if it's working as expected so we can resolve this task or if you run into any issues, let me know and I'll try to fix ASAP. Thanks!

Also, could you let me know if this extension is already running on a wiki instance that is used by many users? So that I can pay more attention and respond faster to issues raised. :)

Here is the error mail content for reference.

Hi D3r1ck01,
Default these three vars to true would be better, as the default tracking behavior of SparkPost.
$wgSparkpostOpenTracking, $wgSparkpostClickTracking and $wgSparkpostTransactional are better. That's good!

This error might related to the sparkpost tracking function, which is enabled by default. It add codes/small gif to each mail to get engagement tracking ability, and change each url link to get click statics.

In T212895#4858348, @D3r1ck01 wrote:

Ohh I see you've filed T213056 already!

An error that we found is, when $wgUserEmailUseReplyTo = true; . the sender's email address were not listed in Reply-To filed. There for reply email sent from User B to User A will send to system mail. Instead of User B.

In T212895#4858132, @D3r1ck01 wrote:

Interesting! So 2 things to keep in mind from my end.

1. I have a valid API key
2. I don't have the configs for a sending domain (but you have)

So in that case, I'll be helping with the development and requests, and you'll be helping out with the testing right?

Also, a little more cleanup on the extension I think is needed and of course writing unit tests (my favorite). Thanks a lot and I think if you wish, I can add you as co-author for the extension if you intend to maintain it (code wise and user wise), should I?

COOL!
I got the mail! Everything seems working very well.
Really appreciate your work!

After several tried, we keep getting error message:
{ "errors": [ { "message": "Message generation rejected", "description": "Sending domain sandbox option mismatch", "code": "1902" } ], "results": { "total_rejected_recipients": 0, "total_accepted_recipients": 1,

In T212895#4858094, @D3r1ck01 wrote:

I have an API key too as well @Zoglun but what I don't have access to now is configs to setup a sending domain, if you have that, then you can use the manual here: https://www.mediawiki.org/wiki/Extension:SparkPost, to test the extension on a local wiki instance. Let me know if you have any troubles. Thanks!

In T212895#4854121, @D3r1ck01 wrote:

@Zoglun, do you have a valid API key and a sending domain to try it out?

We encounter a new error in MW 1.31.
The active user number droped from 1.3k to 50 after php /var/www/wiki/maintenance/rebuildall.php .

@EBernhardson , In fact that ElasticaWrite is quite common, simple server reboot could incur last few line error almost every time. Especially if using ElasticaSearch cluster.

Is there any progress for this bug fix? https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/337803/ were submitted in Feb 2107, and seems to stay in "Cannot Merge" status till now.

@Krinkle
I tired your method of "SetEnv" in nginx. It does not work due to nginx remove any environment variable. Moreover, env MW_CONFIG_FILE=value; will set a single value to all wikis, which is not ideal for wiki farm.

In T203061#4551294, @Legoktm wrote:

It also break the distribute version of Mediawiki in Debian std. They put MediaWiki core files under /usr/share/mediawiki and then /etc/mediawiki/LocalSettings.php. Mediawiki is loaded via symlink from web-server directory. Therefore, after upgrade to 1.31, Mediawiki will start to load LocalSettings.php under /usr/share/mediawiki, instead of where the symlink LocalSettings.php, which break the site.

I'm unable to reproduce any breakage using the Debian filesystem symlink layout under MediaWiki 1.31 - it seems to work just fine.

With further test, same problem could be reproduced with Mediawiki 1.30. The problem is not limited to session storage, it happens when $wgMainCacheType = redis too.

In T203061#4549478, @Krinkle wrote:

I'm not sure such structure was officially supported. (The documentation is freely editable). But, I think we can support this structure.

The only requirement is for MW_INSTALL_PATH to be set as an environment variable to the imitation directory for the current site. Everything will automatically fall into place after that. We can add that to the 1.31 release/upgrade notes.

www.a.com point to /www/a.
/www/a contain LocalSettings.php and symlink to each file/folder under /www/mediawiki.

See https://phabricator.wikimedia.org/T203061

Cool thank you Krinkle!

Cool, thank you!