Project:Current issues

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

Text is available under the Creative Commons Attribution-ShareAlike License; additional terms may apply. See Terms of Use for details.

Start a new topic

Using watchlist notice for Code of Conduct calls for feedback

10 comments • 20:00, 17 October 2016 15 hours ago

10

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?

Reply 09:02, 2 June 2016 4 months ago

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.

Reply 15:57, 2 June 2016 4 months ago

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.

Reply 14:17, 14 June 2016 4 months ago

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)

Reply 01:55, 15 June 2016 4 months ago

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.

Reply 07:13, 15 June 2016 4 months ago

Mattflaschen-WMF (talkcontribs)

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

Reply 19:28, 15 June 2016 4 months ago

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?

Reply 19:26, 15 June 2016 4 months ago

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.

Reply 22:58, 29 September 2016 18 days ago

Qgil-WMF (talkcontribs)

+1

Reply 12:16, 30 September 2016 17 days ago

This comment was hidden by Ciencia Al Poder (history)

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

PdfExport does not work on 1.27.0

16 comments • 19:47, 4 October 2016 13 days ago

16

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

Reply 09:25, 13 July 2016 3 months ago

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 ).

Reply Edited 16:16, 24 July 2016 2 months ago

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.

Reply 09:37, 26 July 2016 2 months ago

Seb35 (talkcontribs)

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

Download Dompdf 0.7 from GitHub
Unzip it in the MediaWiki directory, next to LocalSettings.php, the subdirectory is named "dompdf"
Add require_once __DIR__ . '/dompdf/autoload.inc.php'; in your LocalSettings.php
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 )
Unzip it as usual in extensions/ (if you had a previous extensions/PdfExport move it to another location or delete it)
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).

Reply 15:31, 26 July 2016 2 months ago

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

Reply 08:14, 27 July 2016 2 months ago

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).

Reply Edited 08:39, 27 July 2016 2 months ago

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.

Reply 08:51, 27 July 2016 2 months ago

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!

Reply Edited 12:22, 27 July 2016 2 months ago

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.

Reply 14:09, 27 July 2016 2 months ago

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).

Reply 17:34, 27 July 2016 2 months ago

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.

Reply 07:39, 28 July 2016 2 months ago

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.

Reply 08:04, 28 July 2016 2 months ago

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 :)

Reply 20:47, 28 July 2016 2 months ago

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?

Reply 19:47, 4 October 2016 13 days ago

Reply to "PdfExport does not work on 1.27.0"

Phantom notifications coming from MediaWiki.org

2 comments • 17:06, 28 September 2016 19 days ago

2

Koavf (talkcontribs)

I watch Project:Current issues and when a spam subject gets deleted, my Special:Notifications page across all WMF projects has a little "1" for days and days. No matter how many times I mark them as read across all 850 projects, it still shows up for a week until it magically disappears. Can anyone tell me how to get rid of this? Is there by chance a Phabricator ticket related to it? ~~~~

Reply 20:13, 21 September 2016 26 days ago

Krenair (talkcontribs)

I think I also have this.

Reply 20:14, 21 September 2016 26 days ago

Reply to "Phantom notifications coming from MediaWiki.org"

Translate extension

17 comments • 08:29, 21 September 2016 27 days ago

17

Nemo bis (talkcontribs)

We've been using the translate extension for a while now on this wiki, which definitely needs more multilingual support, so I think we should greatly expand its usage, by deciding where to start. The aim is to reach more MediaWiki users (rather than developers); benefits have to be balanced by costs, and in some areas the extension is easier to use than in others (or even easier than continuing with {{Languages}} and so on). Some ideas:

Most viewed pages: I've done some, but they often need an update/revamp in English too.
Configuration variables: hundreds of them have the corresponding Manual: page translated and can be assumed of interest. The pages use a common pattern and most important info is in the template, so – in principle – translations can be moved to the new system (semi)automatically.
Help pages would be the most useful in theory, but those we have here are very specific and limited. It makes no sense to translate most of them, because the "real help pages" and their translations are in fact on Meta or scattered among Wikipedias (or other Wikimedia projects.

Reply 09:23, 21 October 2012 3 years ago

Leucosticte (talkcontribs)

About #3: What about the users of non-WMF wikis? Wouldn't translated help pages be helpful for them?

Reply Edited 13:31, 21 October 2012 3 years ago

Nemo bis (talkcontribs)

Yes but one should first move the up-to-date and complete English pages here from Meta and other wikis (finding a solution for licensing problems and also convincing them not to keep outdated copies around), which is not going to happen.

Reply 14:01, 21 October 2012 3 years ago

Leucosticte (talkcontribs)

You may be right. I think it was a mistake to insist on public domain Help pages, and that we are reaping the harmful consequences of that decision. But to fix it would require acknowledging that a mistake was made, and sometimes people are resistant to that.

Reply 16:53, 21 October 2012 3 years ago

HappyDog (talkcontribs)

I disagree - PD help pages are a very good idea. However, it is a mistake to think they will be of any real use until we provide a workable method of distibuting them. I think it is a fairly safe assumption that if there was an easy way to import the default help pages into your local wiki, in the appropriate language(s), then that would be sufficient encouragement for the current pages to be tidied up (if, indeed, that is necessary - I haven't looked at them for a while) and, more importantly, widely translated.

I don't think think the solution here is to import existing non-English help content from elsewhere, or to try and encourage a translation drive for the help content, without having an export process in place.

Reply 18:22, 21 October 2012 3 years ago

Nemo bis (talkcontribs)

Seems we can all agree on this, so we're left with #1 and #2 for now.

Reply 08:26, 22 October 2012 3 years ago

Nemo bis (talkcontribs)

So... no interest/ideas/suggestions on those two points (priority pages and manual pages)?

Reply 09:58, 19 November 2012 3 years ago

Leucosticte (talkcontribs)

I'm afraid translation isn't my area of expertise. It's been noted that "English is the working language of the Internet", though, and my attitude toward those who seek to administer websites tends to be, learn English or GTFO. But you seem to be on the right track as far as prioritization is concerned; focus on the most-viewed pages first.

Reply 07:41, 20 November 2012 3 years ago

Nemo bis (talkcontribs)

Configuration settings summaries have over 23 thousands translations for the Configure extension; it would be nice to find a way to use them on wiki. I've opened bugzilla:43380 to see what's technically feasible.

Reply Edited 18:21, 1 January 2013 3 years ago

Qgil-WMF (talkcontribs)

I'm not familiar with the Translate extension, although I'm looking for an excuse to finally give it a try. :) Is it possible to promote a set of pages where translation is prioritized? Using a category, for instance.

Trying to translate the whole mediawiki.org is pointless and actually counterproductive, but there is a bunch of pages that would really welcome more translations, and a formal request to be translated. It would be useful for the project and for translator to identify those, and if possible get those nice stats telling that Japanese is 100% up to date, Italian is 83%, Arabic is 12% and so on.

There are two types of translatable pages based on motivation:

Promotion: local languages are good to reach out to new users and contributors. Homepage, the hubs, How to contribute, the local Groups (mainly in their respective native languages)...
Support: essential pages for users of MediaWiki and our technical infrastructure. The most basic and required pages of the manual, how bugzilla works how to get developer access...

Maybe it's worth having both translatable categories separate? Maybe some languages make total sense for Promotion but less so for Support (no specific examples, although I can imagine Indic or Latin languages speakers needing those translations more for Promotion than Support, since the average sysadmin / developer of those languages is used to deal with English documentation).

It is clear that the deeper you get into both categories the clearer is the need to manage some English, at least in our current reality. We could probably define a VERY LIMITED set of pages translatable here and now in both categories and then consider the addition of new pages based on actual need.

And I agree with Nemo that those pages need a review in the canonical English version before making big calls for translation. But maybe this is a feature? It forces us to go through identified pages, mark them as translatable progressively and giving more time to translators to deal with new content. For instance, we could start focusing in How to contribute and Help:Formatting, and do a first test with these pages.

This post was posted by Qgil-WMF, but signed as Qgil.

Reply Edited by Flow talk page manager 07:14, 10 July 2015 1 year ago

Nemo bis (talkcontribs)

Yes, it's possible to "categorize" requests for translations, see for instance m:Special:AggregateGroups. It's also possible to define priority languages and even to disable translations in some languages, but this makes little sense on this wiki. In general, people will always translate what they're interested in, not what you'd most like to have translated, therefore if something would use translations it should be translatable, while for focused translation recruitement you can have a specific priority group of translatable pages.

In short, I don't like that "very limited" in all caps, unless you consider (like me) that e.g. 600 configuration settings pages (out of ten thousands content pages) would be a "very limited" set of translatable pages. ;-) Specific pages ready for translation should made translatable immediately: I'll comment on those two on talk.

Reply 17:49, 24 December 2012 3 years ago

Qgil-WMF (talkcontribs)

Ok, got your point. I just find useful to have a set of pages identified for volunteer translators without own itch or agenda. "I want to start translating MediaWiki content to Catalan: where should I start? Thank you."

This post was posted by Qgil-WMF, but signed as Qgil.

Reply Edited by Flow talk page manager 07:14, 10 July 2015 1 year ago

Nemo bis (talkcontribs)

I've created a high priority group now.

Reply 18:46, 24 December 2012 3 years ago

Nemo bis (talkcontribs)

http://stats.grok.se/www.w/top was updated; the Help: and Manual: pages in the top-1000 list should probably be made translatable. Who's willing to help me?

Reply 08:38, 24 May 2013 3 years ago

Qgil-WMF (talkcontribs)

Thank you for this useful link!

This post was posted by Qgil-WMF, but signed as Qgil.

Reply Edited by Flow talk page manager 07:14, 10 July 2015 1 year ago

This comment was hidden by Elitre (WMF) (history)

Vetonhaxhi (talkcontribs)

DJVU files not displaying after upload ?

Reply 08:29, 21 September 2016 27 days ago

Reply to "Translate extension"

Are you into home page design?

One comment • 09:44, 19 September 2016 29 days ago

1

Summary by Elitre (WMF)

Asked on the wrong page.

Elitre (WMF) (talkcontribs)

If so, Sanskrit Wikipedia is looking for help!

15:30, 15 September 2016 1 month ago

Mediawiki:Lang

2 comments • 21:01, 14 September 2016 1 month ago

2

Wargo (talkcontribs)

Mediawiki:Lang needs be included in $wgForceUIMsgAsContentMsg here, because currently does not work as expected.

Reply 13:48, 14 September 2016 1 month ago

Legoktm (talkcontribs)

Are you sure? No other Wikimedia wiki has it set.

Reply 21:01, 14 September 2016 1 month ago

Reply to "Mediawiki:Lang"

Please take part in the Flow satisfaction survey

One comment • 06:22, 14 September 2016 1 month ago

1

Trizek (WMF) (talkcontribs)

(That message in other languages: العربية • ‎bosanski • ‎català • ‎Deutsch • ‎Esperanto • ‎français • ‎עברית • ‎polski • ‎português • ‎português do Brasil • ‎русский • ‎اردو • ‎中文 – ‎translate that message)

Hello!

An increasing number of communities now use Flow (like Mediawiki.org) or are considering it. Although Flow itself is not scheduled for major development during 2016 fiscal year, the Collaboration Team remains interested in the project and in providing an improved system for structured discussions.You can help us make decisions about the way forward in this area by sharing your thoughts about Flow — what works, doesn't work or should be improved?

Please fill out this survey, which is administered by a third-party service. It will not require an email or your username. See our privacy statement.

Thanks for your ideas and opinions about Flow!

Reply 06:22, 14 September 2016 1 month ago

Reply to "Please take part in the Flow satisfaction survey"

My wiki is gone!

4 comments • 10:28, 10 September 2016 1 month ago

4

Lnatho (talkcontribs)

When I logged in yesterday all pages are blank and "Deprecated: preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead" appears across the top

15:26, 2 September 2016 1 month ago

Ciencia Al Poder (talkcontribs)

Please post support questions in the Project:Support desk! You're probably using an outdated MediaWiki version and your host has updated PHP. It's time to upgrade your MediaWiki installation.

Edited 17:20, 2 September 2016 1 month ago

2601:601:901:283F:6894:E39C:47F5:E4C6 (talkcontribs)

When I updated my wikis I can no longer access them and instead get the warning message Fatal error: Call to undefined method Title::userIsWatching() in /home/rober125/public_html/wiki3/skins/Foundation/foundation.skin.php on line 121

03:22, 10 September 2016 1 month ago

Ciencia Al Poder (talkcontribs)

What part of the phrase Please post support questions in the Project:Support desk! you don't understand? Also, create a new topic instead of replying to a random one!.

I'm closing it so people stop posting new questions here.

10:28, 10 September 2016 1 month ago

sidebar dependes on usergroup

6 comments • 20:28, 31 August 2016 1 month ago

6

Paul Hema (talkcontribs)

Moin moin.

Is it possible to control the elements in the Sidebar in dependence of the current usergroup? I think there is a new extension. But then you have to built a separate sidebar for every usergroup. I want only change ONE entry in the default sidebar.

Something like {{#ifgroup : thebestusergroupever | superartikle }}

thanks, Paul

By the way: is there a possibility to get a preview of my new theme?

12:34, 18 August 2016 1 month ago

Seb35 (talkcontribs)

@Paul Hema: I don’t know any such extension or way to do it in pure MediaWiki+PHP. Possibly you have to create an extension (the hard way) or write some JavaScript code. In JavaScript, you can do something like: (not tested, you have to debug it)

if( wgUserGroups.indexOf( 'autoconfirmed' ) == -1 ) {
    $( '#n-mainpage-description' ).style( 'display', 'none' );
}

This should hide the element “Main page” (identified by id="n-mainpage-description" in HTML) for users who are not in the group “autoconfirmed” (search $wgUserGroups in HTML to see the groups of the current user). Such code can be put in your MediaWiki:Common.js.

Preview of a theme (“skin” in MediaWiki language) is possible for each user: go in your preferences, tab Appearance and click “Preview” next to a skin. The available skins must be previously installed by the system administrator, and enabled in LocalSettings.php.

Edited 13:22, 18 August 2016 1 month ago

Seb35 (talkcontribs)

Ok, just tried. It almost worked but correct code is: (I confounded jQuery with D3.js I recently learned)

if( wgUserGroups.indexOf( 'autoconfirmed' ) == -1 ) {
    $( '#n-mainpage-description' ).css( 'display', 'none' );
}

13:31, 18 August 2016 1 month ago

Paul Hema (talkcontribs)

Thank you. First it looks good.

But there are a few errors: in the NS "special" (e.g. the lockin page) it dosn't work. Also if you change from one to an other site, the hidden thinks flashes up.

In the meantime i found Manual:Interface/Sidebar#Add or remove toolbox sections .28JavaScript.29 and will try it ...

13:49, 18 August 2016 1 month ago

Legoktm (talkcontribs)

You can use Extension:DynamicSidebar.

05:08, 23 August 2016 1 month ago

Paul Hema (talkcontribs)

Hi Legoktm,

it seems to work perfect for me (although the extension officially supports only MW version 1.24).

Thanks a lot.

08:29, 23 August 2016 1 month ago

Stubborn notices

6 comments • 08:32, 29 August 2016 1 month ago

6

Summary by Trizek (WMF)

Solved.

Gestumblindi (talkcontribs)

I'm having a hard time with the "Notices" icon which stubbornly tells me that I have 3 new notices here on MediaWiki.org, so this gets displayed in other Wikimedia projects, too. The notices come from Talk:Reading/Web/Projects/Related pages where apparently some spam posts were deleted, but it seems that now I have no way to mark them as really read. Special:Notifications says that I have no unread notifications, still there's a "3" appearing on the notifications icon. Any advice on getting rid of these? I've tried taking the page from my watchlist, but the existing notifications are still displayed.

Edited 18:19, 8 August 2016 2 months ago

Trizek (WMF) (talkcontribs)

We have made some fixes to prevent notifications from deleted topics, but my may have been trapped in the glitch. I'm sorry about that, let's try to fix it!

Have you tried to bypass your cache?

If it is not working, that would mean it is a bug.

Edited 09:32, 9 August 2016 2 months ago

Gestumblindi (talkcontribs)

@Trizek (WMF): "Have you tried to ?" - tried to do... well, what? ;-) It seems it's fixed itself, maybe through the new notification your response here generated? - instead of the "3", there was now an "1" and after having read your response, it's gone. So, fixed for me, at least for now, but maybe there's still an issue that needs fixing...?

18:32, 8 August 2016 2 months ago

Trizek (WMF) (talkcontribs)

Apparently not. I keep you r feedback in mind, and if I have an other one, I'll report it.

Happy to see this is fixed! :)

18:49, 8 August 2016 2 months ago

Gestumblindi (talkcontribs)

Not really fixed, it seems; I have now another of these "stubborn" notices, now for a deleted new topic on this page (Project:Current issues)...

21:44, 14 August 2016 2 months ago

Gestumblindi (talkcontribs)

It lasted for days, but today, this notice is gone, too. But I wouldn't be surprised if this happens again when a topic on a watched page is deleted...

18:48, 16 August 2016 2 months ago

Project:Current issues

About this board

Using watchlist notice for Code of Conduct calls for feedback

PdfExport does not work on 1.27.0

Phantom notifications coming from MediaWiki.org

Translate extension

Are you into home page design?

Mediawiki:Lang

Please take part in the Flow satisfaction survey

My wiki is gone!

sidebar dependes on usergroup

Stubborn notices

Navigation menu

Personal tools

Namespaces

Variants

Views

More

Search

Navigation

Support

Development

MediaWiki.org

Print/export

Tools

In other languages