- User Since
- Oct 27 2014, 7:46 PM (439 w, 3 d)
- LDAP User
- MediaWiki User
- Rudloff [ Global Accounts ]
Jun 8 2021
@Osnard The code is available here.
There is no documentation but feel free to open an issue on the repository if you have questions.
Jan 30 2021
I am currently hosting a Composer repository mirroring the MediaWiki extension directory (mostly as a proof of concept to show that installing extensions with Composer can work and can be useful).
I would of course be happy to replace it with Packagist or an official MediaWiki repository.
Apr 11 2018
I confirm it now works correctly for me too :)
Mar 30 2018
Mar 26 2018
I confirm I can't reproduce anymore with MediaWiki 1.29.2, ConfirmEdit 1.29+6925a22 and ContactPage 1.29+d269558.
Dec 20 2017
I published a patch here: https://gerrit.wikimedia.org/r/#/c/399457/
Turns out I had to run maintenance/PopulateContributorsTable.php and now Special:Contributors works correctly. (This should probably be added to the wiki page.)
Oct 17 2017
The errors seem to disappear over time. My guess is that forceSearchIndex.php introduced them in the index, but page edits generate the page again without the errors.
Oct 1 2017
I can still reproduce with 1.29+7005f38:
PHP Notice: unserialize(): Error at offset 20792 of 65535 bytes in /home/vhosts/fabien/archi-mediawiki/vendor/mediawiki/core/includes/jobqueue/JobQueueDB.php on line 807 PHP Fatal error: Unsupported operand types in /home/vhosts/fabien/archi-mediawiki/extensions/CirrusSearch/includes/Job/ElasticaWrite.php on line 44
Sep 23 2017
Sep 20 2017
This seems to be fixed in ReplaceText 1.29+b02d10f.
Sep 12 2017
Any news on this? We have several users that created a second account when they forgot their password and now we can't merge them because of this bug.
Sep 8 2017
Jun 1 2017
May 10 2017
I currently use this to get the latest comment on each page:
$dbr = wfGetDB(DB_SLAVE); $res = $dbr->select( ['Comments', 'page'], ['Comment_Page_ID', 'Comment_Date', 'Comment_Text'], 'page_id IS NOT NULL', null, ['ORDER BY' => 'Comment_Date DESC'], [ 'page' => [ 'LEFT JOIN', 'Comment_Page_ID = page_id', ], ] );
Apr 19 2017
Here is my Accept-Language header: fr-FR,en;q=0.5.
Since French is listed first, shouldn't it be picked instead of English?
Apr 18 2017
That might work but I'm not sure I can wrap the form in a template as it is generated automatically (and we definitely don't want to hide it when the user is not on the results page).
Because we have a pretty big form and it takes a lot of space so we think it might look cleaner if we can remove it from the results page.
Apr 3 2017
Apr 1 2017
Mar 30 2017
Jan 30 2017
Here is my patch: https://gerrit.wikimedia.org/r/#/c/335029/
Jan 26 2017
Any news on this? I can submit a patch if needed.
Jan 1 2017
"install" in Composer context means downloading the PHP files. Again the proposed patch does not enable the extension with Composer.
T467 is about using Composer to load extensions, not about using Composer only to download extensions.
The proposed patch does not use Composer's autoloader and you still need to use wfLoadExtension() to load the extension. The patch only allows people to use Composer to download/update the extension (if they want to, this is entirely optional).
Dec 15 2016
Relative or not, the code uses wfExpandUrl() to always give an absolute URL to getimagesize() (in order to have a consistent behavior, because $wgAppleTouchIcon can also be absolute).
So if it points to a non-existing file, the error should be:
failed to open stream: HTTP request failed
Could it be that allow_url_fopen is set to false on the server so getimagesize() can't be used with a distant file?
Dec 13 2016
Dec 11 2016
I can't reproduce anymore with 1.28+88234fa.
Dec 8 2016
It is because the manifest is not on the same domain as the page (and the Access-Control-Allow-Origin HTTP header is not properly set).
I think the easiest way to fix this is to have a relative URL in the <link> tag.
I will submit a patch for this.
Nov 28 2016
Nov 26 2016
Sorry, I made a mistake and created a new change instead of updating the previous one.
Nov 16 2016
As a workaround, wouldn't it be possible to have an option to automatically enable translation on all pages in a namespace, without the need for <translate> tags?
I know this would not be suitable for a lot of wiki but it can help small wikis (including mine) that want to translate all of their content.
Nov 2 2016
I can still reproduce on the REL1_26 branch.
Aug 25 2016
Aug 18 2016
Aug 4 2016
Jul 21 2016
Jul 17 2016
Jul 15 2016
This seems to be fixed on the 1_27 branch.
As a temporary workaround, I tried 1.27+e0ad10a and the emails are sent correctly.
Jul 14 2016
Jul 11 2016
I am interested in this feature so I would like to work on a patch.
Is someone already working on it?
Jul 10 2016
May 22 2016
May 21 2016
Yes, here it is: https://gerrit.wikimedia.org/r/#/c/290006/
We had a discussion on T123363 and we agreed that using Composer autoloading feature to install extension is probably not a good thing for MediaWiki but that downloading extensions with Composer is harmless.
I personnaly think that it would be pretty useful as Composer is becoming the defacto standard for installing third-party PHP code.
Mar 15 2016
Any news on this? It would be pretty useful to have this extension (and others) available as a Composer package.
Jan 15 2016
What I understand from T467, is that is has been decided that Composer's autoload should not be used to enable, extensions and I totally agree with that.
But Composer is still a very useful way to install extensions (and then we can enable them with wfLoadExtensions).