Project:Current issues

Jump to: navigation, search

About this board

This page is for discussing issues related to MediaWiki.org site. To get help with MediaWiki software, ask on Project:Support desk.
Archives 

Current issues archive overview

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
Shirayuki (talkcontribs)

The link "mass delete" on Special:Contributions does not work properly. The parameter "target" is ignored. e.g. https://www.mediawiki.org/w/index.php?title=Special:Nuke&target=Shirayuki

Koavf (talkcontribs)

FuzzyBot is actually a piece of MediaWiki software--it's not an actual user or bot (e.g., if you block it, it can still edit).

Shirayuki (talkcontribs)

It is just one example of users.

Shirayuki (talkcontribs)

Special:Nuke accepts "wpnuke-target" not "target", but Special:Contributions passes "target".

Ciencia Al Poder (talkcontribs)

task T158502, apparently will be fixed during Monday.

Reply to "Special:Nuke"
Yolo33s (talkcontribs)

After installing PdfExport Extension (v3.2.0) for mediawiki 1.27.0, I have the following error message :

Fatal error: Call to undefined method Article::preSaveTransform() in /var/www/wiki/extensions/PdfExport/converters/HtmlDocPdfConverter.php on line 151

This comment was hidden by Seb35 (history)
This comment was hidden by Seb35 (history)
Seb35 (talkcontribs)

@Yolo33s: This extension is hardly maintained since some time. In fact the line you pointed probably didn’t work since MediaWiki 1.18. I just solved a number of issues I experimented when launching this extension with MediaWiki 1.28alpha, PHP 7.0 and Dompdf 0.7 (installed with Composer), whose this issue. Finally it worked with Dompdf – I didn’t tested other backends. When the change I04eda179bab689e29b9f26caf10807f4136afa3f will be merged, it should work, but you will have to install the very last version (it will be available on ).

62.102.229.98 (talkcontribs)

@Seb35: Thanks for support. I first tried to install dompdf 0.7 with composer but as I don't master it I was not sure about what I was doing. The unzipped dompdf folder is in /usr/bin/dompdf. In LocalSettings.php, I added "require_once '/usr/bin/dompdf/autoload.inc.php';" but when I try to print a page, I get an error message saying that no pdf converter software has been found.

Is it good to place the require_once in LocalSettings.php ? I also tried in index.php. More precisions on how to install dompdf would be much appreciated.

Thanks.

Seb35 (talkcontribs)

I tested the following commands (probably you did some of these):

  1. Download Dompdf 0.7 from GitHub
  2. Unzip it in the MediaWiki directory, next to LocalSettings.php, the subdirectory is named "dompdf"
  3. Add require_once __DIR__ . '/dompdf/autoload.inc.php'; in your LocalSettings.php
  4. Download the patched version of PdfExport from my website (when the change above will be merged, it will be available in the "official" version on )
  5. Unzip it as usual in extensions/ (if you had a previous extensions/PdfExport move it to another location or delete it)
  6. It should work

I guess you are under Linux, right? If so, the path /usr/bin is reserved for general commands, but not for librairies (as is Dompdf); I said above to put it in the MediaWiki directory, it is probably a good place; else web applications sometimes have a subdirectory "lib" where are the external librairies (MW doesn’t have this subdirectory, external librairies are in the subdirectory "vendor" managed by Composer -- prepared by the release manager in the case of the tarball).

Manilal (talkcontribs)

@Seb35 installed dompdf using composer and used your patch. But when I click on Print as PDF link it gives me a blank page. Here is my LocalSettings.php:

require_once "$IP/extensions/PdfExport/PdfExport.php";

Seb35 (talkcontribs)

Probably some file is missing, but we need more informations to find what file is missing.

  1. Check in your webserver logs, there is perhaps some PHP messages (/var/log/apache2/error.log or /var/log/nginx/error.log)
  2. Try to enable
    $wgShowExceptionDetails = true;
    
    and retry to display the PDF: is there some explicit error message?
  3. Configure
    $wgDebugLogFile = 'debug.log';
    
    and retry to display the PDF: is there some useful error message in this file?
62.102.229.98 (talkcontribs)

Thank you for the tips @Seb35. I did everything listed above. Now it is installed but when I print an article I get an error message Exception encountered, of type "Dompdf\Exception" without more informations. This is a blank page. I checked that all requirements are OK (Dom extension, GD extension, MBString, php-font-lib, php-svg-lib) and they are, then I restarted apache...

Do you have any idea about this error message. I read some posts about Dompdf Exception but generally the error message is more precise than just "Dompdf\Exception".

For information, I'm on Ubuntu 16.04 with PHP 5.6 and I run a 1.27.0 version of MW.

Regards

Seb35 (talkcontribs)

Great! At least the MW part seems to work. I didn’t have this exception myself – different config: Debian+PHP7, but yours seems to be quite good also. Can you add ini_set( 'display_errors', 1 ); on the top of your LocalSettings.php? It could display a more detailled information about the exception (you will have to remove it in production).

Yolo33s (talkcontribs)

Yes I also thought to display errors but unfortunately it is not more verbose...Only a strict standard warning unrelated to PdfExport or Dompdf. I wonder if an installation with composer would be safer but I do not feel comfortable with that.

Seb35 (talkcontribs)

If you feel comfortable with command line (quick guide: directories are separated by a slash "/", the main commands are "cd the-directory-you-want-go-to" and "ls" to display the content of the directory), you can install Composer inside the main MediaWiki directory (instructions), then add Dompdf as dependency by creating the file composer.local.json in MediaWiki directory (next to LocalSettings.php) with the content:

{
   "require": {
      "dompdf/dompdf": "*"
   }
}

and executing (in command line in MediaWiki directory) "composer update --no-dev". If you install it with Composer, remove the require_once from LocalSettings.php (else it could be installed two times). There is a guide for Composer on Composer/For extensions. Thanks for your perseverance!

62.102.229.98 (talkcontribs)

And thank you very much for your help @Seb35, I really need to make this extension work. When running "composer update --no-dev" it seems that this is mbstring and gd extension the problem. It is missing. What I don't understand is that I'm using php 5.6 and it requires mbstring and gd extension for php7...Strange. Anyway, it is installed but I still have the same exact error message. Note that in my mediawiki installation folder, the .json file is named composer.json and not composer.local.json. But if dompdf had not been installed, I would have had another error message.

Ma persévérance atteint ses limites.

Seb35 (talkcontribs)

Don’t you have some sysadmin or a geeky person near you? It becomes difficult to follow remotely. For Composer I guess there are dependency issues, probably because some dependencies require PHP7, so probably a bad idea to try in this direction, stay with your downloaded version 0.7 of dompdf. And it is absolutely required for PdfExport, so you (or anybody who could help you) have to make Dompdf work to make PdfExport work. Perhaps add also ini_set('error_reporting', E_ALL); in your LocalSettings.php.

If it cannot work, I tried to install Extension:Collection but, as I was afraid of, it is horribly difficult to install. And an external solution but functionning without any burden for the MW admin is to use the link 'Printable version' in the sidebar section Tools, then use the Print feature of the browser and select 'Print in file'. Depending on the browser, it will save in a Postscript file and/or PDF file. With this way to export PDF, the result can be different from a brower to another (e.g. I was surprised of a document where the font size was about the double between Firefox and Chrome -- it was quite small with Chrome and quite big with Firefox).

62.102.229.98 (talkcontribs)

Yes I already tried collection, and I already add ini_set('error_reporting', E_ALL); in LocalSettings.php. I think dompdf is installed because wether I install it through composer or simple folder, I had the same error message at the end. I will wait for the return of a sysadmin to debug this issue. Anyway thanks a lot for support.

62.102.229.98 (talkcontribs)

@Seb35 I did it ! I found on the general support someone with a completely different problem who needed to run the "jobs". After a php maintenance/runJobs.php, I could print articles to pdf.

I'm still convinced that the mediawiki documentation needs drastic improvements.

Seb35 (talkcontribs)

Ok, I didn’t know it could have an influence, but it’s great! Happy the problem was solved! (and aggree about documentation, it’s a lot of work, you’re welcome if you want to add something, but this thread will probably help other people also :)

Edrimon (talkcontribs)

Hi, Thank you for your valuable information. I installed as instructed in this document, but I get the following output for Greek in my wiki in UTF-8.

Any ideas? its common UTF-8 , should n't it work?

Scroom (talkcontribs)

@Seb35 I get the following error If I try to produce a PDF out of a wiki article:

Exception encountered, of type "Dompdf\Exception" [1ba58343a430deff683c3f41] /wiki/index.php?title=Spezial:PDF-Druck&page=Kollegium Dompdf\Exception from line 704 of /var/www/html/wiki/dompdf/src/Css/Stylesheet.php: Invalid CSS selector syntax: missing attribute name Backtrace:

  1. 0 /var/www/html/wiki/dompdf/src/Css/Stylesheet.php(879): Dompdf\Css\Stylesheet->_css_selector_to_xpath(string)
  2. 1 /var/www/html/wiki/dompdf/src/Dompdf.php(732): Dompdf\Css\Stylesheet->apply_styles(Dompdf\Frame\FrameTree)
  3. 2 /var/www/html/wiki/extensions/PdfExport/converters/DomPdfConverter.php(102): Dompdf\Dompdf->render()
  4. 3 /var/www/html/wiki/extensions/PdfExport/PdfExport_body.php(111): DomPdfConverter->outputPdf(array, array)
  5. 4 /var/www/html/wiki/includes/specialpage/SpecialPage.php(479): SpecialPdf->execute(NULL)
  6. 5 /var/www/html/wiki/includes/specialpage/SpecialPageFactory.php(576): SpecialPage->run(NULL)
  7. 6 /var/www/html/wiki/includes/MediaWiki.php(282): SpecialPageFactory::executePath(Title, RequestContext)
  8. 7 /var/www/html/wiki/includes/MediaWiki.php(745): MediaWiki->performRequest()
  9. 8 /var/www/html/wiki/includes/MediaWiki.php(519): MediaWiki->main()
  10. 9 /var/www/html/wiki/index.php(43): MediaWiki->run()
  11. 10 {main}

Do you maybe have an idea what to do?

Reply to "PdfExport does not work on 1.27.0"
Plagiat (talkcontribs)

moved to meta OTRS

Shirayuki (talkcontribs)

Extension:Math/Inputtypes shows an error message:

Failed to parse (MathML with SVG or PNG fallback (recommended for modern browsers and accessibility tools): Invalid response ("Math extension cannot connect to Restbase.") from server "/mathoid/local/v1/":): {\displaystyle d/dxf(x)=lim_{h->0}(f(x+h)-f(x))/h}
MarkAHershberger (talkcontribs)

See Fresh Mediawiki + Math install gives Restbase URL error.

Reply to "Math extension error"

User can't submit anything (even preview isn't working)

1
Summary by Nrm

This seem to be a problem with my computer. When login with another machine, it works like a charm. Sorry for the polluted topic.

Nrm (talkcontribs)

Hi everyone,

I'm using mediawiki 1.27.1 with php 5.5.21 and 5.5.52-MariaDB, and WikiEditor 0.5.0. I'm using chromium 55.0.2883.87 and Firefox 50.1.0.

Friday I wanted to personnalise my wikiEditor toolbar, so I changed '$wgAllowUserJs' to true in order to allow 'user/common.js' to be working. I put my code into that page, and tried many modifications. At some time, when I wanted to push an image to a button, the wiki didn't allow me to do that with an '400 bad request' error code.

Since then, It's impossible for me to submit anything. If I try to preview a page with 'preview' button that do a POST submit request, I've got the '400 bad request' error.

I deleted my common.js page, disabled '$wgAllowUserJs' variable, check my logs (nothing in there), activated debug mode (nothing there too), tried with Firefox (the error is 'secure connection failed' on this one).

I also tried to lurk in database to see if something went wrong, but I don't know where to look.

I tried with burp to see the request, it doesn't seem to have any issue. My httpd reverse proxy don't print logs in '/var/log/httpd/access.log' for the 'submit' request (no problem for other requests), but log the 408 error reply.

Another interesting thing is that I'm the only user affected by this bug, other users have not this problem..

Does anyone have an idea about to solve my problem or anything to get more logs on this ?

Thank you very much

IExit (talkcontribs)

Dear Ladies and Gentlemen,

as I got the problem that watching and unwatching a topic isn't working anymore, I wanted to ask you, if you got a solution. "action=tokens has been deprecated. Please use action=query&meta=tokens instead."

I dont get where to edit the URLs in the action menu, so you may tell me where I can do this.

Best Regards,

MarkAHershberger (talkcontribs)

I just watched this topic without problem. Could you give more details about your problem?

Wargo (talkcontribs)

Do you use watching tab in interface or you have gadget/own application? What wiki?

Reply to "Watching / Unwatching not working"
Summary by Ciencia Al Poder
Shirayuki (talkcontribs)
Ciencia Al Poder (talkcontribs)

qqx displays (duration-decades: 4)(comma-separator)(duration-years: 7)(comma-separator)(duration-days: 26)(comma-separator)(duration-hours: 18)(comma-separator)(duration-minutes: 14)(and)(word-separator)(duration-seconds: 43)

AttemptToCallNil (talkcontribs)

API:

{
    "batchcomplete": "",
    "query": {
        "blocks": [
            {
                "id": 74115,
                "user": "223.24.7.206",
                "by": "Mainframe98",
                "timestamp": "2017-01-25T20:47:07Z",
                "expiry": "2017-01-27T03:47:07Z",
                "reason": "Inserting false or outdated translations",
                "anononly": "",
                "nocreate": "",
                "allowusertalk": ""
            }
        ]
    }
}

Which is 31 hours. It's likely the correct one. Also if you subtract the wrong result from the expiry date, you get something close to 1970-01-01.

MarkAHershberger (talkcontribs)

Isn't this something that should be fixed in the i18n messages?

Ciencia Al Poder (talkcontribs)

I doubt it has to do with i18n message since qqx lang code displays 4 decades which is blatantly incorrect.

Speravir (talkcontribs)

Does the group of translation administrators exist here? If yes, how to get in contact with them? If not, which people are able to fix mistakes like described Help talk:CirrusSearch#First sentence?

Koavf (talkcontribs)

You can find them here: https://www.mediawiki.org/w/index.php?title=Special:ListUsers&group=translationadmin

Speravir (talkcontribs)

Thank you. So, there is no project page here?

Koavf (talkcontribs)

There is just Project:Administrators

Wargo (talkcontribs)

And Project:Translation

Reply to "Translation administrators"

Using watchlist notice for Code of Conduct calls for feedback

16
Qgil-WMF (talkcontribs)

At Talk:Code_of_Conduct/Draft#Wider_participation.2C_still there is a discussion about how to announce calls for feedback about the proposed Code of Conduct for technical spaces to mediawiki.org contributors. The idea of a watchlist notice has been suggested. As far as I am aware, we haven't used this feature in mw.o before. I guess this is a good place to ask for feedback about using this feature for this purpose.

Technically, this seems to be done by editing MediaWiki:Watchlist-details. Questions:

  • Is this use of watchlist notice OK or not?
  • Should we do it by editing MediaWiki:Watchlist-details or is there another way?
  • Should we use plain text with links or i.e. a Template:Notice?
  • How often and how long should these notices be kept, i.e. One week every time that there is a major call for feedback or more often?
Jdforrester (WMF) (talkcontribs)

Personally, I really dislike the abuse of that part of the interface for important messages, but I understand that some wikis think it's OK. We've never done it here, and I'd be sad to see it start.

More objectively, however, I also think it would be a waste of time for this wiki; very few people are active on MediaWiki.org in the way that editors of other wikis are, because a lot of the "action" occurs off-wiki, in tasks (Phabricator), in code (gerrit/GitHub/etc.), or for third party users of MediaWiki in particular, on their local systems, and so the use of the watchlist as the key place people see is not likely to work. The people who use their watchlists on this wiki (like me) are mostly wiki gnomes rather than the key people to involve. A logged-in-only sitenotice would probably have a much better effect at reaching the useful people for this work.

Mattflaschen-WMF (talkcontribs)

I have no objection to using a watchlist notice, though I agree with James a lot of contributors don't use the wiki that often, and probably use the watchlist even less. I also think the site notice is a good idea, but we probably want to limit it to text approvals (rather than "please help discuss this"). We don't want to be too intrusive, and the site notice appears on every page.

Ciencia Al Poder (talkcontribs)

I personally find CentralNotice banners way more obtrusive than a one-line text on the sitenotice. CentralNotice banners appear for me several days on a week, with images, even if I dismiss them, while the sitenotice can be dismissed once and forever (until someone updates the sitenotice ID)

Qgil-WMF (talkcontribs)

I propose to try something, be ready to pull back if there are justified complaints, and then fine tune next actions based on feedback.

A logged-in-only sitenotice looks like a good candidate for a first try, indeed. How is that requested and implemented? I propose to figure out these details and prepare a sitenotice for the approval of the Cases page, expected to start in a couple of weeks, after the call for feedback started yesterday by Matt has settled and remaining issues have been identified.

Mattflaschen-WMF (talkcontribs)

It may be just one week before starting the approval discussion, depending on how much feedback on Cases there is.

Mattflaschen-WMF (talkcontribs)

I agree a simple dismissable text sentence is fine. No need for an image.

The documentation is at Manual:Interface/Sitenotice , but I'm not entirely clear from that how it interacts with CentralNotice. Someone from Fundraising Tech probably knows.

@AGreen (WMF), how would we configure it if we want a dismissable text notice here and on wikitech.wikimedia.org?

Mattflaschen-WMF (talkcontribs)

Talked to @Awight (WMF) and @AGreen (WMF)

Looks like CentralNotice is the best option here. It doesn't yet support wikitech.wikimedia.org (phab:T147036), but I don't think that's a deal-breaker. I would guess most users of wikitech.wikimedia.org will either see it on MediaWiki.org or have heard about it already.

That will allow a banner that is:

  • text (CentralNotice supports HTML, but a text-only HTML banner is not a problem)
  • Logged-in only (just don't check "Anonymous users")
  • Dismissable (need to add the "Close button" explicitly when drafting the banner, but then it will just work).

Awight said the SiteNotice would probably be problematic for caching. This looks to be the case. Not only does it show to anons (which we don't want), it will be cached for 30 days.

Qgil-WMF (talkcontribs)

+1

This comment was hidden by Ciencia Al Poder (history)
Mattflaschen-WMF (talkcontribs)

@Seddon (WMF) @Qgil-WMF @AGreen (WMF) @Awight (WMF) Do you know who we can work with on this? I don't think I have the permissions to create a banner.

I saw meta:CentralNotice/Request , but it says it needs to be "10 days in advance of any campaign". We will have to update it frequently, and I would prefer not to have a 10-day lead time each time.

AGreen (WMF) (talkcontribs)

Sorry for the delay in replying!! Is it too late, or is this already solved? I think the 10-day lead time only refers to programming the campaign, not updating banners. Also, I suspect it's probably not that strict. :)

Qgil-WMF (talkcontribs)

(I don't know)

Mattflaschen-WMF (talkcontribs)

This is in-progress. Thanks to the people who've helped, among others @JSutherland (WMF).

Qgil-WMF (talkcontribs)

I actually saw the banner in Meta as well. Bug or feature? I actually think it cannot harm (really).

Mattflaschen-WMF (talkcontribs)

It was originally proposed as MediaWiki.org, we looked into MW.org + wikitech, there were technical difficulties with wikitech, so we ended up back at MW.org with no objections.

That's still the most appropriate audience.

Reply to "Using watchlist notice for Code of Conduct calls for feedback"

How and where to store wikitool descriptions

1
Alexmar983 (talkcontribs)

Hi. I hope I am posting in the right place. Please take a look in m:Wikimedia_Forum#Tools_descriptions._Is_there_a_right_place_to_store_them.3F if this topic is of any interest.

Reply to "How and where to store wikitool descriptions"