Project:Current issues

Jump to: navigation, search

About this board

Edit description
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

No editing on both 19 April and 3 May from 14:00 to 14:30 UTC

2
Whatamidoing (WMF) (talkcontribs)

Ops is doing a failover test between the primary and secondary data centers. You will be able to read, but not edit, during a critical point in the work. It should last about 20 to 30 minutes on these two dates:

More information (including a link to the official schedule) is at https://meta.wikimedia.org/wiki/Tech/Server_switch_2017

(User:SGrabarczuk (WMF), is this on your calendar yet?)

Whatamidoing (WMF) (talkcontribs)

Two more things for this particular audience:

  • If you discover unexpected problems (for example, if you can't read pages for more than a moment or two), then you will probably want to report unexpected problems in #wikimedia-tech Last year, #wikimedia-operations was moderated until the wikis were online again.
  • There will be code freezes during both of those weeks. I encourage you all to be thoughtful about what you choose to deploy during the week immediately the code freezes, too.
Reply to "No editing on both 19 April and 3 May from 14:00 to 14:30 UTC"
Trizek (WMF) (talkcontribs)

Hello

The Wikimedia Foundation Collaboration team is ready to release a set of new filters for Recent changes.

These filters will be available as a beta feature by the end of the month on Portuguese and Polish Wikipedias. We plan to roll-out this new feature progressively, still as a Beta feature.

The new filters will include user intent prediction filtering on wikis where ORES is enabled. They will also include result highlighting, to help recent change reviewers.

We also want to setup the new filters on Mediawikiwiki very soon.

If you have any question or feedback, the discussion page is open!

Trizek (WMF) (talkcontribs)

We plan to deploy the new filters on Tuesday March 28, at 13:00 UTC.

Trizek (WMF) (talkcontribs)

The new filters are now available in your Beta preferences. Try them, and please provide feedback!

Reply to "New filters for edit review"
SGrabarczuk (WMF) (talkcontribs)

I'd like to invite you to participate in the Wikimedia Movement Strategy discussions, about our wider movement's overall goals, "What do we want to build or achieve together over the next 15 years?".

It's currently in the first stage, of broad discussion. There are further details in the related metawiki pages (incl. FAQ, calendar and process, list of other simultaneous communities' discussions, etc). (Also, if you're interested in helping facilitate and summarize the discussions here, and to bring back here the summaries of what the other communities are discussing, in the weeks ahead, please let me know.) Thanks.

Reply to "Wikimedia Strategy 2017"
Elitre (WMF) (talkcontribs)

Is anybody familiar with rate of created accounts on this wiki? A concerned editor showed up in my talk page.

MarkAHershberger (talkcontribs)

The account creation at Special:Log does look odd. I thought these were automatically duplicated in CentralAuth. I'm going to see if someone on IRC can look.

MarkAHershberger (talkcontribs)

<hexmode> who do I ask to look at the account creation rate here https://www.mediawiki.org/wiki/Special:Log? quiddity? ragesoss?

<quiddity> looking...  [11:58]

<Reedy> hexmode: https://grafana.wikimedia.org/dashboard/db/authentications

<Reedy> https://grafana.wikimedia.org/dashboard/db/authentications?from=now-30d&to=now

<hexmode> Reedy: quiddity: prompted by https://www.mediawiki.org/wiki/Topic:Tn4q0l4fzgoe63o8  [12:01]

<Reedy> At least at a graphing level, it doesn't look out of the ordinary

<hexmode> ok

<ragesoss> looks like all those accounts are the same ones recently being created on meta.

<Reedy> Yeah

<ragesoss> do you now automatically get a mediawiki account when you create a new SUL?

<Reedy> CA will propogate it

<ragesoss> or was that always the case?

<Reedy> I dunno if it's delayed via job queue

<Reedy> Not always the case, but it's been like that quite a while now  [12:02]

<Reedy> Since SUL finalisation stuff

<hexmode> Is it ok if I copy-paste this on the thread?

<Reedy> Sure

<Reedy> https://grafana.wikimedia.org/dashboard/db/authentications?from=now-6h&to=now

Brynda1231 (talkcontribs)

And some of those usernames are spam or profane and should be blocked.

MarkAHershberger (talkcontribs)

@Brynda1231, if you see a username that should be blocked, it is going onto all the wikis (here is enwiki, for example). I think you would need to file a task in phabricator for it.

Brynda1231 (talkcontribs)

K, I'll try...

Reply to "Creation of new accounts?"

Search function does not work (the way we expected it)

2
87.123.228.236 (talkcontribs)

Hi,

we built a documentary were contents are included in tables. However if we search for these contents with the search function they cannot be found.  :-(

Is it a known error? Or is it dependent on the way MediaWiki is written?

THX in advance for your answer.  :-)

Klaus

Ciencia Al Poder (talkcontribs)

Maybe the search index hasn't been updated. You can try running Manual:rebuildtextindex.php. You can also consider installing Extension:CirrusSearch to improve the search.

Reply to "Search function does not work (the way we expected it)"
Shirayuki (talkcontribs)

WMDE Engineering says:

Failed to load RSS feed from https://sourcecode.berlin/feed/: Error fetching URL: SSL certificate problem: certificate has expired
Ciencia Al Poder (talkcontribs)

using http doesn't give those problems: http://sourcecode.berlin/feed/

So simply switch to HTTP? or remove that feed, which I don't know if it's relevant.

Shirayuki (talkcontribs)

http://sourcecode.berlin/feed/ is not in the URL whitelist of RSS feeds.

Reply to "Failed to load RSS"
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.

Elitre (WMF) (talkcontribs)

For Template_talk:Tracked#Can_this_be_tweaked.3F. Thanks!

Reply to "Looking for a code wizard"
Nemo bis (talkcontribs)

Manual:Installation guide has one section with a 400 words summary, but then links to a "Main installation guide" composed of 4+4 more pages. None of these pages is translatable. Can we consolidate truly important information and make it translatable? Currently one is supposed to find the following logical steps.

  1. Download
  2. Requirements
  3. The actual installation
  4. Misc troubleshooting and alternatives if something went wrong
  5. Configuration
  6. Maintenance
  7. Informative material

The pages in bold are part of the official Template:InstallationNav (which complements Template:MediaWiki Introduction): they are supposed to be the official path and need special care and coordination.

Nemo bis (talkcontribs)

Given Chad's comment, I'm also going to tag all "platform-specific" manual pages for merge to the main ones. Common parts can be merged and transcluded on the specific pages, while really platform-specific additional information can be left there. P.s.: for a start, I removed 5 guides on obsoleted systems and marked the others for merge.

Nemo bis (talkcontribs)

I made Manual:LocalSettings.php translatable and expanded Manual:System administration by merging Manual:Configuration.

  • Manual:System administration could be useful if it becomes a reasonable index/step by step guide/tutoring of the really important pages in Category:MediaWiki for site admins (allowing to remove respective information from the general installation manual), but I'm not sure of its current role.
  • Manual:LocalSettings.php is very visited, but it's quite a mess. I doubt it kept anywhere close up to date, is it currently making a good service to users?
Ciencia Al Poder (talkcontribs)

I wonder what's the purpose of making Manual:LocalSettings.php translatable if you doubt about the usefulness of that page or if you plan/propose to improve/restructure it.

Nemo bis (talkcontribs)

The page is vastly correct and the strings contained in it look rather stable, so it's ok to translate it. It is my impression that some consolidation will be needed for that page (reducing total amount of text around), but not a rewriting.

Nemo bis (talkcontribs)

I've tried to make the essential stuff transcludable, and I've trimmed some more pages.

IMHO the direction is rather clear:

  • always defer to other sites for guides on how to set up PHP etc.;
  • keep all the steps internal to MediaWiki (like installer, config script, LocalSettings.php) in their own, shared manual pages;
  • in all the setup-specific pages, just transclude the former and maintain only:
    • information on packages available and how to use them (debatable, should be on their sites whenever possibles),
    • OS-specific instructions which can't be found anywhere else, like specific paths to put in MediaWiki config or RAM/suhosin requirements and the like.
Reply to "Installation guide consolidation"
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?
Manilal (talkcontribs)

@Seb35 I'm sorry for the delayed response, I didn't notice your reply.

I enabled both the above configs and got a bunch of messages in debug.log. I think the following is related to DomPdf.

[exception] [WLPQoUWN-nHgCzghCAxhXAAAABg] /mediawiki/index.php?title=Special:Pdfprint&page=Downloads   Dompdf\Exception from line 704 of /home/www/html/mediawiki/vendor/dompdf/dompdf/src/Css/Stylesheet.php: Invalid CSS selector syntax: missing attribute name

#0 /home/www/html/mediawiki/vendor/dompdf/dompdf/src/Css/Stylesheet.php(879): Dompdf\Css\Stylesheet->_css_selector_to_xpath(string)

#1 /home/www/html/mediawiki/vendor/dompdf/dompdf/src/Dompdf.php(732): Dompdf\Css\Stylesheet->apply_styles(Dompdf\Frame\FrameTree)

#2 /home/www/html/mediawiki/extensions/PdfExport/converters/DomPdfConverter.php(102): Dompdf\Dompdf->render()

#3 /home/www/html/mediawiki/extensions/PdfExport/PdfExport_body.php(111): DomPdfConverter->outputPdf(array, array)

#4 /home/www/html/mediawiki/includes/specialpage/SpecialPage.php(522): SpecialPdf->execute(NULL)

#5 /home/www/html/mediawiki/includes/specialpage/SpecialPageFactory.php(576): SpecialPage->run(NULL)

#6 /home/www/html/mediawiki/includes/MediaWiki.php(283): SpecialPageFactory::executePath(Title, RequestContext)

#7 /home/www/html/mediawiki/includes/MediaWiki.php(851): MediaWiki->performRequest()

#8 /home/www/html/mediawiki/includes/MediaWiki.php(512): MediaWiki->main()

#9 /home/www/html/mediawiki/index.php(43): MediaWiki->run()

#10 {main}

Please let me know if you can interpret anything from this messages. I have enabled selinux in this server (CentOS-7 with Apache Httpd), but couldn't find anything related to httpd in audit.log.

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"