Project:Support desk/Sections/Miscellaneous

__NEWSECTIONLINK__ = Unsorted Threads =

Terminology - Call

 * MediaWiki: (Reported by your Wiki's Special:Version page)
 * PHP:
 * MySQL:
 * URL:

Would it be correct to say that index.php "calls" the Logo image, calls the menus, etc? Smaug 22:32, 2 March 2008 (UTC)


 * I would say "define", and please, Smaug, use the template to post your topic. -PatPeter, [[Image:Tournesol.png|20px]] MediaWiki Support Team  19:33, 3 March 2008 (UTC)
 * The logo image path is defined in LocalSettings.php which is included by index.php --Nad 21:40, 9 March 2008 (UTC)
 * Thank you. Smaug 18:25, 18 March 2008 (UTC)

Lost sysop access
OH CRAP!!!!! I was trying to figure out how to turn on uploads (still haven't figured that one out yet: documentation is not easily found on this site) and I accidentally killed my bureaucrat privileges on the Userrights Page. Poof! How do I restore them???? No one else is a Bureaucrat and I can't find anything on this site to help me fix this.
 * MediaWiki: 1.10.1
 * PHP: 5.1.4
 * MySQL: 4.1.22
 * URL: I'm too embarrassed to release this!

I'm just starting to learn the ins and now especially the outs of PHP and SQL...is there a way of fixing this in MySQL? or in one of the myriad of PHP files?

Thanks!

—Keng 23:45, 10 March 2008 (UTC)
 * You'll need to update the database directly with the following query. First login and go to Special:Preferences to get your user id number (I've used 999 in the example below, so replace that with your own user id), then shell in to your server or do a query with whatever means you have of accessing your database. Also note that if you're using a table prefix you'll need to prepend that to the user_groups table name.

INSERT INTO user_groups (ug_user,ug_group) VALUES(999,'sysop');
 * --Nad 02:18, 13 March 2008 (UTC)
 * Also regarding uploads, you need to set $wgEnableUploads to true in your LocalSettings.php. There are also a number of other settings relating to uploads, see Category:Upload variables. --Nad 02:27, 13 March 2008 (UTC)


 * MediaWiki: (Reported by your Wiki's Special:Version page)
 * PHP:
 * MySQL:
 * URL:

Hi. I'm terribly sorry, but I happened to create the page myTestPage on the mediawiki.org Wiki when I thought I was doing on my newly installed own wiki page (because they look so similar). Could you please delete this page?

Questions? Mail me at anders@kupa.se.

—193.15.169.146 14:19, 13 March 2008 (UTC)


 * MediaWiki: (Reported by your Wiki's Special:Version page)
 * PHP:
 * MySQL:
 * URL:

Is it possible to include the HTML code below in a wiki page without installing Google Maps extension ?

 View Larger Map

—201.21.160.180 15:14, 13 March 2008 (UTC)

How to integrate media wiki log in with website?
How to integrate media wiki log in with website.? Please help ....


 * You mean how do you sync the MW login with non-MW login elsewhere on your site? It depends on how the rest of your website logs users in. Smaug  18:28, 18 March 2008 (UTC)

Fatal Error on 'Recent Changes'

 * MediaWiki: 1.12.0
 * PHP: 5.?
 * MySQL: 4.?
 * URL: Wyfopedia

My wiki has just stopped working. I can get ftp to it. Help!

-Wyfopedia 21:23, 14 March 2008 (UTC)

Hi I have created an MediaWiki account now. IF you want to know what versions I'm on then please instruct me on how to find out. I'm worried that I have lost my database. I can see my wiki images. If I can download the database and images, I don't mind re-installing again from scratch. -Wyfopedia 21:31, 14 March 2008 (UTC)
 * You appear to have some problems with your rewrites. As a first measure you can set $wgUsePathInfo to false in your LocalSettings.php. Bryan Tong Minh 20:54, 15 March 2008 (UTC)


 * Thank you for your help Bryan Tong Minh. Wyfopedia 20:01, 21 March 2008 (UTC)

I have backed up the database and image files, and upgraded to v. 1.12.0. The site now seems to be working again. However, I have the following error on 'Recent Changes':

'Fatal error: Class 'ChangesList' not found in /home/fhlinux182/w/wyfopedia.org.uk/user/htdocs/includes/SpecialRecentchanges.php on line 221'

-Wyfopedia 20:01, 21 March 2008 (UTC)

Pages imported by ImportTextFile.php NOT searchable

 * MediaWiki: 1.8.3
 * PHP: 5.2.0
 * MySQL: 5.0.27
 * URL:

I am using ImportTextFile.php to import a number of pages and they show up in Recent Changes.

But if I do a search on some text that I know is in the pages, the results are NOT showing them.

Is there a way that I can ensure that these pages are also searchable?

Thanks.

—68.147.72.69 06:34, 15 March 2008 (UTC)


 * Run the updateSearchIndex.php maintenance script. Emufarmers 02:23, 21 March 2008 (UTC)

Changing sidebar according to article-language

 * MediaWiki: 1.10.1
 * PHP: 5.2.4 (cgi-fcgi)
 * MySQL: 5.0.27
 * URL: www.GS-500.info

Hi,

I'm currently translating my wiki from German to both English and Spanish. I'm happy with the solution to swap between the three languages, but as I modified the sidebar: Is there any possibility to indicate the article-language and change the sidebar accordingly? I already looked at Extension:LanguageSelector, Extension:Multilang and Extension: MultiLanguageManager but they all don't seem to tackle my problem as they assume the usage of an unchanged sidebar.

Kind regards, Timo

—82.11.169.246 11:09, 16 March 2008 (UTC)

questions
I have many questions :

- How can I create many pages automatically ? If I can't, is there another solution ? IS there a programm for injecting pages ( created by scripting shell) - How can I know all the pages depending on a page ? - How can I delete all the page created the same day ?

Thanks —192.54.193.51 09:36, 19 March 2008 (UTC)

http://www.mediawiki.org/wiki/Manual:FAQ#Importing_from_other_types_of_files

if you look through this site or use google you will find many helpful articles like that one JohnShep 20:42, 19 March 2008 (UTC)

CheckUser weirdness - please investigate

 * MediaWiki: 1.13alpha from SVN
 * PHP:
 * MySQL:
 * URL: it's on a localhost

I got CheckUser working, as well as Oversight and Makesysop, and surprisingly, despite what the CheckUser page here tells me, I didn't need run the command-line to get it working (to be honest, though, I actually had no PHP commandline utilities on XAMPP. Just added the SQL queries, and then copied the files to extensions directory, and for some reason, it actually worked and did a query. Is this a bug or is this meant to happen?? Should this go to Bugzilla?? Thanks, AP @ —82.42.237.84 15:08, 20 March 2008 (UTC)


 * How did en.wikipedia.org grant the rollback extension in the user rights log?? nothing in Special:Version about it. Thanks, AP @ --82.42.237.84 15:37, 20 March 2008 (UTC)


 * If you ran the SQL queries that the installation script includes, then you've done its job.


 * The non-sysop rollback functionality has been in the core code since version 1.11 (Manual:User_rights_management). Emufarmers 02:13, 21 March 2008 (UTC)


 * OK, so doing what I did above actually gets it working and it's not a bug?? Confused. AP @ --82.42.237.84 11:37, 22 March 2008 (UTC)


 * If it's actually working, then yeah. The installation script just happens to be more convenient (and less error-prone) than running the queries directly. —Emufarmers(T 01:31, 23 March 2008 (UTC)

Subcategories with the same name

 * MediaWiki: 1.11.2
 * PHP: 5.2.5
 * MySQL: 5.0.45
 * URL: not ready

For example,I want create 3 categories: -Slackware -Ubuntu -openSuse I want,that each category must have the subcategory called "Script". But the slackware's script,must be different from ubuntu's script and suse's script. It is possible?How?

—79.3.253.38 19:27, 20 March 2008 (UTC)


 * Maybe you could just call the ubuntu subcategory "Ubuntu script" and the suse subcategory "suse script". I don't know if doing what you want to do is possible.  Is this a suitable workaround? Smaug  19:39, 22 March 2008 (UTC)

Ajax Search doesn't work since 1.12.0 upgrade

 * MediaWiki: 1.12.0
 * PHP: 5.2.5 (apache2handler)
 * MySQL: 5.0.51
 * URL: I don't have URL because it is internal

Hi all,

I've upgrade MediaWiki 1.11.2 to 1.12.0 and everything went fine until I tested the AjaxSearch. It is not working anymore. In my LocalSettings.php I have $wgAjaxSearch = true; and to be sure I added $wgUseAjax = true;. I thought the problem may have been because of the upgrade, so I did a fresh install, but this did not helped at all.

Is there something new we need to do, so that the AjaxSearch actually works? Or is there a bug. I know AjaxSearch received some bugfix since the patch 1.12.0.

Thank you for your help.

Maxime.

—199.243.65.6 14:09, 21 March 2008 (UTC)

It seems like we now need to activate the AjaxSearch in the preferences of the user in the Search tab... Also, the new version of this Ajax search is bugged... I'll need to use the one from 1.11 + 1.12 to have a functional Search.

--199.243.65.6 14:57, 21 March 2008 (UTC)

Reading passwords of users

 * MediaWiki: 1.12.0
 * PHP: 5
 * MySQL: 4.1
 * URL: www.wikilh.tk

Hi. I have question. How I can read the password of my users? I dont want to change them, but i need to read them. I need fast answer. Thank you.

drake

—83.26.71.3 20:21, 23 March 2008 (UTC)
 * You can't. —Emufarmers(T 21:54, 23 March 2008 (UTC)
 * I don't know the answer, but I must assume that since they are stored somewhere in the database, there must be some way to read them, even if it requires some decryption. Smaug 00:33, 24 March 2008 (UTC)
 * MediaWiki salts its MD5-hashed passwords, which, as far as I know, makes decryption impractical, if not impossible.


 * The only sort of counsel that I'll offer is that this is not ethical, and you're wasting your time anyway. —Emufarmers(T 05:49, 24 March 2008 (UTC)

MediaWiki optimization

 * MediaWiki: 1.10.0
 * PHP: 5.2.5 (apache)
 * MySQL: 4.1.22-standard-log
 * URL: Fan History Wiki

My wiki had problems with pages loading where we ended up with a few thousand articles in a category. This caused these pages either not to load or to load slowly. I queried my host about this. They said, among other things:

We tested the above mentioned URLs and managed to re-create the issue on our end. It is most likely caused by the timeout settings of our shared hosting servers, especially if the problematic pages contain lots of links with reference to your application's database.

Upon further investigation, we found out that the home page of your wiki is also loading a little bit slowly, due to the 274 links on this page. It loads for more than 2 seconds locally on the server, which it should not load for more than 1 second.

We will recommend you to contact a developer which is familiar with the source code of your application and possesses the required knowledge for optimizing it. The optimization usually involves reducing the number of links on the pages, reducing the overall size of the application's database, creating indexes for each table in the database, etc.

I switched to a VPS which makes some pages which previously wouldn't load now load. I also optimized the database on phpMyAdmin. I removed a few of the extensions which were not being used actively. But if some pages link to certain categories, like Category:People, new pages won't create and will time out. What more can be done to optimize things, fix the overly large category problem or just generally make the wiki load faster? I really want to continue to grow Fan History but this has thrown me for a loop. Is this something I can fix myself?

—PurplePopple 02:29, 24 March 2008 (UTC)


 * Your site doesn't load for me, so I can't take a look at your categories, but we just had a similar query on the MWusers forums, and the simple answer was "caching." —Emufarmers(T 05:49, 24 March 2008 (UTC)


 * The whole site doesn't load or just those pages? I've added the caching elements by adding     $wgUseFileCache = true; and   $wgFileCacheDirectory = "$IP/cache"; to the local settings but it doesn't seem to make the load any faster.  I've removed a few more extensions.  I've removed Google Analytics. It is still taking about 15 seconds for me to get Category:People to load and about 3 to get the main page to load.  If I remove

$wgMainCacheType = CACHE_NONE; $wgMemCachedServers = array; $wgUseFileCache = true; $wgFileCacheDirectory = "$IP/cache";
 * 1) Shared memory settings


 * It actually seems to load a bit faster but not much. :/ (On a completely unrelated note, my host seems to have disabled image uploads...  *sighs*) --PurplePopple 12:09, 24 March 2008 (UTC)