Cool thank you @Krinkle !
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Aug 10 2019
Jul 24 2019
Jul 15 2019
WOW @alex-mashin really thank you for your time. I will try your fix in my environment.
Jun 19 2019
It does not seems to repeat in MW 1.31. I have changed this task to resolved status.
Jun 10 2019
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:
May 20 2019
May 19 2019
Mar 7 2019
Mar 5 2019
In T217656#5001653, @Aklapper wrote:Is this a bug report (if it is, what is the bug?) or a support question?
Feb 27 2019
Is there anyway to capture the email send request before the mail sent to Sparkpost?
Feb 26 2019
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.
Feb 25 2019
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.
Feb 22 2019
@Aklapper Cool! Thank you!
Feb 19 2019
Feb 15 2019
Feb 12 2019
Cool, thank you @matmarex !
Feb 11 2019
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.
Feb 10 2019
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:
Feb 9 2019
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?
Feb 5 2019
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.
Jan 29 2019
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.
Jan 26 2019
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!
Jan 25 2019
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.
Jan 7 2019
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.
- I have a valid API key
- 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?
Nov 25 2018
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 .
Nov 21 2018
@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.
Sep 13 2018
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.
Sep 2 2018
@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.
Sep 1 2018
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.
Aug 31 2018
www.a.com point to /www/a.
/www/a contain LocalSettings.php and symlink to each file/folder under /www/mediawiki.
Aug 29 2018
Aug 7 2018
Jul 28 2018
Cool thank you Krinkle!
Feb 6 2018
Cool, thank you!