MediaWiki upgrade - 1.23.5 to 1.26.2 - WYSIWYG editor not working

Recently we upgraded our MediaWiki installation from 1.23.5 to 1.26.2.

We were using WYSIWYG MediaWiki extension in our existing version (1.23.5). During upgrade, we copied the same extension to 1.26.2 extensions folder and enabled it in LocalSettings.php.

However it did not worked and we got "500:Internal Server Error" when we tried to "Edit" any MediaWiki Page.

After a bit of research we found that we need to download a new version for this extension from this URL- https://github.com/Mediawiki-wysiwyg/WYSIWYG-CKeditor

Once downloaded, we copied the WYSIWYG folder to our extensions folder and it started working fine.

Hope this helps someone who is facing similar issue.

Mediawiki 1.26.2 - Stylesheet not working/loading

We were running Mediawiki installation for one of our clients for quite some time. The Mediawiki version that we were using was 1.23.5. Since this version was quite old and has come to legacy status, we decided to upgrade to latest version of Mediawiki (1.26.2).

We downloaded and installed Mediawiki latest version 1.26.2. When we ran this version, we observed that the stylesheets are not working/loading. In older version (1.23.5) of Mediawiki installed on same server, it was working fine. We checked LocalSettings.php file multiple times and everything seems to be fine.

The Mediawiki 1.26.2 site was deployed as a directory in a website under IIS (Windows 2012 server). In same website, Mediawiki 1.23.5 was deployed under different directory. Mediawiki 1.23.5 stylesheets were loading fine. However for 1.26.2 it was not working.

We also tried deploying Mediawiki 1.26.2 under a new website  just to be sure that directory inside a website is not creating any problem. But still it didn't worked. We tried both with http and https protocol but it did not made any difference.

Finally after lots of research on mediawiki forums, we found the solution for this issue.

The problem was that PHP.exe did not had write access to temp folder where it creates temp files during application execution. This was fine with older versions of MediaWiki (E.g. - MediaWiki-1.23.5). However latest version (E.g. - Mediawiki-1.26.2) do not loads styles due to this problem.

By default PHP uses C:\Windows\Temp directory for storing temp files. However it was not possible to give permission to this directory due to security restrictions on our server.

So we modified php.ini file and defined a custom temp directory where PHP can store its temporary files. We gave read/write permissions to this folder. After doing this modification, we did iis-reset and when we opened Mediawiki 1.26.2 version, that stylesheets started appearing fine.

Hope this will help.

Session sharing between Classic ASP and ASP.NET

Recently for a project which was a mix of classic ASP and ASP.NET, I was exploring ways of sharing session between classic ASP and ASP.NET.

After a bit of research, I found following three ways -

Option 1 –

• Use nSession DLL - http://nsession.codeplex.com/
• This provides a library which can be used in both ASP.NET and classic ASP applications to access session values. 

Option 2 –

• Store session in SQL Server by encrypting it from ASP.Net page
• Retrieve session from SQL server by decrypting it in ASP page
• Standard Microsoft approach - https://msdn.microsoft.com/en-us/library/aa479313.aspx

Option 3 –

• From ASP.NET page, encrypt session and pass in query string or store in a cookie.
• Redirect to classic ASP page.
• Get the encrypted value from query string or cookie, decrypt it and store in classic ASP session.
• This new session can be used in application.

We have followed 'Option-2' which is standard recommended approach by Microsoft and is also a safer option with respect to security.

SharePoint 2013 - Find ULS logs with Correlation Id

Generally whenever we get any SharePoint error, it is accompanied by a Correlation Id which is essentially a GUID. This can be searched in SharePoint ULS logs to find the actual error details.

Searching ULS logs for a particular correlation id is not easy due to following reasons -

• ULS logs are text file. Searching and copying errors for a particular correlation id is effort and time consuming.
• ULS log file tends to get large, sometimes more than 250MB. Opening and searching such huge files is not easy for any text editor or even ULS Viewer.

Recently, one of my team-mates told me an easy way out. Just run following command in SharePoint PowerShell and pass correlation id as input. It will copy all the logs related to that correlation id in a separate text file which you can easily view using any text editor or ULS Viewer.

get-splogevent | ?{$_.Correlation -eq "<correlation-id>"} | select Area, Category, Level, EventID, Message | Format-List > C:\TraceLog.log

C:\TraceLog.log is the location where your ULS logs related to that correlation id will be copied. You can specify any location and file name of your choice.

SharePoint 2013 Pages - How to edit in browser

Recently I was trying to edit a SharePoint page in SharePoint 2013. When I clicked on 'Edit Page' button in SharePoint ribbon after selecting the page, I got following error -

We’re sorry, we couldn’t find a program to open this document

On my machine, SharePoint Designer is not installed. On a different server where it is installed, the above mentioned operation used to first launch the SharePoint Designer and then open the page in browser in 'Edit' mode.

I found that on different server, when page opens in edit mode, the URL has following query-string appended to it -

?ToolPaneView=2&pagemode=edit

I manually added this to my SharePoint page to be edited -

https://<my_sharepoint_site>/<my_page>.aspx?ToolPaneView=2&pagemode=edit

And Voila, it worked. I was able to edit the page and then save it as per normal process.