Project:Support desk

Jump to: navigation, search

About this board

Edit description
vde   Welcome to MediaWiki.org's Support desk, where you can ask MediaWiki questions!

There are also other places where to askCommunication: IRCCommunication#Chat, mailing listsMailing lists, Q&A etc.

Before you post

Post a new question

  1. To help us answer your questions, please always indicate which versions you are using (reported by your wiki's Special:Version page):
    • MediaWiki
    • PHP
    • Database
  2. Please include the URL of your wiki unless you absolutely can't. It's often a lot easier for us to identify the source of the problem if we can look for ourselves.
  3. To start a new thread, click "Start a new topic".
By clicking "Add topic", you agree to our Terms of Use and agree to irrevocably release your text under the CC BY-SA 3.0 License and GFDL
星耀晨曦 (talkcontribs)

My wiki's short url is //domin/wiki/page.

When I visit Special:Notifications,that is //domin/wiki/Special:Notifications, the page prompts me "No such special page". After that, I visit it with another url(//domin/w/index.php?title=Special:Notifications), the page can be displayed properly.

Once, I thought it was web server url rewriting problem. However, most special pages are still accessible. So, I think the mediawiki have a bit of a problem.

Ciencia Al Poder (talkcontribs)

Usually, for the server, there should be no difference between both URLs, because the rewrite takes care to map first URL to second.

Try to find what exact URL is receiving PHP when accessing //domin/wiki/Special:Notifications. You can view it if you enable a debug log.

星耀晨曦 (talkcontribs)

I checked the web server log, I think //domin/wiki/Special:Notifications is rewritten to /w/index.php title=wiki/Special:++++++. This is not normal!

I think there is a problem with the rewrite rules of the web server. The pattern of rewriting rules is ^(wiki/[^/]+)/?$.

Ciencia Al Poder (talkcontribs)

Are you using apache, nginx or other server software? Can you post the complete rewrite rules you're using? The rewrites are inside an .htaccess?

星耀晨曦 (talkcontribs)

I am using IIS. I refer to this to set the rewrite rules.

Since I found the problem, I tried various rewrite rules, the short URL builder tool and import from .htaccess file(e.g the rules of the apache). But still can not access it normally.

星耀晨曦 (talkcontribs)

I'm going crazy! I visited a page that was able to display properly, and the server log tell me 2017-08-17 10:11:52(time) 10.8.0.2(host) GET(cs-method) /w/index.php(cs-uri-stem) title=Special:++++++++++++(cs-uri-query) 443(s-port) //domin/wiki/Special:%E9%80%9A%E7%9F%A5 (cs(Referer)) 200(sc-status).

The return code is 200, but //domin/wiki/Special:%E9%80%9A%E7%9F%A5 is rewritten to /w/index.php title=Special:++++++++++++.

星耀晨曦 (talkcontribs)

I created a redirect, as long as ^wiki/Special:(.*)$ match will be redirected to w/index.php?title=Special:{R:1}. No doubt, cure the symptoms, not the cause.

Ciencia Al Poder (talkcontribs)

Apparently IIS7 doesn't like colons in URLs... see https://forums.iis.net/t/1220559.aspx

Wondering if it may be the cause and maybe you can add some of the suggested configuration to it...

星耀晨曦 (talkcontribs)

Make a reverse proxy? I think, I have to learn more knowledge.:D

Reply to "Some questions about short url"

Add js var that page was edited or created

3
Subfader (talkcontribs)

How would I add a js var to the head that the page was edited or created via an extension?

I need to trigger the page that is loaded for the contributor after he edited or created a page.

  • Would be easy to add the age in seconds I guess, but that could be incorrect at times.
  • Add url parameter to the viewed article after edits?
120.144.149.85 (talkcontribs)

You can use mw.config.get( 'wgPostEdit' ); to know if the user just edited a page. It can contain: saved, created, or restored.

Subfader (talkcontribs)

I get only null and true (MW 1.25), but that's enough for me. Thanks!

Reply to "Add js var that page was edited or created"

MW 1.29.0 bug with SyntaxHighlight extension

27
Aka sektor (talkcontribs)

After upgrade MediaWiki from 1.28.2 to 1.29.0 - I am find, what appeared bug Extension:SyntaxHighlight

Not highlight lang "LUA"

Sample:

<syntaxhighlight lang="lua">

there_is_code

</syntaxhighlight>

In the bottom just write: "Pages with syntax highlighting errors"

Aka sektor (talkcontribs)

Like in this topic: Topic:Tj9l1go9tonunwbq

Aka sektor (talkcontribs)

Is it again developers of MediaWiki allowed mistake in packaging, like in 1.28.0 & 1.28.1?

AhmadF.Cheema (talkcontribs)

I am assuming the extension worked when you were using MediaWiki 1.28.2.

Can you again make sure that execute permissions are set for the pygmentize binary: extensions/SyntaxHighlight_GeSHi/pygments/pygmentize?

Sometimes, upgrades mess up file permissions.

In case you installed the extension from Git, you will also need to update composer.

Aka sektor (talkcontribs)

Yes, that work on 1.28.2

How to check execute permissions? I do not understand. I not done this before

"from Git"

Not. I just only installed box 1.29.0 from here https://releases.wikimedia.org/mediawiki/1.29/mediawiki-1.29.0.tar.gz

AhmadF.Cheema (talkcontribs)

I am assuming that you are running MediaWiki on Linux.

If you have access to SSH, change your directory (cd) to your Wiki directory and run the following command:

chmod a+x extensions/SyntaxHighlight_GeSHi/pygments/pygmentize

OR, if you have access to a file explorer for your uploaded files, browse to <WIKI DIRECTORY>/extensions/SyntaxHighlight_GeSHi/pygments/, there should be a pygmentize file inside and a column for file permissions. See what permissions it has been set.

Aka sektor (talkcontribs)

Maybe work this Extension:GoToShell

I try to use your command

Aka sektor (talkcontribs)

Checked. Not any effect.

AhmadF.Cheema (talkcontribs)

Does your hosting provide a file manager for your uploaded files? Can you visually check what permissions have been set for the pygmentize file?

OR, if that's not possible run the following command:

ls -la extensions/SyntaxHighlight_GeSHi/pygments/pygmentize > foo.txt

and see what gets written in foo.txt in your Wiki directory.

Aka sektor (talkcontribs)

Ok, I do it, this writen in the foo.txt:

-rwxr-xr-x 1 h99724 h99724 842005 Jul 13 22:15 extensions/SyntaxHighlight_GeSHi/pygments/pygmentize

Of course I have file manager on hosting, but I use FileZilla and FTP access.

How check that permissions? Open in the Notepad file pygmentize? But Notepad dont understand file syntax.

I can only read the first line:

#!/usr/bin/env python

AhmadF.Cheema (talkcontribs)

The -rwxr-xr-x part in foo.txt are describing the permissions for the pygmentize file, which are fine.

Aka sektor (talkcontribs)

Yes, your code for lang python is highlighting.

But my problem with lang "lua".

AhmadF.Cheema (talkcontribs)

Apologies, I misunderstood, I thought all languages were having problems highlighting.

Aka sektor (talkcontribs)

No more ideas how to fix the problem?

Aka sektor (talkcontribs)

Have to wait for the update 1.29.1

Aka sektor (talkcontribs)

Where update?

AhmadF.Cheema (talkcontribs)

This issue is present for some users in at-least MediaWiki v1.28.2 too. I think a bug report will need to be filed for this.See, How to report a bug.

Aka sektor (talkcontribs)

In 1.28.2 - it's work 100%

Aka sektor (talkcontribs)

Why do not they fix it for so long? Where is the update?

AhmadF.Cheema (talkcontribs)

Have you already reported this bug on phabricator?

Aka sektor (talkcontribs)

https://phabricator.wikimedia.org/T173301

So?

91.248.150.85 (talkcontribs)

I understand that with Mediaiki 1.29, the language "lua" no longer gets highlighted.

Although highlighting worked correctly in MW 1.28.2, I think this is not one of the usual cases where highlighting support was present in older versions of MediaWiki (where in fact GeSHi had still been used), but went away in newer ones. According to https://releases.wikimedia.org/mediawiki/1.29/mediawiki-1.29.0.tar.gz, the extension should parse "lua" just fine...

Maybe there still are some files from older versions of MediaWiki present inside the installation?

Aka sektor (talkcontribs)

For example? What files? Folder Extenisions? SyntaxHighlight_GeSHi ?

No. I did not touch it. Only installed the engine from the archive.

I repeat: the extension works partially.

If I did something, it would not work at all

94.217.149.6 (talkcontribs)

I have the same problem.

Maybe this could be the problem?

Product Version
MediaWiki 1.29.0
PHP 5.6.29 (cgi-fcgi)
MariaDB 10.1.20-MariaDB
SyntaxHighlight 2.0 (f18e070)21:05, 17 May 2017 GPL-2.0+ Provides syntax highlighting <syntaxhighlight> using Pygments - Python syntax highlighter Brion Vibber, Tim Starling, Rob Church, Niklas Laxström, Ori Livneh and Ed Sanders
This comment was hidden by 151.249.164.138 (history)
Aka sektor (talkcontribs)

No. This 100% mistake of developers MediaWiki. They already admitted this error in versions 1.28.0 & 1.28.1

Check: https://lists.wikimedia.org/pipermail/mediawiki-announce/2017-April/000209.html

"Due to a mistake in packaging, the releases 1.27.2 and 1.28.1 did not contain the fix for SyntaxHighlight_GeSHi. This new release does contain that fix."

Nothing remains, except how to expect the release of the next version 1.29.1

2003:72:6D05:7900:EDB3:E480:1C2A:17 (talkcontribs)

I would now download the MediaWiki tarball again and extract it somewhere on the server. Then I would run diff to compare the newly downloaded files with what is present in the installation. This will show which additional files are there...

Reply to "MW 1.29.0 bug with SyntaxHighlight extension"

Want to Install ConfirmAccount, but UpgradeKey Won't Work

1
LaMirkat (talkcontribs)

I'm trying to update so I can use the ConfirmAccount extension. It failed to work using the Mac Terminal app, so I want to do it through the browser.

The problem is that it tells me that the upgradekey that I copied from local settings isn't accurate. I know it is copied correctly, and I have not changed any values.

Please help? I've spent almost four hours on this issue, and I'm ready to tear out my hair. I'm using version 1.29 of MediaWiki.

Reply to "Want to Install ConfirmAccount, but UpgradeKey Won't Work"
173.8.114.137 (talkcontribs)

Upgraded PHP to current, installed new wiki, and when trying to pull it up I get an error:

"MediaWiki 1.29 internal error

Installing some external dependencies (e.g. via composer) is required.

External dependencies

MediaWiki now also has some external dependencies that need to be installed via composer or from a separate git repo. Please see mediawiki.org for help on installing the required components."

I've installed Composer, run 'composer --dump-autoload' to create the \vendor\autoload.php file. When running 'composer update --no-dev' I get the same error every time:

[ErrorException]

Class 'Wikimedia\Timestamp\TimestampException' not found

Any thoughts?

2003:72:6D1E:1400:B197:E34:89A1:B6C3 (talkcontribs)

According to Topic:Tun121xrbndcqdet, user Grantkinkead knows the solution of your problem, but he has not yet shared it. Asking him might help you further...

Reply to "MW 1.29, dependencies, and composer"

There seems to be a problem with your login session; this action has been canceled as a precaution against session hijacking. Go back to the previous page, reload that page and then try again.

4
12.197.215.194 (talkcontribs)

I have just set up MediaWiki (1.29.0) on an AS400 IBM i machine. Though I can navigate the site, as well as create/edit pages, I cannot log in or create a new account. Every attempt to do so gives me "There seems to be a problem with your login session; this action has been canceled as a precaution against session hijacking. Go back to the previous page, reload that page and then try again."

I have tried adding "session_save_path("tmp");" to LocalSettings.php, as well as play with values of $wgMainCacheType and $wgSessionCacheType with no luck. Currently, my shared memory settings in LocalSettings.php have only these two lines:

$wgMainCacheType = CACHE_ACCEL;

$wgMemCachedServers = [];

How can I fix this? I believe my CSRF token is not being correctly cached in my session, but I'm not sure how to correct it.

I am using MariaDB as a database, Apache for the server, and PHP 5.5.37.

Ciencia Al Poder (talkcontribs)

If you have $wgMainCacheType = CACHE_ACCEL; you should provide a persistent data storage in $wgSessionCacheType

12.197.215.194 (talkcontribs)

I have $wgSessionCacheType = CACHE_DB;

I've been able to look into my objectcache table, and found that MWSession is being stored correctly, (as in it's the same value as <my-wiki>_session in the response header's cookie). Is there another location where that value is written/read? I figure since I know it's being cached, but my comparison is still failing, that the fault is probably in getting/setting whatever value the cached token checks against, right?

Also, for what it's worth, I've since tried installing MediaWiki using version 1.27.3, but I'm still facing the same problem.

12.197.215.194 (talkcontribs)

Another update: I've been fiddling with the source code to see if I can narrow down where my problem is occurring. This is what I'e found:

AuthManagerSpecialPage::trySubmit() is where the token mismatch is caught. $requestTokenValue and $sessionToken are not the same

setting $secret in Token::__construct to some constant allows me to sidestep the "hijacking" error, but in it's place is the error "Cookies may be disabled. Ensure you have cookies enabled start again" (my cookies are enabled), as well as the warning "You are already logged in as <username>. Use the form below to log in as another user" ("log in" changes to "sign out", but navigating away from the page at all signs me out). Supplying an incorrect password or username yields the appropriate error there, so WikiMedia is correctly able to check my credentials.

Obviously, making $secret a constant wasn't going to solve my problem, but hopefully faking it through the first error can shed some more light on what's actually going wrong.

Reply to "There seems to be a problem with your login session; this action has been canceled as a precaution against session hijacking. Go back to the previous page, reload that page and then try again."

Built-in Search Not Returning Page Text Results

1
50.234.209.106 (talkcontribs)

MediaWiki: 1.27

PHP: 7.1.1

Database: MSSQL 2008R2

I'm setting up an internal wiki. It currently only has the default main page and test page with text. The built in search only returns results for queries that mach exact page titles. For example, the main page will only show up in the results if "main page" is the search. Nothing is returned if you try to search for specific words that exist on the page. I tried removing the rows in the searchIndex table and running rebuildTextIndex.php. I also tried rebuildAll.php. The rebuildTextIndex script ran fine, but rebuildAll crashed when rebuilding links. The entries in the searchIndex table appear as Chinese characters. I'm not sure if this is just because the results from rebuildTextIndex aren't human readable and happen to fall in that section of characters, or if the script is actually returning incorrect values.

Reply to "Built-in Search Not Returning Page Text Results"

My mediawiki server times out on edit?

4
Wollington (talkcontribs)

Hey all! I'll preface this with saying that I'm by no means an advanced user of mediawiki, let alone Linux. I'm more of just a casual user than anything.

So I have a MW server installed on a raspberry pi and the last few days it's been having an issue with making edits to pages. The pages load fine for viewing, but the editing is what has an issue. I tried looking around and trying to install a php profiler to see what was causing the issue, but for some reason pecl isn't a command on my machine. I've also tried disabling all my extensions and trying to make an edit, but it still times out on me, so I don't think it's the extensions. I kinda feel like it's having an issue with writing to the database, but again, I'm more of an armchair admin than someone who knows what they're doing.

Any help would be greatly appreciated!

Malyacko (talkcontribs)

See https://www.mediawiki.org/wiki/How_to_debug - basic version information also welcome.

Ciencia Al Poder (talkcontribs)

See also Topic:Tuzbboot0de7nuzk

Wollington (talkcontribs)

Fixed!

Ended up being an issue with a dynamic IP, of all the stupid simple things that could've gone wrong. Set each instance of the old IP in LocalSettings to the new one, everything is working fine now.

Remember kids, check your IP.

TraaBBIT (talkcontribs)

Hello.

On my page

http://westeros.com.pl/Lata_po_Podboju_Aegona/Obliczenia_Lat_(Kontynuacja)#Przypisy

I get error on some refs:

Błąd rozszerzenia cite: Nieprawidłowy znacznik <ref>; nazwę „Rtwoiaf_the_westerlands:_house_lannister_under_the_dragons.7B.7B.7B3.7D.7D.7D” zdefiniowano więcej niż raz z różną zawartością Błąd rozszerzenia cite: Nieprawidłowy znacznik <ref>

Ciencia Al Poder (talkcontribs)

The message is self-explanatory. You have {{Ref|TWOIAF| The Westerlands: House Lannister Under the Dragons}} with case variants (upper/lower)

TraaBBIT (talkcontribs)

So what should I do?

AhmadF.Cheema (talkcontribs)

If I understand the issue correctly, the first reference in the article's section "Jason Lannister (syn Gerolda)" is the problem. There is a case mismatch for the reference.

In the other four places for the reference, the name is {{Ref|TWOIAF| The Westerlands: House Lannister Under the Dragons}} while at this place, it is {{Ref|TWOIAF| The Westerlands: House Lannister under the Dragons}}. That is, with a lower case under. Change it to uppercase.

TraaBBIT (talkcontribs)

That it is. Thank You.

TraaBBIT (talkcontribs)

I have one more question.

Can I have in one article two refs looking similar?

Like:

ref|TWOIAF| Targaryenowie na Tronie: Maekar I

ref|twoiaf| Targaryenowie Na Tronie: Daeron II

Ciencia Al Poder (talkcontribs)

The "name" parameter of the ref must be unique on the page, or if it's not, they should have the same content. Having 2 different refs is okay as long as you don't use the same "name"

Reply to "Issue with refs"

How many teeth has the chain of distribution of the fiat lancia ZLA 840000*01057711

2
190.6.84.132 (talkcontribs)

How many teeth has the chain of distribution of the fiat lancia ZLA 840000*01057711

AhmadF.Cheema (talkcontribs)

This support forum is for queries related MediaWiki software and your question is unrelated to it.

Reply to "How many teeth has the chain of distribution of the fiat lancia ZLA 840000*01057711"