How can i edit the donate link in side bar.
Project:Support desk
Jump to navigation
Jump to search
Reply to "How do I delete or edit the Donate link in side bar"
Reply to "Creating Two media wiki on same domain"
Reply to "Right-to-Left issue: Flip parenthesis inside a link"
Reply to "Add expires headers?"
Reply to "Problems with a project (links)"
Reply to "Trouble with transfer/upgrading"
Reply to "Can't Edit Main Page after Deleting Revisions"
Reply to "Hunk #2 FAILED at 245 when applying MW 1.31.16 patch"
Reply to "Cyrillic URL encode"
Reply to "Duplicate rows in Cargo"
Side bar can be edited at: Mediawiki:Sidebar
See manual:Sidebar
Hello I don't know if this is a good idea.
For Example I have a wiki website that function like Wikipedia to at www.en.website.com and I am trying to create another website that function like wikidata.
www.wikidata.website.com... Which is I created my wiki on a subdomain and I want to create another wiki on another subdomain... What do you think? Should i continue or i should buy different hosting for the wikidata.
Just Like the way there is Wikipedia and simple.wikipedia
Doesn't really matter, do whichever meets your needs.
MediaWiki 1.36.1 in Hebrew.
In the following text, the parenthesis adjacent to the English text should appear from the right but appears from the left.
[[מתודת document.write()]]
I tried to fix it with a template changing right to left.
Template:מל
<span dir="ltr">{{{1}}}</span>
Input
[[מתודת {{מל|document.write()}}]]
Output
[[מתודת document.write()]]
My question
As my fix try failed, how would you suggest to try to fix it?
I think that's just how the HTML pre tag works.
[[מתודת ()document.write]]
You could just type it the wrong way round :-)
@Jonathan3 thanks, I really want to avoid such tricks to ensure easy maintenance in the long run.
I might do it with JavaScript though.
What effect (overall) are you trying to achieve?
Just that the parenthesis in the output will be on the right.
welcome to BIDI land!
So computers don't know if the parenthesis go with the hebrew or the english text.
One way to fix: add ‎ immediately after the parenthisis. This is an invisible character called a LEFT-TO-RIGHT MARK that looks like an english character in terms of directionality. If () is surrounded by "english" characters (including ‎) on both sides they should behave like english parenthesis
[[מתודת document.write()‎]]
The other alternative is like you were doing with the direction tag, but just for the english part.
[[מתודת document.write()|מתודת <span dir="auto">document.write()</span>]]
As you can see, the wikitext source looks messed up but it should look fine when rendered. (Dir=auto is newer compared to dir=ltr. Its a bit less confusing how it works compared to dir=ltr. Either should work in this case.).
if typing it out in a ltr wiki, the wikitext source looks like
[[מתודת document.write()|מתודת <span dir="auto">document.write()</span>]]
There are also some other override characters. Honestly, they are rarely needed and a bit confusing how they work and difficult to type. 99% of the time ‎ ‏ (Or equivalently &רלמ; . RIGHT-TO-LEFT MARK is the only one with a hebrew equivalent. The hebrew equivalent is a custom mediawiki thing and doesn't work in normal html) and <span dir=auto>. If you want to learn more on the subject see https://www.w3.org/International/articles/inline-bidi-markup/uba-basics and https://www.w3.org/International/articles/inline-bidi-markup/ which also lists the more obscure control characters and what they do.
Thanks a lot Bawolff, I should seek some single-character-character which represents the multi-character-character ‎
Things starting with & in wikitext are just another way to write a character. E.g. you can write → directly or you can do → which will make the same character.
Similarly, you can write ‎ directly. It can just be difficult because its an invisible character, so its hard to copy and paste. On windows you can insert by holding down alt, typing a + character and then 200E (200F if you want rlm instead of lrm)
I'm doing a little performance tuning and see that one of the recommendations is "Add expires headers". What does this mean and how can I do it?
is this some sort of analysis tool that is telling you this ?
It's likely something like Pingdom. For MediaWiki sites one of the things it says is "Add Expires headers. Web pages are becoming increasingly complex with more scripts, style sheets, images, and Flash on them. A first-time visit to a page may require several HTTP requests to load all the components. By using Expires headers these components become cacheable, which avoids unnecessary HTTP requests on subsequent page views. Expires headers are most often associated with images, but they can and should be used on all page components including scripts, style sheets, and Flash."
I've always wondered how to interpret or address this sort of stuff but have never had the time to look into it :-)
It very much depends. WMFs caching is different from MediaWiki's for instance and in general, whenever caching is applied by Mediawiki via Cache-control, it also sets a max-age.
But it really depends on the specific request. Overall, I'd say that in general MediaWiki does a LOT of caching and just because some tool found a situation in the dozens of different request that it thinks it has a problem with, doesn't mean you have a big performance problem.
Yes it was Pingdom.
I've just tested http://www.pingdom.com/ using their own website and it produces exactly the same suggestion :-)
I guess I'm not going to worry about it. Hurts my feelings though when Pingdom gives an F grade.
It gives its own website 4 Fs so maybe is feeling sorry for itself too :-)
GRADE SUGGESTION F0 Reduce DNS lookups F0 Make fewer HTTP requests F0 Compress components with gzip F0 Add Expires headers F40 Avoid URL redirects E60 Use cookie-free domains B89 Configure entity tags (ETags)
Hello there,
The problem is that when respondents click on the link, a blank screen appears, it is random, in some cases it happens yes and in others it does not. It is also that the password is incorrect although it is not, refreshing the page loads correctly.
We did the test on another server by exporting the survey and importing it and the same thing happens to us.
We want to know if the problem may be in the design of the form or is it a limesurvey bug and if someone can give us a solution or tip.
@Paulo Nuchi We are not Limesurvey. You'll have to contact Limesurvey for Limesurvey questions. See the sidebar.
I have a wiki at https://www.informationism.orgthat I had hosted at Siteground. Because it was going to cost me so much to continue hosting it there I moved to Hostinger and got them to transfer the site. However after transfer there was no content on the pages. This issue may be a well known one: Topic:Sdqa68uut9dw9zo5 and Manual:Common errors and symptoms#All pages have no content.2C but when editing a page the wiki text is there
The advice is to upgrade which I attempted to do so. However when I upgraded I got the message that the wiki couldn't access the database. So now I have two installations of mediawiki that don't work and Hostsinger say they can't help because they are not "software developers" is there anyone here who could help me get back on my feet?
Hmm mw 1.16 and php 5.3. That is pretty old. So yeah, you need to upgrade mediawiki (or downgrade pcre that php is linked to)
To start with, to upgrade mw you would have to upgrade php.
If command line php says it cant connect to db, that might meandb drivers are not installed for it or not enabled in php.ini. remember that cli php is totally different than web php and can have different version or config.
Thanks very much for your help. On my new installation: https://www.informationism.org/mediawiki-1.25.2/index.php It says:
Sorry! This site is experiencing technical difficulties.
Try waiting a few minutes and reloading.
(Cannot access the database)
Is there any advised quick fix for this?
Sounds rough. Make sure you keep good backups. Keep in mind you'll run into trouble with different versions of mediawiki, mysql, and php.
I think your best bet is to do gradual upgrades until you get to a Mediawiki version that supports php7.1. Then do a dump and a fresh install on the new server. (to change to 7.1 How to Change the PHP Version of Your Website – Hostinger Tutorials)
It's kind of lame that your new host didn't know this. Another route might be just get a refund and try someone else.
Is there a way to overcome the following error?
MWexception ... could not find text for current revision
It prevents the user from editing the Main page.
Said user is a teacher in our network who has been using MediaWiki since 2009 to get learners to create a knowledge base. This semester, a student pointed out that it was possible to use page history to access pages from previous years. In this case, that'd be a strategy to cheat in the assignment.
One solution found was to delete revisions.
Help:RevisionDelete - MediaWiki
This was done directly in the database. And it was working... until the user deleted revisions for the Main page.
Now, the Main page says that revision number NNNN doesn't exist and that it should be solved in the deletion log... which is empty.
Attempting to edit the Main page produces the aforementioned exception (which is apparently a “Sanity check for bug 37225”).
Adding and editing other pages still works.
The database backup would be difficult to retrieve.
What's the best course of action, at this point? Is there a way to create a new Main page? Creating a blank revision?
Thanks!
> This was done directly in the database. And it was working... until the user deleted revisions for the Main page.
The page you linked does not suggest directly editing the db. Can you list exactly what commands you did?
Generally speaking,bad things happen when you delete the most recent revision of a page (you should first make a new revision without the info and delete the old one).
If you just modified rev_deletrd field you could just set it back to 0 on the page in question. If you actually deleted the whole row, you could try putting it back, or just delete the whole page entirely and recreate it.
@Bawolff: The teacher did delete the entire row for the latest revision. So I guess the best thing to do is to delete the page. How do we recreate it afterwards? (I did retrieve the Main page's content from a cache. I just want to know how to create a new Main page.)
Of course, you're right, the instructions didn't talk about the db. The teacher and a ped counsellor were already using the db to delete pages in bulk. I do realize it wasn't the proper approach. It's the one which was most compatible with existing practice.
For reference, here's how it went:
We all went to the `revision` table and tested with a single revision, then with revisions for the same page. Once we checked that it had the desired result, we set about doing the same for all the other unwanted revisions. If memory serves, there were 17k of them.
With the `revision` table set to 250 rows, we'd select all rows, unselect the initial and most recent revisions, and click delete. The teacher finished that process.
So... As long as I know how to create a new Main page, I guess it'll be the best approach. Maybe I'll try that on a separate instance.
I tried to apply the patch 1.31.16 to two 1.31.15 installations with the following result:
... checking file includes/specials/SpecialContributions.php Hunk #2 FAILED at 245. 1 out of 2 hunks FAILED checking file includes/widget/search/FullSearchResultWidget.php ...
You mean this one https://releases.wikimedia.org/mediawiki/1.31/mediawiki-1.31.16.patch.zip on top of this one: https://releases.wikimedia.org/mediawiki/1.31/mediawiki-1.31.15.zip ???
Worked without a hitch for me with a clean apply. Are you sure of your versions ?
yes. I downloaded the .gzip version though. All the patching went great on MW 1.35, but in both my tries with MW 1.31.15 I got the messeage above.
In my second instance, I even had to patch the installation up to 1.15 which also went smootly, only the last patch showed the problem.
so you applied multiple patches on 1.31 ? First to bring it to 1.31.15 and then to 1.31.16 ?
in one case yes. It was on 1.31.12 and I brought it up to 1.31.15 and failed with 1.31.16. The other installation was already on 1.31.15 (by applying patches when they were issued).
k, what I think is the simplest, is to download a 1.31.5 original zip, unpack it next to your own installation (be careful not to override when unzipping). Then run diff -ruN 1.31.5-download/includes yourinstallation/includes
just to see what the differences between the 2 bases are.
diff -ruN mediawiki-1.31.15/includes/api/ApiQueryRecentChanges.php silver/includes/api/ApiQueryRecentChanges.php --- mediawiki-1.31.15/includes/api/ApiQueryRecentChanges.php 2021-06-23 16:27:44.000000000 +0200 +++ silver/includes/api/ApiQueryRecentChanges.php 2019-07-11 10:06:50.000000000 +0200 @@ -631,8 +631,8 @@ if ( isset( $params['show'] ) && $this->includesPatrollingFlags( array_flip( $params['show'] ) ) ) { - return 'private'; - } + return 'private'; + } if ( isset( $params['token'] ) ) { return 'private'; } diff -ruN mediawiki-1.31.15/includes/auth/AuthManager.php silver/includes/auth/AuthManager.php --- mediawiki-1.31.15/includes/auth/AuthManager.php 2021-06-23 16:27:44.000000000 +0200 +++ silver/includes/auth/AuthManager.php 2020-09-28 09:58:27.739140044 +0200 @@ -897,8 +897,8 @@ // When the main account's authentication data is changed, invalidate // all BotPasswords too. if ( !$isAddition ) { - \BotPassword::invalidateAllPasswordsForUser( $req->username ); - } + \BotPassword::invalidateAllPasswordsForUser( $req->username ); + } } /**@}*/ diff -ruN mediawiki-1.31.15/includes/logging/LogEventsList.php silver/includes/logging/LogEventsList.php --- mediawiki-1.31.15/includes/logging/LogEventsList.php 2021-06-23 16:27:44.000000000 +0200 +++ silver/includes/logging/LogEventsList.php 2019-07-11 10:06:56.000000000 +0200 @@ -568,7 +568,7 @@ * @return bool */ public static function userCanViewLogType( $type, User $user = null ) { - if ( $user === null ) { + if ( $user === null ){ global $wgUser; $user = $wgUser; } diff -ruN mediawiki-1.31.15/includes/specials/SpecialChangeEmail.php silver/includes/specials/SpecialChangeEmail.php --- mediawiki-1.31.15/includes/specials/SpecialChangeEmail.php 2021-06-23 16:27:44.000000000 +0200 +++ silver/includes/specials/SpecialChangeEmail.php 2019-07-11 10:06:50.000000000 +0200 @@ -61,9 +61,9 @@ parent::execute( $par ); } - protected function getLoginSecurityLevel() { - return $this->getName(); - } + protected function getLoginSecurityLevel() { + return $this->getName(); + } protected function checkExecutePermissions( User $user ) { if ( !AuthManager::singleton()->allowsPropertyChange( 'emailaddress' ) ) { diff -ruN mediawiki-1.31.15/includes/specials/SpecialContributions.php silver/includes/specials/SpecialContributions.php --- mediawiki-1.31.15/includes/specials/SpecialContributions.php 2021-06-23 16:27:44.000000000 +0200 +++ silver/includes/specials/SpecialContributions.php 2020-12-22 15:14:53.657816326 +0100 @@ -248,20 +248,20 @@ } $work = new PoolCounterWorkViaCallback( 'SpecialContributions', $poolKey, [ 'doWork' => function () use ( $pager, $out ) { - # Show a message about replica DB lag, if applicable - $lb = MediaWikiServices::getInstance()->getDBLoadBalancer(); - $lag = $lb->safeGetLag( $pager->getDatabase() ); - if ( $lag > 0 ) { - $out->showLagWarning( $lag ); - } + # Show a message about replica DB lag, if applicable + $lb = MediaWikiServices::getInstance()->getDBLoadBalancer(); + $lag = $lb->safeGetLag( $pager->getDatabase() ); + if ( $lag > 0 ) { + $out->showLagWarning( $lag ); + } - $output = $pager->getBody(); - if ( !$this->including() ) { - $output = '<p>' . $pager->getNavigationBar() . '</p>' . - $output . - '<p>' . $pager->getNavigationBar() . '</p>'; - } - $out->addHTML( $output ); + $output = $pager->getBody(); + if ( !$this->including() ) { + $output = '<p>' . $pager->getNavigationBar() . '</p>' . + $output . + '<p>' . $pager->getNavigationBar() . '</p>'; + } + $out->addHTML( $output ); }, 'error' => function () use ( $out ) { $msg = $this->getUser()->isAnon() diff -ruN mediawiki-1.31.15/includes/specials/SpecialEditTags.php silver/includes/specials/SpecialEditTags.php --- mediawiki-1.31.15/includes/specials/SpecialEditTags.php 2021-06-23 16:27:44.000000000 +0200 +++ silver/includes/specials/SpecialEditTags.php 2019-07-11 10:06:50.000000000 +0200 @@ -225,7 +225,7 @@ // phpcs:ignore Generic.CodeAnalysis.ForLoopWithTestFunctionCall for ( $list->reset(); $list->current(); $list->next() ) { $item = $list->current(); - if ( !$item->canView() ) { + if ( !$item->canView() ){ throw new ErrorPageError( 'permissionserrors', 'tags-update-no-permission' ); } $numRevisions++; diff -ruN mediawiki-1.31.15/includes/user/User.php silver/includes/user/User.php --- mediawiki-1.31.15/includes/user/User.php 2021-06-23 16:27:44.000000000 +0200 +++ silver/includes/user/User.php 2021-10-01 16:45:58.107282616 +0200 @@ -1801,8 +1801,8 @@ ? $sessionUser->getName() : IP::sanitizeIP( $sessionUser->getRequest()->getIP() ); if ( $this->getName() === $globalUserName && !$this->isAllowed( 'ipblock-exempt' ) ) { - $ip = $this->getRequest()->getIP(); - } + $ip = $this->getRequest()->getIP(); + } // User/IP blocking $block = Block::newFromTarget( $this, $ip, !$bFromSlave ); diff -ruN mediawiki-1.31.15/includes/user/UserGroupMembership.php silver/includes/user/UserGroupMembership.php --- mediawiki-1.31.15/includes/user/UserGroupMembership.php 2021-06-23 16:27:44.000000000 +0200 +++ silver/includes/user/UserGroupMembership.php 2020-05-26 14:33:37.903366159 +0200 @@ -396,7 +396,7 @@ // link to the group description page, if it exists $linkTitle = self::getGroupPage( $group ); - if ( $format === 'wiki' ) { + if ( $format === 'wiki' ) { if ( $linkTitle ) { $linkPage = $linkTitle->getFullText(); $groupLink = "[[$linkPage|$groupName]]"; @@ -407,8 +407,8 @@ if ( $linkTitle ) { $groupLink = Linker::link( $linkTitle, htmlspecialchars( $groupName ) ); } else { - $groupLink = htmlspecialchars( $groupName ); - } + $groupLink = htmlspecialchars( $groupName ); + } } if ( $expiry ) { @@ -420,9 +420,9 @@ $expiryT = $uiLanguage->userTime( $expiry, $uiUser ); if ( $format === 'wiki' ) { - return $context->msg( 'group-membership-link-with-expiry' ) - ->params( $groupLink, $expiryDT, $expiryD, $expiryT )->text(); - } else { + return $context->msg( 'group-membership-link-with-expiry' ) + ->params( $groupLink, $expiryDT, $expiryD, $expiryT )->text(); + } else { $groupLink = Message::rawParam( $groupLink ); return $context->msg( 'group-membership-link-with-expiry' ) ->params( $groupLink, $expiryDT, $expiryD, $expiryT )->escaped();
URL problem:
Cyrillic renders correctly in MediaWiki Sidebar, but Cyrillic is encoded in articles(titles).
Example:
On other WiKi, there is no problem.
What is the problem?
MediaWiki 1.36.1
PHP 7.4.21 (apache2handler)
MariaDB 10.5.11-MariaDB-1
It is necessary to correctly display the Cyrillic alphabet in articles (headings), and encode the URL only when copying.
Thanks.
My WiKi:
arch-cat.ru/
I dont see anything onviously wrong when i go to your site. Can you be more specific?
Yes, the spam filter is in the way.
When using the content(mw-toc-heading), the url is encoded. How to remove it?
arch-cat.ru/index.php/Debian#URL encoded
On other wiki, no problem.
ru.wikisource.org/wiki/Александр_Сергеевич_Пушкин#URL not encoded
When using content(mw-toc-heading), url is not encoded, encoded only when copied. How can I do the same?
Thanks.
Oh. See Manual:$wgFragmentMode
It works, thanks.
I have installed mediawiki and Cargo 3.0, using Postrgesql 13. I am following the book catalog example and have got it mostly working. However, I get duplicate rows of books. How can I fix this?
This is a known problem - best to head over to Cargo's talk page with full details.
My workaround is to use GROUP BY in all queries, and periodically to recreate the tables...