Wed, Nov 13
Oct 28 2019
! In T236188#5611628, @sbassett wrote:
Seeing the alert within a developer console is normal, expected behavior for the time being. Again, it should just be a notice-level warning, not an error which blocks a resource from loading. I'm going to resolve this for now unless it can be demonstrated that the CSP in question is actually blocking a resource from being loaded.
Oct 27 2019
@Aklapper sorry for late answer.
I've used Chrome Version 77.0.3865.90 (Build) (64 bit).
I get the same result with Firefox Quantum 69.0.2 (64 bit)
Oct 22 2019
Jul 8 2018
Thanks for your findinds, now my question is if it really make sense.
If there is no problem is term of security or performance I suppose that this block can be reverted.
Any update on this regression?
Jun 29 2018
Jun 25 2018
IMHO a warning message is not a solution, but a temporary patch. A solution should be to use icons that will allow to show POI with counter greater than 99, then any editor will decide if it's a good idea (or even necessary) to use such high number of POI.
May 18 2018
Unfortunately the problem still happens but rarely :-(
It seems that no error has been generated.
@Jdlrobson, by now it seems that the patch works. IE11 doesn't send any error but several warnings most likely not related to this issue.
Since also other language versions should be affected by this problem, I think that the bug should be fixed soon.
Thanks by now.
May 14 2018
@Jdlrobson, I've tried to implement the patch but it seems that it doesn't work. I'll keep it few days more in case you'll need it for a test.
May 11 2018
Today an Italian article has been shown on TV (http://www.teleboario.it/tbnews/turismo-per-iseo-un-altro-riconoscimento-dal-web/) without the proper banner and honestly it's a bit embarassing for the whole project.
Feb 7 2018
Focus has been not restored. It's so difficult the regression of this bug?
Dec 1 2017
@MaxSem can your patch be integrated into the LUA script mentioned above?
In the affirmative case it could be an efficient patch, otherwise the same LUA order function should be inserted inside the extension and activated any time the above templates are used inside the wiki-code.
Nov 29 2017
Oct 28 2017
Sorry, @Aklapper you are right, I was in rush.
It happens anytime with traditional wikitext editor using either Chrome, IE and Firefox (last versions).
Oct 27 2017
Jul 25 2017
Jul 24 2017
Jul 21 2017
For sure I'm simplify too much the issue, but maybe could be enough to add the block <div class="mw-indicators mw-body-content">...</div> (or maybe the renamed mw-mf classes) to allow the whole indicator mechanism.
I don't know if it has been already highlighted but I've just noticed that also the interwikilink goes to the desktop version.
Jul 6 2017
Jul 4 2017
May 31 2017
@Aklapper, I'm not sure if it's the same problem but it looks like.
May 11 2017
Thanks for your excellent clarification!
@Krinkle, could you explain me better this point: @import rules for proper ResourceLoader modules (e.g. not legacy modules 'site' or 'user') is only supported if they are loaded dynamically through mw.loader.?
@matmarex do you think that in the (very?) long term can MediaWiki:Common.css/js be managed through resourceLoader having the benefit of compression and speed without giving the possibility to any user to disable it?
Or maybe there is a technical constraint that preclude this possibility?
@Aklapper although unrelated, could you suggest me in detail how to modify https://it.wikivoyage.org/wiki/MediaWiki:Gadget-Sandbox.js ?
I've applyed the following but I'm not sure if this is what you meant:
@matmarex in MediaWiki:Common.css we have style that must be active for the correct functioning of the wiki. As far as you know, is possible to have a gadget that cannot be disabled by a user?
@matmarex regrouping block of styles in separated files, helps their maintenance, hence I would avoid to reverse the whole set of instruction inside the main file.
May 3 2017
Matroc, thanks to try to find a solution to this bug/limitation that no one is willing to take in charge for its complete resolution.
In my opinion your approach would cause the creation of articles that in the future (when finally this extension would work) should be fixed and it would be difficult to find them.
The JS patch that I've mentioned above would be transparent for the editors.
Apr 19 2017
Apr 5 2017
@Aklapper modifying MediaWiki:Vector.css with the commons image, the correct behaviour has been restored.
Jan 11 2017
Maybe I'm wrong (because I repeat that I haven't seen the code) but I suppose that reason why the banner is shown above the breadcrumb could be the same reason why the banner is shown above the diff.
If confirmed, should be rethought how the banner is displayed.
Dec 15 2016
I understand the reason of your approach, and I agree that in a long term perspective is the right one.
Can the customized solution you mention be applied in the short term until the maki icons will manage correctly the three digits numbers?
@Yurik, any update for the fix of this bug?
Dec 14 2016
Breadcrumbs has been always shown above the banner, inline with the geo coords and map icons.
That is the less intrusive location because it optimizes the available space.
Here below attached what I see on it:voy (jointly with my IE & Windows version).
Dec 2 2016
Dec 1 2016
The old banner hid the page title and created a dedicated new title for the banner, maybe that's way in the old implementation this problem has never occur.
Is it possible to implement the banner in the same way?
I agree that the very top of the page it's not the right place for the banner. The right place is its real position: at the top of the article (below the diff) and not at the top of the page.
As explained before, is an issue not seeing the banner and it must be corrected.
By the way I understand the lack of time... is a common issue :-)
Nov 30 2016
Maybe I'm wrong but since the banner it's just a normal picturre (nothing more, nothing less), I suppose that has been use some code to hide it, so it should be enough to remove/bypass that code.
Nov 15 2016
Putting the banner above the diff without the titla has to be considered a temporary patch that improve the current situation, but the real/final patch has to show banner (title included) below the diff.
Nov 14 2016
Nov 2 2016
Hi @Jdlrobson, do you think that more verifications are needed or is already possible to restore the normal visualization of the diff pages?
Oct 17 2016
@Jdlrobson thanks for sharing the available background.
As briefly wirtten in T110384 by @Tgr and @Nicolas_Raoul banner should stay there.
If there is someone, or maybe a whole language community that for any reason would prefer to see/provide a diff page different from the the real one should be able to do it through a dedicated gadget parameter or extension configuration, but IMHO hide the banner for all the user is not the right approach.
Oct 14 2016
@Jdlrobson I'll try to explain better the issue.
Oct 12 2016
Clearly the same patch shall be applied on MediaWiki:Mobile.js in order to correct the same extension mistake opening a page on mobile view.
Oct 8 2016
Unitl the maintainers are not able to solve this bug, a dirty workaround is the following:
Oct 6 2016
@Yurik, please let me know if you have understood the proposal or not.
In the second case, I'll be more than glad to explain it to you one more time.
Oct 4 2016
@Yurik actually is the opposite.
The old map currently in use in it:voy shows number like 100, 101, 102, etc.
The number shown in the article (generated by the extension) are 99, 99, 99, etc.
@Yurik, since the the map is not working properly because of the 99-limit, in it:voy we are using the old map (see https://it.wikivoyage.org/wiki/Pest#Come_orientarsi ) that show corretly all the numbers and cause no other probelm.
What we need, until this bug is fixed, is a way to show the correct number in the article (see https://it.wikivoyage.org/wiki/Pest#Altri_parchi) where is the only point where is showed the wrong number. Since is not linked to the icon constraint, it shouldn't be an issue.
Oct 3 2016
Yurik sorry, but if a bug is difficult solve doesn't mean that the ticket should be closed.
The limit of 2 digits is a problem for several articles. The old icons worked well. If you want to implement a new icon set (Maki or whatever) is ok, but this choice shouldn't introduce limitations.
Let's keep the bug open since has been found a solution to this problem.
Sep 15 2016
IMHO WikiViewStats is much more complete and userfriendly of any other stats tool (this new one included). Since I'm not able to fix it, I need to accept the community decision, but is really sad to hear this.
Sep 11 2016
@Urbanecm thanks a lot :-)
@Urbanecm no problem for the delay. I've opened it now, since all the most active users has express their consensus, so I do not believe the will arise any change on the next days.
Jul 21 2016
Jun 27 2016
On top on the previous messagge, I've tried to use that parameter on an URL and I can tell you that:
@matej_suchanek in the last 2/3 years it has worked without specifying any value to the parameter hidepatrolled. By the way, I've tried as per your suggestion and it still doesn't work.
Jun 26 2016
Mar 14 2016
I would agree with the fact that is not maintained, but I don't see how it can be harmful if addressed to the right menu.
By the way, as said, the DMOZ are not commonly used in it:voy because most of the category are in English and not in Italian, that's way we haven't integrated DMOZ in any other template (leaving this decision to the single editor); so personally I do not have nothing in contrary on any direction (fix it or delete it).
Just let me know in the second case in order to adjust the affected articles.
@Dereckson: I've thought this discussion was based on the magic word "#related". In previous posts I was referring to it.
@Nemo_bis: maybe the other voy language versions have some bad configuration on extensions or on local templates/modules
@Dereckson: take for example any Italian city (e.g. https://it.wikivoyage.org/wiki/Firenze) On left side you can find "In altri progetti" menu based on Wikidata, and "Pagine correlate" based on RelatedSites.
Mar 13 2016
In https://it.wikivoyage.org this extension is not used for WMF project (managed through Wikidata + custom local template), but is used to link any article to other sources (e.g. pages stored in Portale Namespace).
Oct 31 2015
AWB Version: 184.108.40.206
Aug 21 2015
Honestly I'm not able to judge.
Aug 6 2015
MusikAnimal: this tool shows with (any timeframe) the most accessed pages on a project in a very friendly visual and multilingual interface. This helps a lot to understand the trend of the moment and gives clues (specially for the minor sister project) on which are the pages that should be improved or created (because popular on other languages).
scfc, thanks for the clarification.
What I (and I suppose many other users) want is to have a tool that will allow to easily see which are the most visited pages of any project in a visual way. AFAIK wikiviewstats is the best one.
Currently the tool mostly used that perform a similar job is http://stats.grok.se/ that has several limitation and bugs never fixed.
Aug 5 2015
my question now is: is it possible to restore the tool Wikiviewstats?
My main purpose is to use it :-)
scfc, is it normal the message "Internal error
The URI you have requested, /wikiviewstats/, appears to be non-functional at this time." that I see when I try to access to the wikiviewstats tool?
When I said "turn it off" I was referring to the error log feature, not the whole application.
Can the application be turned on without the error log feature? If not, can the error.log be deleted with an high frequency, in order to mitigate its quick dimension increase (until the problem is completely solved)?
I have the same question of Palnatoke. This, apparently quite easy to solve bug, is open since June.
Jul 11 2015
Cyberpower678, Technical13 do you see any chance to restore this tool?
Jul 8 2015
Thanks a lot Umherirrender.