Topic on Project:Support desk

Summary by Ciencia Al Poder

I'm installing mediawiki in IIS on Server 2012 R2. I am using SQL Server.

After completing the installation form and starting the install the process fails with Could not create a new page. It already exists.

If I choose back I need to drop and remake the database so that the creating tables routine doesn't fail, but if this is done the install stops at the same point with the above error. This is the same if I choose to restart installation.

I have fully deleted mediawiki and extracted a new copy to the folder IIS expects it to be in and I leave the web.config file. After this i get the same error as above.

There isn't a localsettings.php file anywhere other than the ..\extensions\MultimediaViewer\tests\browser\ one. It appears that no additional files or folders have been created as they have the same number as a newly extracted install (+1 for the web.config file)

I'd appreciate any help or advice. Thank you!

SQL Server is not well supported for MediaWiki. Apparently this is another bug for SQL Server support, which is already tracked on MediaWiki's phabricator as task T214055.

As alternative, I suggest you to use MySql instead

I finally got this working. I want to point out that I had around 5-10 significant issues on a FRESH install that would've been impossible had each not been addressed. I'd be extremely curious if anyone got all the way through an mssql setup without any issues or code fixes. Some more minor issues I'm working on. I have a patch I'm working on testing, far from production, but will be enough to get MSSQL working for folks to play around with it. Very cool Tool/Website/software!!

Tracked in Phabricator
Task T214055

Here is a link to my patch: https://drive.google.com/open?id=1F46slgU7F5lfC4RjpnPS4Yi-5rcduViw

This wiki wouldnt let me upload it!! As I mentioned above this is NOT intended to be an official patch or production ready. It is only a patch to get this wiki up and running to play around with it. There are some more mssql bugs I found, but overall it works maybe 95%. Feel free to provide feedback. This is for version: mediawiki-1.32.0_

Instructions:

-Get working web server with php & mssql integration (test that this all works)

-Update your webserver vd or however you want to access this (eg http://yourwebsite.com/wiki - add "wiki" vd in this example)

-Unzip the official Mediawiki zip you got from this site to your website directory (eg, wiki)

-Unzip my patch on top of this

-Open http://yourwebsite.com/wiki (may need to add index.php as a default file) - The website should indicate the wiki hasn't been setup yet and take you to the installer. You can play with settings, but here's what definitely works: SQL login both times it asks, use sa sql account (yes this is bad for prod use!!!), all default db settings (changing db name is ok), DONT go through additional settings when you get to it (it asks something about being bored, skip additional steps). Should build tables, etc and take you to a complete page

-Click Continue and download the LocalSettings.php file it made for you, and drop it in the root of your website folder (wiki or whatever)

-Open website http://yourwebsite.com/wiki & it should work

@Kevin71246 You can submit your patch to our code repository directly! See How to become a MediaWiki hacker

I think my patch may be controversial so I wanted to share it informally - eg, A particular error may be better fixed: in the php code OR the db schema. And without knowing the apps code thoroughly, I have no clue any consequences it may have either on the bug side, security side, or causing issues or compatibility down the line. I'm also sure its possible it would break things if one put this patch for a different database, like mysql. I saw numerous db data type errors where the SQL query wasnt playing nice, and complaining about requiring a cast or whatever since it expected a different data type (ie the query expected a varchar datatype, but the db was varbinary). So I dont know what the best OFFICIAL fix would be.

My expertise is much more on the environment side than on the PHP programming side. Again, I came up with this patch because I was excited to get this up and running, and shared it so others can play around with this.

Also, over many years I professionaly supported webserver(Apache & IIS)/php/mssql environments, and it came to mind that the sql:php drivers alone varied quite a bit. There were many file versions for the dll, as well as numerous php extensions for sql integration, such as pdo, odbc just to name a few. Point here, is this could explain the erratic behavior between one user to another while trying to set this up in a "IIS:PHP:MSSQL" environment, for example, because that's still way to ambiguous. Ie, what mssql driver and file version is one user using to connect to PHP?

That said, Id be more than happy to work with someone that knows PHP and this app particularly much more than I, to come up with an official patch. I have notes for all the errors I found thus far, and workaround/fixes if that would help to expedite and get MSSQL officially supported :)

@Ciencia Al Poder I've been finding a lot of more MSSQL bugs. I understand it isn't officially supported, but perhaps volunteers like myself can change that. Again, I'm not an expert programmer so I appreciate overlooking or critique on my "fixes". I really don't know how all this works (submit a patch, it gets reviewed?). BTW I submitted a request to join phabricator, but it hasn't been approved for some time. Id like to help contribute at least troubleshooting to existing tickets. But maybe not everyone can just join? (Its ok, Im not offended :) )

I have a specific question though, since many of the mssql bugs relate to one thing: whether it should be fixed in php or on the db schema side - Where should that dialogue exist? (If its on the db schema side, we need to change the data type from varbinary to varchar for many columns, or perhaps all - this would easily fix a large majority of mssql related bugs without touching the code - Alternatively, if "MediaWiki" feels this is the correct datatype and the fix needs to be in the php code, then we need to add CONVERTs everywhere it fails due to the data mismatch between a string & the binary datatype.) I'd like to know where "we" stand on the correct fix, so I do that, and not the "wrong" way. Then perhaps my patch (which is growing by the day) will a little more accepted. Thanks!!!

@Kevin71246 did you ever get your code added into gerrit or to a bug as a suggested fix? We've found further issues that we've resolved with MSSQL but they rely on your updates being in place first. I have a bug for this topic already if you haven't done either and want to update that.

We got a large spam attack in phabricator recently, maybe now accounts take longer to be accepted. I'm sorry this is happening to you.

Best you can do is to get into the wikitech-l mailing list and explain both the problem with the phabricator account and your ideas or questions about how to better fix those mssql issues. That list is focused on developers and I'm sure you'll get very good advice about that.

I'm going to ping @AKlapper (WMF) who can speed up the activation of your phabricator account and maybe review if there's something wrong in the acceptance of new contributors.

Thanks a lot for the ping and sorry for the inconvience! Approved your Phabricator account (but I'm afraid that creating a Developer Account to put patches into Gerrit might also be limited for another one or two weeks).

I downloaded your patch @Kevin71246 and merged it with the changes in the new 1.32.1 (the Database.php and LoadBalancer.php were the only 2 files with changes in them from 1.32.0 release). Using your patch we were able to successfully install into a MS-SQL installation on our dev environment where we couldn't before. We skipped the config more like you suggested so I don't know if there are any issues in that section. Having to run as sysadmin for the account during installation was something we had noticed before too. Because it will only work when it gets to create the DB assigning sysadmin was the easiest method on dev, another work around would be to make a Server Role with the ability to create DB and temp assign it during install. Either works and both are removed once done.