Topic on Project:Support desk

I've upgraded recently to 1.26 without problems.

Now I felt forced to upgrade again to 1.28.

When I start my wiki I get this message:

Warning: require(/kunden/vexilli.net/webseiten/Hombruch/wiki/includes/services/ServiceContainer.php): failed to open stream: No such file or directory in /kunden/vexilli.net/webseiten/Hombruch/wiki/includes/AutoLoader.php on line 81

Fatal error: require(): Failed opening required '/kunden/vexilli.net/webseiten/Hombruch/wiki/includes/services/ServiceContainer.php' (include_path='/kunden/vexilli.net/webseiten/Hombruch/wiki/vendor/pear/pear_exception:/kunden/vexilli.net/webseiten/Hombruch/wiki/vendor/pear/console_getopt:/kunden/vexilli.net/webseiten/Hombruch/wiki/vendor/pear/pear-core-minimal/src:/kunden/vexilli.net/webseiten/Hombruch/wiki/vendor/pear/mail_mime:/kunden/vexilli.net/webseiten/Hombruch/wiki/vendor/pear/mail_mime-decode:/kunden/vexilli.net/webseiten/Hombruch/wiki/vendor/pear/net_socket:/kunden/vexilli.net/webseiten/Hombruch/wiki/vendor/pear/net_smtp:/kunden/vexilli.net/webseiten/Hombruch/wiki/vendor/pear/mail:.:/usr/local/lib/php') in /kunden/vexilli.net/webseiten/Hombruch/wiki/includes/AutoLoader.php on line 81

What should I do now?

Please make sure that you have updated all files of the installation. Also it is important that you extract the new files into a new folder. Any remaining files of the old MediaWiki version may cause errors. More details are at upgrading!

I did it all again and now I see: I'm getting an error message while depackaging mediawiki-1.28.0.tar. It comes while depackaging the file mediawiki-1.28.0\wiki.phtml which says "Can not create symbolic link : Access denied : C:\...my local path...\mediawiki-1.28.0\vendor\pear\net_smtp\README.rst"

And pear is the place where the start-up-time error message refers to.

So what to do about this depackaging?

I don't think this should be a problem.

From what I understand, the MediaWiki package includes a symbolic link "file" which are for Linux operating systems and as such are unsupported on Windows systems. These are like shortcuts and shouldn't be causing any breaking of the software.

"Can not create symbolic link" is what you'll see unless you run the extraction (depackaging) as an adminstrator. It won't cause problems because symlinking a README isn't going to affect the functionality.

Are you still getting the "Failed opening required..." error message?

Yes, unfortunately.

I tried to go back to 1.26 but I damaged the backup.

Then I tried to go back to 1.23 but there were too many differences.

So I'm still most interested in getting 1.28 working.

Would it be possible to try using a different software package to extract the TAR file? The actual unzipping (really un-tarring) seems to be where the problem is.

Thank you all!

All problems are solved now!

-Winfried

Could you tell us what worked for you so others will know if they run into a similar problem?

I have the same problem and I have used the mediawiki-1.28.0.tar.gz which I unpacked in windows first and then placed on my server. Which file to you Wschroedter get to have it to work?

regards HenrikKoch

I think this stupid symlink should be reported as a bug! See bugreport for how you can do that! It is a useless link and is only causing trouble!

I filed phab:T156491. Please comment there saying which TAR extraction software you used when you encountered this problem.

Does anyone have a solution for this? My MediaWiki is still down and I don't know how to solve this after upgrading to 1.28

Warning: require(/volume1/web/MediaWiki/includes/services/ServiceContainer.php): failed to open stream: No such file or directory in /volume1/web/MediaWiki/includes/AutoLoader.php on line 81 Fatal error: require(): Failed opening required '/volume1/web/MediaWiki/includes/services/ServiceContainer.php' (include_path='/volume1/web/MediaWiki/vendor/pear/pear_exception:/volume1/web/MediaWiki/vendor/pear/console_getopt:/volume1/web/MediaWiki/vendor/pear/pear-core-minimal/src:/volume1/web/MediaWiki/vendor/pear/mail_mime:/volume1/web/MediaWiki/vendor/pear/mail_mime-decode:/volume1/web/MediaWiki/vendor/pear/net_socket:/volume1/web/MediaWiki/vendor/pear/net_smtp:/volume1/web/MediaWiki/vendor/pear/mail:.') in /volume1/web/MediaWiki/includes/AutoLoader.php on line 81

Found the problem

Somebody had renamed /includes/services to /includes/Services (note the upper case S ) changing this to lower case made the trick!

How and why does this happen in a release´?

/Henrik

This issue is a serious problem. This breaks mediawiki on any system that is case-sensitive.

> This issue is a serious problem.

Do you mean the renaming of /includes/services to /includes/Services that HKOCH mentioned? Could you explain exactly what you did that caused this folder to be renamed? As far as I can see this folder has always been lowercase.

Re: Somebody had renamed /includes/services to /includes/Services (note the upper case S ) changing this to lower case made the trick!

Exactly the same thing happened to me after relocating files from Windows to a *nix server. Other files had been named, too, such as SpecialUserLogin > SpecialUserlogin (see also: http://stackoverflow.com/questions/38135184/mediawiki-1-27-warning-requiring-specialuserlogin-php). The problem did seem to occur in the process of either zipping/tarring or extracting the files. Not sure if there's a connection with symlinks or PEAR dependencies.

This is probably caused by Windows being case insensitive and people not following the instructions on Manual:Upgrading stating that you shouldn't unpack new files over the old ones!

On Windows, files SpecialUserLogin.php and SpecialUserlogin are the same. If you unzip a new version over the old one, it sees the file already exists and updates the contents without using the new name. It continues to work on windows, until you move those files on a case-sensitive filesystem.

Thanks. Mmm, after unsuccessful attempts to upgrade MW in the manner prescribed (I remember it was something specific to MW 1.28.0), I resorted to a third-party installer to upgrade MW, which somehow worked (locally), but that's precisely where things must have gone wrong. A veritable mess, but everything should be in order now.