Project:Support desk

Hi there! Could you please let me know if there is an extension that allows to make e-mail the message to all registered users?

What is the difference between Extension:LiquidThreads and Extension:StructuredDiscussions?

StructuredDiscussions was based on the work on the third version of LiquidThreads.

That means LiquidThreads are outdated and will sooner or later be replaced with StructuredDiscussions?

(Asking for the sake of translating.)

Extension:LiquidThreads answers this already? It says "unmaintained", it says "cancelled".

"later be replaced" depends on each wiki's admins; cannot generalize. :)

Ups, yes. I missed the notice. Thanks.

Hi everyone,

After migrating my wiki 1.28 in 1.30, my pictures are no longer displayed in my pages. Instead I have a link to the image. "www-data" is the owner of my images folder with this icon (https://rlv.zcache.be/icone_cassee_dimage_dinternet_photo_sur_toile-r69551bbb568344f6868770d9048c8cf2_a0ib_8byvr_324.jpg).

Any ideas?

Thx

If your wiki is public, please share a link so we can take a look at the problem.

Open a file description page (a page of the File: namespace) and click on the "view full size". If it displays an error instead of the file itself, something is misconfigured. If the error is a 404 not found, either MediaWiki is pointing to the wrong URL or your webserver has problematic rewrite rules. If error is a "forbidden" or "unauthorized", there may be problems with permissions of those files.

If it works fine, then problem may be for thumbnails.

Thank you Ciencia Al Poder

My wiki is not public ... However, I did your tests and everything works normally. When I remove the size of my thumbnail in my wikicode [[File: example.jpg | 400px | legend]] -> [[File: example.jpg | legend]] it works perfectly ...

Really strange ^^

Problem is on thumbnails, then. Use the thumb.php script (from your browser) to request a file on your wiki (with the "f" parameter) and provide a width for the thumbnail (the "w" parameter), and see what happens, if it's displayed correctly or it displays an error.

Hi,

I have the same problem. This doesn't work in my wiki:

[[File:image.png|thumb|My Image]]

this works:

[[File:image.png|frame|My Image]]

thumb.php works just fine:

thumb.php?f=image.png&w=200&h=200

My wiki is also a private wiki.

Maybe you turned off Manual:$wgGenerateThumbnailOnParse?

We face the same problem after upgrading to 1.30: Thumbnails are shown as broken images though they are correctly rendered on server side. The developer console of chrome reveals the following error messages:

Failed parsing 'srcset' attribute value since it has an unknown descriptor.

Dropped srcset candidate "/uploads/thumb/xxx.png/450px-xxx.png"

Failed parsing 'srcset' attribute value since it has an unknown descriptor.

Dropped srcset candidate "/uploads/thumb/xxx.png/450px-xxx.png"

GET https://aaa.bbb.ccc/5x 404 (Not Found)

Turning off Manual:$wgGenerateThumbnailOnParse and running maintenance script Manual:FAQ#…are some of my images not showing up after an upgrade does not fix the issue.

thumb.php works perfectly.

Maybe this thread deals with the same issue: Topic:U7m4bysmlzhqp0y1 ?

Is this a known bug, can anybody confirm this behaviour or is there any solution?

Inspect the image with the developer tools of your browser (right-click and inspect this element, or hit F12 and manually select the image). If the srcset property contains commas instead of dots, the problem is the server locale and you should change it on LocalSettings.php by adding:

setlocale(LC_NUMERIC, "C");

See task T181987

This fixed our problem, thank you!

Sorry for the delay, I had to let go of my investigation ... Thank you all for solution! It's resolved!

Hello, thanks for the trick but for me setlocale(LC_NUMERIC,"C"); has no effect..

dots are still replaced by comma in my html

Do you have an idea please ?

Many thanks (I'm from France, I upgraded PHP form 5.6 to 7.0 and mediawiki from 1.27 to 1.31)

Have you tried editing the page and doing a preview, to be sure you're not seeing a cached version of the page generated before the change in setlocale?

Is there an extension to automatically change display language(interface, menu, etc.) for non-logged in users, depends on browser's language settings?

Does the way language is selected in Wikimedia Wikis not work for your purposes? See, Universal Language Selector/FAQ and Extension:UniversalLanguageSelector for details.

How to view Sitemaps?

See Manual:GenerateSitemap.php.

What I have: MediaWiki 1.30.0; PHP 7.2.7; SQLite 3.24.0

What I need: MediaWiki 1.31.0; PHP 7.2.7; PostgreSQL 10.4

Should I first migrate the database and then upgrade to MediaWiki 1.31 or upgrade Mediawiki first and then migrate the database?

And what is most important: I couldn't find a how-to for migrating a Mediawiki database from SQLite.

Any hints appreciated.

I don't know, if it is easier or more difficult to switch MediaWiki 1.30 or MediaWiki 1.31 from SQLite to Postgres.

Actually, I would first do, what I know is working - that is: An upgrade from MediaWiki 1.30 to 1.31.

Afterwards I would address the switch of the DBMS.

I don't know of a way to switch from SQLite to Postgres directly. https://www.quora.com/What-is-the-best-way-to-copy-my-SQLite-database-to-PostgreSQL-so-I-can-deploy-it-to-Heroku sounds like there basically is a way to convert your stuff. However, note that at least the "lazy" way will almost certainly lead to problems at some later point. That is what the author calls "lost productivity". This is what will happen.

An idea might also be to set up a new MediaWiki installation and to have MediaWiki create an empty Postgres database. Afterwards you can compare the database structure of what you got after your conversion with what the MediaWiki installer creates. I think comparing these two is what I would do. This will most likely show you some differences,which you need to adjust so that your converted Postgres DB looks as MediaWiki expects it to look like...

Hi, inspecting the header, h1, title of a page it has the following css loading...

h1, h2, h3, h4, h5, h6 {

    color: #000;

    background: none;

    font-weight: normal;

    margin: 0;

    overflow: hidden;

    padding-top: 0.5em;

    padding-bottom: 0.17em;

    border-bottom: 1px solid #a2a9b1;

}

I can't find this css anywhere.

It says it loads in at...

...w/load.php?debug=false&lang=en&modules=mediawiki.legacy.commonPrint%2Cshared%7Cmediawiki.sectionAnchor%7Cmediawiki.skinning.content.externallinks%7Cmediawiki.skinning.interface%7Cskins.madwiki&only=styles&skin=madwiki

But I don't know where to find this to edit it. I do not wish to overide it, but find where it's already stated.

Thanks

You can use the URL parameter "debug=true" to find the exact file.

changing the parameter didn't work at all.

But I found where all the css is hiding. For future reference;

w/resources/src/mediawiki.skinning/

Current: MediaWiki 1.27.4 Upgrade to: MediaWiki 1.31.0

PHP 7.1.17 (fpm-fcgi) MariaDB 10.2.14 URL - localhost (test environment)

Running the maintenance script update.php produces a privilege error:

=

Turning off Content Handler DB fields for this part of upgrade. Adding ipb_id field to table ipblocks ...[06a6bcb5ba7a28f0640c1c8d] [no req] Wikimedia\Rdbms\DBQueryError from line 1457 of /var/www/html/w/includes/libs/rdbms/database/Database.php: A database query error has occurred. Did you forget to run your application's database schema updater after upgrading? Query: ALTER TABLE `mediawiki`.`ipblocks`

ADD ipb_auto tinyint NOT NULL default '0',
ADD ipb_id int NOT NULL auto_increment,
ADD PRIMARY KEY (ipb_id)

Function: Wikimedia\Rdbms\Database::sourceFile( /var/www/html/w/maintenance/archives/patch-ipblocks.sql ) Error: 1142 ALTER command denied to user 'wiki'@'localhost' for table 'ipblocks' (localhost)

Backtrace:

1. 0 /var/www/html/w/includes/libs/rdbms/database/Database.php(1427): Wikimedia\Rdbms\Database->makeQueryException(string, integer, string, string)
2. 1 /var/www/html/w/includes/libs/rdbms/database/Database.php(1200): Wikimedia\Rdbms\Database->reportQueryError(string, integer, string, string, boolean)
3. 2 /var/www/html/w/includes/libs/rdbms/database/Database.php(4194): Wikimedia\Rdbms\Database->query(string, string)
4. 3 /var/www/html/w/includes/libs/rdbms/database/Database.php(4129): Wikimedia\Rdbms\Database->sourceStream(resource (closed), NULL, NULL, string, NULL)
5. 4 /var/www/html/w/includes/installer/DatabaseUpdater.php(683): Wikimedia\Rdbms\Database->sourceFile(string)
6. 5 /var/www/html/w/includes/installer/DatabaseUpdater.php(751): DatabaseUpdater->applyPatch(string, boolean, string)
7. 6 /var/www/html/w/includes/installer/DatabaseUpdater.php(482): DatabaseUpdater->addField(string, string, string)
8. 7 /var/www/html/w/includes/installer/DatabaseUpdater.php(446): DatabaseUpdater->runUpdates(array, boolean)
9. 8 /var/www/html/w/maintenance/update.php(200): DatabaseUpdater->doUpdates(array)
10. 9 /var/www/html/w/maintenance/doMaintenance.php(94): UpdateMediaWiki->execute()
11. 10 /var/www/html/w/maintenance/update.php(245): require_once(string)
12. 11 {main}

==

Running the update script as a database user with administrator privileges produces this error:

Function: Wikimedia\Rdbms\Database::sourceFile( /var/www/html/w/maintenance/archives/patch-ipblocks.sql ) Error: 1146 Table 'mediawiki.ipblocks' doesn't exist (localhost)

(same backtrace)

==

My database user account has "GRANT ALL PRIVILEGES ON `wiki`.* TO 'wiki'@'localhost'".

There are no errors when I run the update script from a version 1.31 clean install.

There are no errors when I run the update script from my current version 1.27.4.

I am blocked upgrading to version 1.31.0.

How can I debug this problem? I do not see any mention of this problem in Phabricator.

This is a problem with MySQL/MariaDB permissions. You are speaking about two different databases!

> ALTER TABLE `mediawiki`.`ipblocks`

> ALTER command denied to user 'wiki'@'localhost' for table 'ipblocks'

> GRANT ALL PRIVILEGES ON `wiki`.* TO 'wiki'@'localhost'

The correct database name obviously is "mediawiki", not "wiki".

Thank you for the reply. I agree, the database name does not match. There is no mention of 'mediawiki' in my LocalSettings.php file; the correct database name is 'wiki'. Therefore, the database name has changed during the script execution.

I was incorrect in my earlier statement of There are no errors when I run the update script from a version 1.31 clean install. The script did indeed run, but that was for a clean (new) database. The conditions which triggered my error did not occur - modification of an existing database.

All maintenance scripts utilize the configurations in LocalSettings.php. Perhaps this is the source of my problem? I replaced my existing LocalSettings.php file with the version created from a clean install. It worked!

I then modified the "clean" LocalSettings.php to align with my existing configuration. Extensions were added to the bottom of the file. (Previously, they were near the top of the file.) I don't know if the extension placement or a configuration setting was source of my problem.

In any case, I have a working configuration and can proceed with my testing.

I had exactly the same error message as @Lady_G2016 indicated when upgrading from MW1.30 to MW1.31. So I asked for help from my University of Colorado colleague at the IT department, Karen. Karen indicated the following:

It almost looks like there is a code error. In most cases, the settings use $wgDBname, which properly points to the mysql database "csdms_wiki" [the dbname of my wiki].   However, in Setup.php, there is a reference to $wgDBmwschema, which, per LocalSettings.php should only be used if you are using postgresql. In LocalSettings.php, $wgDBmwschema points to 'mediawiki'. So maybe try changing the value for $wgDBmwschema in LocalSettings.php from 'mediawiki' to 'csdms_wiki'?

I did that and the update.php script runs smoothly. So could it be that the reference in the Setup.php to $wgDBmwschema shouldn't be there when running the wiki from a mysql database?

Thanks,

Albert.

I had this exact issue as well. I use MySQL. My LocalSettings.php, which was originally generated quite a many versions ago, had this code:

$wgDBmwschema       = 'mediawiki';

I changed it to this, and the problem went away.

$wgDBmwschema       = $wgDBname;

I've updated Manual:$wgDBmwschema to reflect this situation, and mentioned this on MediaWiki 1.31#Configuration changes.