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?

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.

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.

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

Any update?
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.

Focus has been not restored. It's so difficult the regression of this bug?

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

Sorry, @Aklapper you are right, I was in rush.
It happens anytime with traditional wikitext editor using either Chrome, IE and Firefox (last versions).

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.

Thanks @Aklapper, T53189 is the bug I was mentioning, while this bug is focusing to this new behaviour.

@Aklapper, I'm not sure if it's the same problem but it looks like.

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.

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.

@Aklapper modifying MediaWiki:Vector.css‎ with the commons image, the correct behaviour has been restored.
Thanks.

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.

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?

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

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

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.

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.

@Sumit, @Jdlrobson I don't know if the patch has been already submitted/reviewed or not.

Hi @Jdlrobson, do you think that more verifications are needed or is already possible to restore the normal visualization of the diff pages?

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

@Jdlrobson I'll try to explain better the issue.

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.

Unitl the maintainers are not able to solve this bug, a dirty workaround is the following:

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

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

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.

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.

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

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.

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.

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

AWB Version: 5.8.0.0
Project: https://it.wikivoyage.org

Honestly I'm not able to judge.

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.

mmm
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)?

Any news?

I have the same question of Palnatoke. This, apparently quite easy to solve bug, is open since June.

Cyberpower678, Technical13 do you see any chance to restore this tool?

Thanks a lot Umherirrender.

If in the above search example, I add also the "Tematica" namespace what happens is:
Case 1: it finds the same previous results
Case 2: it finds a new occurrence