Forum:Mededelingen

Mededelingen over het beheer, de werking en de layout van deze website. Om terug te gaan, klik hier.

2018

Naamruimtes projectpagina's

Probleem: Wanneer men op een link naar een projectpagina (pagina's met prefix Mechelen Mapt:) klikte, bestond deze niet meer. De pagina's waren nooit weg, konden niet worden opgeroepen door een verkeerde systeeminstelling. | Cartoonist | Contact | 15 dec 2018 16:27 (UTC)

Status: Opgelost.

Gebruiker verlaat Mechelen Mapt

Probleem: Een gebruikersaccount kunnen we niet vernietigen (denk maar aan de talloze spamaccounts). Bovendien kunnen in bijvoorbeeld artikelgeschiedenissen of in overlegpagina's links naar de gebruikerspagina of de gebruikersoverlegpagina bestaan (en dat gaan we niet na). Daarom zou het ongepast zijn een van die persoonlijke paginas's te verwijderen, wanneer een gebruiker vraagt zijn account te sluiten. Wel gaan we als volgt te werk :

Het lijkt ingewikkeld door de uitleg maar het is een simpel selecteer- en kopieer  /  knip - & plakwerkje.

1. De gebruiker blokkeren, zonder IP blokkering ! — Ex-gebruiker mag geen e-mails via Mechelen Mapt zenden.

Vervalt:  Onbepaald 

Reden:  Anders 

Reden:  De gebruiker verzocht om sluiting van het account. Voorkomen van misbruik door eventuele identiteitrover. 

V   Registreren gebruikers blokkeren (aangevinkt laten)

V   Gebruiker weerhouden van het sturen van e-mail (aanvinken !)

_   Automatisch de IP-adressen van deze gebruiker blokkeren (NIET aangevinkt laten !)

_   Gebruikerspagina en overlegpagina op volglijst plaatsen (onnodig, zal seffens aangevinkt staan bij beveiligen)

    Klaar? Even meegedacht en goed nagekeken? Druk 'Deze gebruiker blokkeren'.

2. De gebruikerspagina beveiligen.

Bewerken:  Alleen beheerders toestaan 

Bewerken: Duur:  Onbeperkt 

V   Overige beveiligingsinstellingen beschikbaar maken (aanvinken !)

Hernoemen:  Alleen beheerders toestaan 

Hernoemen: Duur:  Onbeperkt 

_   Cascadebeveiliging (NIET aanvinken !)

Overige/additioneleReden:  Pagina onder beheerdersverantwoordelijkheid  (misleidende marge want slaat op de ganse beveiliging,  n ‍i ‍e ‍t  op een cascade)

Overige/additionele reden:  Pagina van gebruiker die Mechelen Mapt verliet 

V   Deze pagina volgen (aangevinkt laten want onze beveiligingen kunnen omzeild worden)

    Klaar? Even meegedacht en goed nagekeken? Druk 'Bevestigen'.

3. De gebruikersoverlegpagina beveiligen op identieke wijze.

4. De gebruikerspagina wijzigen:

4.1. Tenzij de gebruiker zelf de gebruikerspagina (al dan niet eerst leeggehaald) van een afscheidsbericht (zonder een persoonsgerichte kritiek of schuttingtaal) heeft voorzien:
      4.1.1. de gebruikerspagina leeghalen, en
      4.1.2. de gebruikerspagina omvormen tot een doorverwijzing naar de bijhorende gebruikersoverlegpagina.
4.2. Dan, hetzij helemaal bovenin de behouden pagina, hetzij onder de doorverwijzing:
      4.2.1. op de gebruikerspagina de tab 'Bewerken' onderdrukken (zelfs al zorgde een beveiliging er al voor);
      4.2.1. op de gebruikerspagina de tab 'Brontekst bekijken' onderdrukken (wat niet automatisch gebeurde bij beveiligen);
      4.2.2. op de gebruikerspagina de tab 'Kopje toevoegen' onderdrukken (zelfs al zorgde een beveiliging er al voor);
      4.2.3. op de gebruikerspagina de tab 'Geschiedenis weergeven' onderdrukken;
      4.2.4. op de gebruikerspagina het item 'Verwijderen' in de tab 'Meer' onderdrukken;
      4.2.5. op de gebruikerspagina het item 'Hernoemen' in de tab 'Meer' onderdrukken (zelfs al zorgde een beveiliging er al voor) :

#DOORVERWIJZING [[Overleg gebruiker:{{subst:PAGENAME}}]]
{{noedit}}<css>#ca-viewsource, #ca-addsection, #ca-history, #ca-delete, #ca-move {display:none !important}</css>

◀— slechts indien de pagina compleet leeggehaald werd !

    Bewerkingssamenvatting: naargelang het geval:
De gebruiker wenst sluiting van het gebruikersaccount. We kunnen slechts de gebruikerslogin blokkeren, de gebruikerspagina met de bekendmaking bijzonder onbewerkbaar en onnatrekbaar maken en het gebruikersoverleg bijzonder onbewerkbaar archiveren.
    ofwel
Gebruiker wenst sluiting van het gebruikersaccount. We kunnen slechts de gebruikerslogin blokkeren en de bijzonder onbewerkbare en onnatrekbare gebruikerspagina doen doorverwijzen naar de bijzonder onbewerkbare gebruikersoverlegpagina met de bekendmaking.
Klaar? Bewerking ter controle bekeken? Druk 'Pagina opslaan'.

5. De gebruikersoverlegpagina als archief klaarzetten:

5.1. op de gebruikersoverlegpagina de tab 'Bewerken' onderdrukken (zelfs al zorgde een beveiliging er al voor);
5.2. op de gebruikersoverlegpagina de tab 'Kopje toevoegen' onderdrukken (zelfs al zorgde een beveiliging er al voor);
5.3. op de gebruikersoverlegpagina het item 'Verwijderen' in de tab 'Meer' onderdrukken;
5.4. op de gebruikersoverlegpagina het item 'Hernoemen' in de tab 'Meer' onderdrukken (zelfs al zorgde een beveiliging er al voor);
5.5. de geheel behouden gebruikersoverlegpagina helemaal bovenin van een passende melding voorzien :

{{noedit}}<css>#ca-addsection, #ca-delete, #ca-move {display:none !important}</css>
<div style="margin-bottom:1em;border:3px solid #a00;color:#a00;background-color:#fcc;text-align:center;">
'''Deze gearchiveerde overlegpagina mag niet meer gewijzigd worden.'''.</div>

    Bewerkingssamenvatting:
De gebruiker wenste de sluiting van het gebruikersaccount.

Klaar? 

De geheel behouden gebruikerspagina wordt bijzonder onbewerkbaar maar wel natrekbaar gearchiveerd, met zichtbare tabs 'Geschiedenis weergeven' en (hoewel niet voor beheerders) 'Brontekst bekijken':

Klaar? Bewerking ter controle bekeken? Druk 'Pagina opslaan'.

6. De gebruikersoverlegpagina archiveren:

6.1. Klik de tab 'Geschiedenis weergeven' en klik op de datum en tijd van uw zopas opgeslagen versie. Selecteer alles in de adresbalk van de browser en kopieer.
6.2. Klik de ook hier aanwezige tab 'Geschiedenis weergeven' maar klik ditmaal op de datum en tijd van een oudere versie. Klik op de daar aanwezige tab 'Bewerken'. Selecteer alles in het bewerkingsvenster en plak de daarnet gekopieerde inhoud van de adresbalk in de plaats.
6.3. Dan, met de cursor net vóór de zopas geplakte 'url' http://.../index.php?title=Overleg_gebruiker:?????????&oldid=??????:
      6.3.1. op de gebruikersoverlegpagina (met slechts een url) de tab 'Bewerken' onderdrukken (zelfs al zorgde een beveiliging er al voor);
      6.3.2. op de gebruikersoverlegpagina de tab 'Brontekst bekijken' onderdrukken (wat niet automatisch gebeurde bij beveiligen);
      6.3.3. op de gebruikersoverlegpagina de tab 'Kopje toevoegen' onderdrukken (zelfs al zorgde een beveiliging er al voor);
      6.3.4. op de gebruikersoverlegpagina de tab 'Geschiedenis weergeven' onderdrukken;
      6.3.5. op de gebruikersoverlegpagina het item 'Verwijderen' in de tab 'Meer' onderdrukken;
      6.3.6. op de gebruikersoverlegpagina het item 'Hernoemen' in de tab 'Meer' onderdrukken (zelfs al zorgde een beveiliging er al voor);
      6.3.7. de gebruikersoverlegpagina van een passende melding voorzien :

{{noedit}}<css>#ca-viewsource, #ca-addsection, #ca-history, #ca-delete, #ca-move {display:none !important}</css>
De gebruiker verzocht {{subst:SITENAME}} in {{subst:CURRENTMONTHNAME}} {{subst:CURRENTYEAR}}
om zich uit te schrijven.<br />
Deze overlegpagina mag bijgevolg niet langer benut worden. U vindt de laatste versie als
<span class="plainlinks">[XXX archief]</span><!--
aldaar met normaal functionerende tab "Geschiedenis weergeven'-->.

6.4.Knip die url weg en plak die over de geselecteerde XXX heen.
    Bewerkingssamenvatting:
De gebruiker wenst sluiting van het gebruikersaccount. We kunnen slechts de gebruikerslogin blokkeren, de gebruikerspagina met de bekendmaking bijzonder onbewerkbaar en onnatrekbaar maken en het gebruikersoverleg bijzonder onbewerkbaar archiveren.
Klaar? Bewerking ter controle bekeken? Druk 'Pagina opslaan'.

Tijd voor een koffie of een pintje !

— SomeHuman 2018-12-21 21:00 - 2018-12-23 11:05 (UTC=WINTER-1 ZOMER-2)

Status: Klaar.

Pagina's met een pagina-eigenschap

Probleem: Speciale pagina's → Pagina's met een pagina-eigenschap: selectie 'displaytitle' → lijst van pagina's die {‍{DISPLAYTITLE:...}‍} bevatten. Die is onvolledig  :

Het sjabloon aangebracht sedert geruime tijd (MdA), recenter (Anker) of zeer recent (Forum:Inhoud), komt voor in de pagina's van de lijst. Het allicht binnen die periode aangebrachte sjabloon met identieke syntax —‍ ook qua hoofdletters en locatie in het bestand —‍ (Akker [beveiligde pagina], Stillen Genieter [niet beveiligde pagina], ...), dat ook correct functioneert, staat in pagina's die ontbreken  in de lijst.

Suggestie: De procedure bij opslaan bevat allicht een routine om het sjabloon te detecteren en de paginanaam in een lijst op te nemen (of in een lijst met alle paginanamen een flag te zetten). Mogelijke verklaring: Die routine verkeert soms buiten westen zonder het opslaan te verhinderen; in dat geval wordt noch geregeld gescand noch bij uitvoeren van het sjabloon gecheckt of de lijst juist staat. Eventuele oplossing: Een 'bot' laten scannen en de lijst bijwerken (vermoedelijk buiten bevoegdheden van Mechelen Mapt). Alternatief: Nagaan of andere Mediawiki's dit probleem hebben of oplosten ...

[2019-01-03:] Daarnaast blijken lijstjes onwaarschijnlijk of met zekerheid (Speciale pagina's → Oudste pagina's, Pagina's met de minste bewerkingen) onterecht leeg, allicht omdat hun cache nooit bijgewerkt raakt.
— SomeHuman 2018-12-23 02:13 - 2019-01-03 15:25 (UTC=WINTER-1 ZOMER-2)

Status: Open. Prioriteit : Laag.

Uitgebreid zoeken

Probleem: Zoekbalk → Zoeken: Uitgebreid → Zoeken in naamruimten: toont twee keer  de selecties voor 'Mechelen Mapt' & 'Overleg Mechelen Mapt'. Allicht houdt dit verband met de recente Mediawikiversie en de aanpassingen daartoe op Mechelen Mapt ; het is niet evident of een nog nodige selectieset voor een naamruimte nu zou ontbreken.
— SomeHuman 2018-12-23 11:35 (UTC=WINTER-1 ZOMER-2)

Status: Open. Prioriteit : Laag.

Gebrekkige pseudotags

1. De pseudotag <charinsert> </charinsert>: Een klik op é‍ é‍ n van de 'speciale tekens' of 'speciale functies' in Extra's bij bewerken plaatste het aangeklikte op de plaats van de cursor in het bewerkingsvenster. Technisch werd alles tussen de begin- en eindtag gekopieerd. Sinds de recentste Mediawikiversie werkt dit niet meer; de pseudotag wordt niet eens herkend zodat die uiterst storend als tekst verschijnt. In afwachting van een functionele oplossing, werden vorige week die pseudotags verwijderd en dient men nu een teken of functie onhandig te selecteren, kopiëren, opnieuw de juiste plaats in het bewerkingsvenster vinden en daar plakken.
— SomeHuman 2018-12-24 02:05-02:22 (UTC=WINTER-1 ZOMER-2)
Update: MediaWiki 1.31/PHP7 2019-07 heeft de extensie voor charinsert zodat de toegepaste noodoplossing zopas ongedaan is gemaakt.
— SomeHuman 2019-08-05 00:19 (UTC=WINTER-1 ZOMER-2)
Status 1: Opgelost.

2. De pseudotag <youtube> </youtube> liet toe een Youtube of Vimeo videootje te tonen, waarbij de afmetingen geparametriseerd werden. Sinds de recentste Mediawikiversie halen die parameters niets meer uit; er is slechts één (te groot) formaat beschikbaar. De Vimeo's lijken helemaal niet meer getoond te worden maar het kader krijgt dezelfde grote afmeting als de Youtubes; dat formaat is dus door onze Mediawiki bepaald. Misschien had Vimeo bepaalde parameters echt nodig om een passende resolutie te kiezen maar geeft Youtube een terugvalresolutie. Het ziet ernaar uit dat onze Mediawiki de parameters niet meer doorgeeft. [2019-03-04:] Blijkbaar vergt de extensie youtube een nieuwe, simpelere syntax. Ik paste de stylesheet aan om in al onze nog niet aangepaste artikels die grote beelden netjes onder mekaar te tonen en om de andere met reeds de nieuwe syntax correct te laten werken. De oude syntax werkte ook voor andere videoleveranciers dan Youtube, zoals Vimeo; de nieuwe niet. De nieuwe syntax mag (geleidelijk) de oude in bestaande artikels vervangen. De aparte extensie 'EmbedVideo' maakt alle gangbare videoleveranciers beschikbaar.
— SomeHuman 2018-12-24 02:05 - 2019-03-04 04:31 - 2019-03-05 07:53 (UTC=WINTER-1 ZOMER-2)
Update: Eerst voor Youtube globale noodoplossing toegepast, dan maandenlang de 239 artikels die het benutten, één voor één bewerkt, telkens elk van de 1 tot een dozijn videootjes erin aangepast, inclusief bij elke Vimeo de extensie EmbedVideo geïmplementeerd.
— SomeHuman 2020-04-02 10:52 (UTC=WINTER-1 ZOMER-2)
Status 2: Opgelost. In zeldzame (niet traceerbare) gevallen zou na een video(reeks) de verticale spatiëring iets te ruim kunnen blijken, elk vergt aparte behandeling (meerdere technische oorzaken mogelijk).

3. De pseudotag <googlemap> </googlemap> levert sedert (ongeveer) de recentste Mediawikiversie een al te duistere kaart  met daar overheen een kader met de foutmelding: "Google — Google Maps kan niet correct op deze pagina worden geladen. — Do you own this website? — |OK| ". Bemerk de link, naar Maps JavaScript API-foutmeldingen op het Google Maps platform. Bij 'OK' klikken verdwijnt het kader. Overheen de kaart, die wel alle argumenten binnen de begintag en parameters tussen begin- en eindtag blijkt te gehoorzamen, staat herhaaldelijk "For development purposes only". In feite: Google Maps kan wel, maar wil niet. [2019-01-12:] Google wil nu betaald worden na een dosis gratis gebruik en lijkt vooraf aanvaarding van een betalingswijze te eisen. Kan Mechelen Mapt toch een gratis ‍'API-key'‍  bekomen of gaan we de Mediawiki (allicht met extra extension ) omschakelen (en moeten we achteraf alles wat kan omwerken) naar open source  OpenStreetMap (OSM)?
— SomeHuman 2018-12-24 02:05 - 2019-01-12 18:30 (UTC=WINTER-1 ZOMER-2)
Status 3: Zie in 2019 Google Maps buiten gebruik.

Gebruikers-e-mail

Probleem: Gebruikers kunnen vanuit hun 'Instellingen' → Voorkeuren een e-mailadres invoeren maar Mechelen Mapt verstuurt de e-mail om dat e-mailadres te laten bevestigen nooit, hoewel een schermmelding beweert (en bij elke nieuwe poging volhoudt) die gezonden te hebben. Volgens CartoonistHenning dient het euvel buitenlands (na erg lang wachten) verholpen te worden in de Php-code. Allicht zou hij inmiddels wel een gebruiker ‍'emailconfirmed'‍  kunnen erkennen; daartoe is nog geen procedure gepubliceerd.
— SomeHuman 2018-12-24 03:47 (UTC=WINTER-1 ZOMER-2)

Status: Open. Prioriteit : Zeer hoog (tot bekendmaking noodprocedure).

Afbeeldingen

Probleem: Sedert (ongeveer) de recentste Mediawikiversie worden door [‍[Bestand:bestandnaam|thumb|...px|beschrijving]‍] geï‍ ncorporeerde afbeeldingen slechts getoond indien die opgegeven breedte in pixels overeenstemt met de opgeslagen afbeelding. Voordien mocht het te tonen formaat verschillen, zodat veel artikels verknoeid blijken. Voor een nette lay-out is resizing  vereist. We kunnen niet elke afbeelding opnieuw opslaan ; in verschillende formaten meermaals voor meerdere artikels zou trouwens onpraktisch wezen.
— SomeHuman 2018-12-25 00:36 - 2018-12-26 17:36 (UTC=WINTER-1 ZOMER-2)
Update: De eind juli 2019 op de hostserver geï‍ nstalleerde versie van Mediawiki/PHP7 heeft dit probleem niet.
— SomeHuman 2019-07-30 02:59 (UTC=WINTER-1 ZOMER-2)

Status: Opgelost.

Kaart bewerken

Probleem: Sinds (minstens) de recentste Mediawikiversie is bovenaan het bewerkingsvenster in de (mits Instellingen → Voorkeuren: tab Bewerken: Tekstverwerker: aangevinkte 'Bewerkingswerkbalk weergeven' en — zie in '2019'  Instellingen - Bewerken — uitgevinkte 'Uitgebreide bewerkingsbalk inschakelen' getoonde) bewerkingsbalk de meest rechtse knop 'undefined', ook als in de pagina al een kaartje voorkomt. Zonder dit handige hulpmiddel om het te dimensioneren en er markeringen en bovenal gekleurde lijnen of vlakken in te tekenen, vergt die taak degelijke kennis van de Google Mapssyntax (hoewel ver onderaan Extra's bij bewerking voorbeelden kan tonen) en blijft het moeizaam gepruts. [2019-01-12:] Zie evenwel Gebrekkige pseudotags: <googlemap>.
— SomeHuman 2018-12-29 16:32 - 2019-01-12 18:36 (UTC=WINTER-1 ZOMER-2)

Status: Zie in 2019 Google Maps buiten gebruik.

Leeshinder

Probleem: Sedert (ongeveer) de recentste Mediawikiversie hindert de persoonlijke hoofding, alleen met het (default ) uiterlijk 'Vector' ingesteld, het lezen van de erachter scrollende pagina. Bovendien is de achtergrond van de hoofding storend langer dan de / mijn reeksje koppelingen erin. Best zou in die rechterbovenhoek slechts het symbooltje zichtbaar zijn dat vooraan staat in die hoofding, welke naar links toe (net ver genoeg en zonder extra eindje achtergrond) zou uitklappen zodra de aanwijzer in die hoek komt. Tot dan is er (sinds daarnet) een zeer behoorlijke oplossing door die ganse hoofding meer doorzichtig te maken en de achtergrond tot de afzonderlijke elementen te beperken ; elk element is minstens herkenbaar en zodra de aanwijzer erover komt perfect leesbaar.
— SomeHuman 2018-12-25 13:25 - 2018-12-26 18:58 (UTC=WINTER-1 ZOMER-2)

Status: Opgelost ; mag nog beter worden.

Navigatie en huisstijl

1. Probleempje: Met het (default ) uiterlijk 'Vector' ingesteld, hoefde men vanuit de koppelingen in de inhoud of vanuit het bewerkingsvenster het halve linkermenu voorbij om een menukoppeling alleen onder het links uitgelijnde woord of tekstje te vinden. Door de linkkleur op fel contrasterende achtergrond, wees pas ‍'gaan proberen'‍  uit dat de woorden 'Tools', 'Share' e.d. geen koppelingen zijn. Ik breidde de gevoelige zone naar rechts toe uit, zodat men een cartouche ziet opduiken, die netjes past bij de voor leesbaarheid op 2018-12-25~26 geï‍ntroduceerde (in de banner  tot men scrollt). Het menu kreeg een neutrale achtergrondkleur en laat nu ook de ganse Toren zien en de Beyaert herkennen. Boven de hoofdinhoud volgen sinds 2018-12-28 alle navigatie ('Overleg', 'Bewerken' e.d.) en de zoekfunctie deze stijl ; die houdt op de Grote Markt‍foto van de huisgevels nu slechts de terrassen uit het zicht. Men kan even vlot bewerken maar artikels ogen nu aardiger om gelezen te worden. Zoals reeds onderhavige pagina, kan deze herkenbare huisstijl met afgeronde hoeken (geleidelijk aan) toegepast worden binnenin (dus ook bij iemands ingesteld ander uiterlijk) alle hulp- en infopagina's ; artikels en gebruikerspagina's behouden hun hoekige inhoud.
— SomeHuman 2018-12-27 19:41 - 2018-12-29 16:36 (UTC=WINTER-1 ZOMER-2)
Status 1: Opgelost. Eventueel krijgen hulp- en infopagina's nog de typerende stijl.

2. Probleempje: Allicht alleen met het (default ) uiterlijk 'Vector' ingesteld, prijkt meteen boven de hoofdinhoud in de rechternavigatiebalk "Meer" (met een klein pijltje omlaag). Een klik erop laat een menuutje openvallen met de overige mogelijkheden. In sommige  speciale pagina's zonder  iets extra stond toch "Meer", al haalde een klik niets uit. De Mediawiki verwerkt de dan voorkomende css-classe ‍'emptyPortlet'‍ niet correct. Ik zorgde er zopas in de voor dat uiterlijk bedoelde css (opmaakcode) voor dat "Meer" niet onnodig opduikt.
— SomeHuman 2018-12-31 16:26 (UTC=WINTER-1 ZOMER-2)
Status 2: Opgelost ; (tenzij toch een ander uiterlijk dit euvel zou vertonen).

Beveiligingen

1. Probleem: Vroegere spamplagen, welke nu efficiënter bekampt worden, leidden tot het aanmaken van bepaalde artikels in hoofdnaamruimte en/of hun overlegpagina (en enige andere types) voorbehouden aan bevestigde gebruikers of zelfs beheerders. Heden herzag ik die één voor één.
— SomeHuman 2018-12-25 03:50 (UTC=WINTER-1 ZOMER-2)
Status 1: Opgelost.

2. Probleem: Vroegere spamplagen, welke nu efficiënter bekampt worden, leidden tot het bewerken van bijna 600 artikels voorbehouden aan bevestigde gebruikers. Dit hindert niet ingelogde gebruikers en bemoeilijkt nieuwe gebruikers om aan het nodige aantal bewerkingen voor hun bevestiging te komen. Mijn bericht op gebrukersoverlegpagina's verhelpt dit sinds enige tijd, maar de omzeiling is een tikkeltje omslachtig, vergt (mijn) tussenkomst en de onzekere wachttijd zal ontmoedigend werken. Het aantal semibeveiligingen lijkt echter te groot om één voor één te wijzigen.
— SomeHuman 2018-12-25 03:50-16:15 (UTC=WINTER-1 ZOMER-2)
Status 2: Open ; noodoplossing toegepast. Prioriteit : Laag.

2019

Instellingen - Bewerken

Probleem: Instellingen → Voorkeuren: tab Bewerken: Tekstverwerker: aanvinkbaar 'Bewerkingswerkbalk weergeven' en aanvinkbaar 'Uitgebreide bewerkingsbalk inschakelen' — Het eerstgenoemde vinkje zorgt in elke bewerkte pagina net boven het bewerkingsvenster voor een balk met knoppen tot o.m. invoegen van vet of schuinschrift en als laatste (zodra het Kaart bewerken probleem van 2018 is opgelost) tot bewerkingshulp bij een Google Mapskaart. Het andere vinkje lijkt nog iets extra te bieden maar ... zopas ontdekt: aanvinken van inschakelen toont niets extra doch integendeel voorkomt het zelfs dat de balk waartoe die eerstgenoemde optie is aangevinkt, getoond wordt. Opvolging:

Ik vermoed dat die twee als aparte opties aanvinkbare checkboxes programmatorisch als uniek te kiezen radiobuttons verwerkt worden (een bug in de instellingenpagina of daarin aangeroepen script) en effectieve naleving van de tweede keuze elders (zoals in een stylesheet) uitgeschakeld werd — zodus na te zien in gemene en selecteerbare scripts & stylesheets. Het euvel treft minstens het uiterlijk 'Vector' en 'Modern' maar dat bewijst niet afdoende dat een fout in de gemene js of css staat ; standaard staat slechts 'Bewerkingswerkbalk weergeven' aangevinkt maar een nieuwe gebruiker zou allicht zoveel mogelijk hulpmiddelen inschakelen ...

— SomeHuman 2019-01-03 00:14-03:02 (UTC=WINTER-1 ZOMER-2)

Status: Open. Prioriteit : Laag.

English

1. Probleem: Onze weinige Engelstalige artikels zijn volop gecodeerd als lang="nl" in plaats van "en". Dit dempt sterk hun gewenste internationale vindbaarheid in zoekmachines.
— SomeHuman 2019-01-03 08:34 (UTC=WINTER-1 ZOMER-2)
Status: Open. Prioriteit : Laag.

2. Probleempje: Naast een Engelstalig artikel, op Mechelen Mapt steeds <artikelnaam>/English, staat in het linkermenu onder 'In English' nogal dom ook 'This article'. Vervelend is dat een (ook nogal dom) klikje erop, geen artikel <artikelnaam>/English/English kan vinden. Die menuoptie zou dan moeten wegblijven. Optie 'Main page' als men daar al is, lukt net zo goed als helemaal bovenaan 'Home' vanuit de Nederlandstalige Hoofdpagina.
— SomeHuman 2019-01-10 05:58-06:45 (UTC=WINTER-1 ZOMER-2)
Status: Open. Prioriteit : (Zeer) laag.

Verdwenen info

Probleem: Hoofdpagina|Hoofdpagina/English|Help:Statistieken → Mechelen Mapt:Statistieken: 'Concreet aantal pagina's op deze wiki met unieke bezoekersaantallen (hoofdnaamruimte)' → onbestaande  Speciaal:PopularPages. Verklaring: voor huidige Mediawikiversie nodige 'Extension:HitCounters' ontbreekt. Oplossing: 'HitCounters' laten installeren ofwel  (vermits dan Mechelen Mapt:Statistieken slechts 1 link zou overhouden) Mechelen Mapt:Statistieken verwijderen en Hoofdpagina, Hoofdpagina/English en Help:Statistieken direct linken naar Speciaal:Statistieken. 'HitCounters' kan meer beï‍ nvloeden; ik overleg met CartoonistHenning.
— SomeHuman 2019-01-04 16:03 (UTC=WINTER-1 ZOMER-2)

Status: Open. Prioriteit : Laag.

Hoofdpagina

Probleem: Op onze voornaamste presentiepagina, Home, stonden In de kijker  links naar verouderde zaken. Ik zette er naar artikel 'Mechelen' en de bijzonderste huidige categories onderwerpen. De daaronder verwachte sectie Nieuwste pagina's  was al lang buiten gebruik gesteld, allicht om hinderlijke, rommelige info te vermijden. Ik gaf zopas de hoofdpagina controle (net als Hoofdpagina/English voor Featured & Recent pages) over wat opgehaald en getoond wordt, met een zeer net resultaat in de hoofdpagina. Daarin werd onderwijl het onderste blokje info ordelijker en nauwer in lijn met de 'Share' in ons alomtegenwoordig linkermenu, en pastelkleuren van blokken gepast bij de afbeelding erin. Het berichtje bovenin over technische problemen, wijst nu op onderhavige Mededelingen.
— SomeHuman 2019-01-05 06:57 - 2019-01-11 03:32 (UTC=WINTER-1 ZOMER-2)

Status: Opgelost.

Google Maps buiten gebruik

Probleem: De Google Maps-extensie is verlaten en werkt niet langer voor PHP 7. Google biedt ook niet langer de Maps API gratis aan voor kleine websites. De multimaps-extensie is een goed alternatief dat werkt, met behulp van OpenStreetMap. Naast de hoofdpagina doen zeventig andere pagina's beroep op Google Maps.
— Carlb (overleg) 29 jul 2019 15:49 - 30 jul 14:44 (UTC)
De syntax verschilt sterk van die van Google Maps. Die nu nodige parameters lijken me mooi verduidelijkt op een (Engelstalige) andere wiki. Vergelijk oud versus nieuw in Mechelen Noord (veel afbakenende lijnen en ingekleurde vormen): de getalwaarden blijken vlot over te nemen, behalve kleurdekking: in googlemaps hexadecimaal 00 (doorzichtig) tot FF (decimaal 255, volle kleur) van bvb E5 wordt decimaal 229/255 = afgerond 0.90 (90% dekkend) in multimaps. De coördinaten van deze Netegrens exporteerde ik met formaatkeuze gpx uit uMap (waarin men wel links pijltje neerwaarts en knop 'Verander kaartachtergond' drukt om aan rechterzijde 'OpenStreetMap' in plaats van 'OSM fr' te selecteren alvorens te tekenen); (resultaatbestand geopend in Notepad, alles voor en na de rij coördinaatcijfers weggeknipt en dan 2 x 'replace all' het onnodige erbinnen door : respectievelijk , ).
— SomeHuman 2019-07-30 03:48 - 2021-01-17 11:05 (UTC=WINTER-1 ZOMER-2)
Het valt zwaarder dan voorgespiegeld: Die 70 blijken de tip van de ijsberg (allicht die met een 'markeerpunt' waarbij men een specifiek commentaar in de code kan vinden). Ik zette al veel meer dan  92 artikels om en dan blije ven er nog 54 vindbare + een ongekend maar zeker beduidend aantal die niet door een zoekroutine te vinden zijnleken (zie Passage zoeken en tekst vervangen)
— SomeHuman 2019-08-11 04:43 - 2019-09-13 08:31 (UTC=WINTER-1 ZOMER-2)
In januari 2021 werden de laatste 29 artikels met nog 32 x '<googlemap' gevonden met Passage zoeken en tekst vervangen en omgezet naar 'multimaps', behalve het (niet eens voor Mechelen Mapt geschikte) artikel Google Earth: MultiMaps ondersteunt geen gelinkte url in een markeerpunt; die ene googlemap is buiten gebruik gesteld. Er zijn heden 213 'multimaps' in 203 artikels.
— SomeHuman 2021-01-18 09:38 (UTC=WINTER-1 ZOMER-2)
Status: Opgelost.

Fouten bij MediaWiki 1.31/PHP7 2019-07

1. Probleem: Ongewenste blanco lijnen worden ingelast. Meer details

De code:

<div>Blabla1
</div><br />
<div>Blabla2
</div>

 voorkwam dat de tweede 'div' naast  de eerste getoond werd. Die code kwam precies zo in de browser. Sinds eind juli 2019 echter, komt volgende html in de browser:

<div>Blabla1
</div><p><br />
</p><div>Blabla2
</div>

 zodat een ongewenste blanco lijn tussen de beide getoond wordt. Dit verknoeit onder meer 'Filmlinks' met meerdere rijen, maar ook bijvoorbeeld gepreformateerde brokjes, bijvoorbeeld in het artikel Doorverwijspagina. Ook in tegenstelling tot eerder, komt er een zulke blanco lijn boven Blabla2 bij deze code:

<div>Blabla1
</div><br />Blabla2

De layout van tal van pagina's die niet eens opspoorbaar zijn zodat de hele wiki van boven tot onder nagelezen zouden moeten worden, wordt verstoord door een syntax die vroeger veelal noodzakelijk  was om op een nieuwe lijn verder te gaan. Wat we nu gans nieuw netjes schrijven, zal op zijn beurt quasi onvoorspelbaar anders  getoond worden zodra de software opnieuw als voorheen zou werken.
— SomeHuman 2019-07-31 07:00-07:44 (UTC=WINTER-1 ZOMER-2)

Status: Open. Prioriteit: Hoog.

2. Probleem: De nochtans vrij recent ge‍ï‍ ntroduceerde <embedvideo service="  . . .  " dimensions="  . . .  x  . . .  ">  . . .  </embedvideo> wordt niet meer herkend. Dit heeft vooral in 'Filmlinks' met als service Vimeo  kwalijke gevolgen.
— SomeHuman 2019-07-31 07:00 (UTC=WINTER-1 ZOMER-2)
Status: Open. Prioriteit: Vrij hoog.

3. Probleem: Met het (default ) uiterlijk 'Vector' ingesteld, toont elke pagina de (naar Hoofdpagina linkende) logobanner "Mechelen Mapt" te laag (voorheen in de 'lucht' van de foto, net onder de gebruikersnaam). De navigatiekolom links had een vaste, smalle breedte maar is nu flexibel, zodat een breder venster de extra breedte verdeelt tussen linkernavigatie en inhoud. Hierdoor wordt de voor inhoud beschikbare breedte minder  breed dan vroeger en passen onze alom toegepaste standaardbreedtes van 'Galerij' en van 'Filmlinks' niet meer naast een foto of kaartje rechts van de gebruikelijke 400 pixels breed. Zo kan een afbeelding nu de filmlinks onder zich duwen, wat voorheen bij geen enkele browservensterbreedte mogelijk was: daar hadden we op getest.
Erger: Zowel die te laag getoonde logobanner als het linkernavigatiemenu staan vast  op het scherm, in plaats van te kunnen scrollen. Naast de duidelijke visuele hinder, verhindert de logobanner (met brede gevoelige zone) het klikken op tabs en in gescrolde pagina's op links, evenals behoorlijk bewerken van de code. Een flink deel van de linkernavigatie kan niet beschikbaar komen, vermits die lijst dieper is dan een browservenster hoog. Beide elementen lijken statisch gepositioneerd in plaats van relatief en/of een ander ankerpunt te hebben, en beide verschuiven horizontaal of verbreden naargelang de breedte van het browservenster in plaats van een vaste horizontale positie en breedte aan te houden.
— SomeHuman 2019-07-31 07:00 (UTC=WINTER-1 ZOMER-2)
Update: Een paar extra instellingen in de relevante 'stylesheet' loste het ganse probleem op.
— SomeHuman 2020-03-05 18:58 (UTC=WINTER-1 ZOMER-2)
Status: Opgelost ... doch: 2020-03-05 als default  uiterlijk werd sinds maanden dan maar 'Monobook' ingesteld, waarbij dit probleem zich niet voordoet maar zo lijkt de minder fraaie huisstijl al te zeer op Wikipedia: 'Vector' dient opnieuw de default te worden!

Beveiliging wijzigen

Probleem: Na ettelijke wijzigingen van permissies per artikel, voorafgaand aan MediaWiki 1.31/PHP7 (2019-07), lukt zulks sindsdien sporadisch  niet. Beschrijving en ervaring:

Het kwam al eens voor dat het nadien wel lukte maar niet bij "Keizerstraat". Er verschijnt dan de pagina 'Interne fout' met melding zoals:
 [78b145011f7c18b304dd8f4c] 2019-08-11 16:02:48: Fatale fout van type "MediaWiki\Storage\IncompleteRevisionException" 

Ook komt er tussen pogingen in zo nu en dan  een foutbericht bovenin de pagina 'Keizerstraat&action=protect', dat er een probleem scheen met mijn aanmeldsessie maar toch met verzoek gewoon opnieuw te proberen.
Het blijft mislukken, ook na afmelden, leeghalen van de browser cache, rebooten, aanmelden en tal van pogingen op uiteenliggende tijdstippen.
Dit alles deed zich voor, vooraleer ik de pagina 'Keizerstraat' wijzigde (met laatste wijziging in 2016 — enig gegoogel lijkt erop te wijzen dat die oude 'geschiedenis' een rol kan spelen). Na opslaan van mijn bewerking, kon ik de beveiliging meteen wijzigen. Idem op 2019-08-18 met 'Antverpia' uit 2012. Het blijkt dus geen toeval, zodat gewoon eerst even bewerken een doeltreffende work-around is.

— SomeHuman 2019-08-11 22:32 - 2019-08-18 02:16 (UTC=WINTER-1 ZOMER-2)

Status: Open doch te omzeilen als hierboven uitgelegd. Prioriteit : (Zeer) laag.

Passage zoeken en tekst vervangen

Vanuit het zoekbalkje of de zoekpagina vindt men niet gelijk wat. Bijvoorbeeld googlemap  leverde vrijwel alleen die term geplaatst tussen <!-- en --> in de bewerkingscode: een waarschuwing die bovenin amper 1/3 van de pagina's met de tag <googlemap ...> voorkwam. Beheerders  kunnen zulke normaal onvindbare brokjes in de bewerkingscode opsporen met Speciaal:TekstVervangen. De resultatenlijst laat namelijk toe te kiezen waarin daarna de vervanging al dan niet  uitgevoerd wordt. Toch dienen ze het slechts te zoeken  brokje in zowel oud als nieuw te plakken, om accidenteel wissen uit te sluiten. Bij echte, gewenste vervangingen, lijkt die functie perfect te verlopen met bevestiging en al ... maar nadien blijkt nergens iets gewijzigd. Gezien de bevestiging en geen weigering (die niet beheerders wel zien), zal de hoogste bevoegdheid bureaucraat wellicht evenmin werken. Na verificatie door CartoonistHenning allicht op te lossen door Carlb: De vervangfunctie is onmisbaar voor vlot onderhoud.
— SomeHuman 2019-09-11 12:36 - 2019-09-13 08:13 (UTC=WINTER-1 ZOMER-2)
Vele maanden na contacteren van CarlB, bleek de functie effectief te werken. Ook was hem gevraagd om het maximum aantal pagina's die in 1 beweging kunnen gevonden en bewerkt worden, te verhogen. De limiet bleef echter 250, wat voor sommige taken onvoldoende is.
— SomeHuman 2021-01-13 00:30 (UTC=WINTER-1 ZOMER-2)
Status: Open. Prioriteit: Uiterst laag.

2020

Wikitaal naar Html - <br />

Onlangs bleek binnen <gallery>...</gallery> een <br /> geen gevolg te krijgen indien die binnen 'vetjes' of 'schuinschrift' staat: Een nieuwe lijn binnen '‍'‍'... ...'‍'‍' of '‍'... ...'‍' vergde nu '‍'‍'<br />'‍'‍' resp. '‍'<br />'‍', dus vetjes of schuinschrift sluiten en op de volgende lijn heropenen. De voorbije weken paste ik er al enige aan want wanneer de automatische woordomslag niet toevallig daar ingreep, plakte het eerste woord bestemd voor de volgende lijn bots tegen het laatste woord van de bedoelde voorgaande. De oorzaak lag ten dele bij de #2018:#Gebrekkige pseudotags Status 2 work-around en er is daarnet een mouw aangepast.
— SomeHuman 2020-04-09 06:34-14:14 (UTC=WINTER-1 ZOMER-2)
Status: Opgelost.

Verdonkeremaand

Een link in de historiek van Overleg:KRC Mechelen toont Forum:Ondoeltreffend bewerken in het rood. Er zou in 2015 een stuk naartoe verhuisd zijn. Die historiek van de praatjespagina van 'de Racing' toont een IP-bewerker en de historiek van diens bewerkingen toont o.m. een bewerkingscommentaar met link naar Forum:Ondoeltreffend bewerken in het blauw. De 'status bar' van mijn browser toont daar (zoals ook hier net voor) mechelen.mapt.be/wiki/Forum:Ondoeltreffend_bewerken, maar wanneer men die klikt, blijkt dat die pagina nieuw zou worden aangemaakt. Ook bij dat commentaar op 'gesch' klikken geeft slechts: "Deze pagina is niet bewerkt". Maar op 'wijz' bekomt men de verschillen tussen twee versies: Die blijkbaar recentste waarbij inderdaad iets uit Overleg:KRC Racing werd overgezet, en de voorgaande. Men kan een voor een met 'oudere bewerking' de verschillen tussen voorgaande versies opvragen. Maar als men dan ooit bovenaan op de tab 'Forum' of op de tab 'Historiek' klikt, blijkt opnieuw de pagina niet te bestaan en 'Aanmaken' toont evenmin dat die ooit zou verwijderd zijn. Krankzinnig: Ik kan het gedetailleerd verschil tussen alle versies zien van iets dat volgens onze MediaWiki noch bestaat noch ooit bestaan heeft ... Wat is hier aan de hand? Dit is de huidige versie, te vinden door navigatie naar 'recentere versie' maar niet naar 'huidige versie': alweer 'Aanmaken'. De wiki bleek wel om zeep, in die tijd (vandaar mijn toenmalige IP-bewerkingen via een proxyserver), maar de bewuste forumpagina bevat veel meer en zou normaal vindbaar moeten zijn. Dat geldt ook voor de reeks evenzeer verduisterde forae in de Categorie:Forum.
— SomeHuman 2020-05-26 14:37-16:20 (UTC=WINTER-1 ZOMER-2)

2021

Multimaps - zware fout bij ~title= en ~text=‍

Elk element (Marker, Circle, Line, Polygon) kan de tooltipparameters ~title= en/of ~text= [en/of ~* in slechts 2 artikels] bevatten (op Mechelen Mapt gemakshalve steeds helemaal achteraan de reeks parameters). Tijdens 2020 bleek plots dat elk artikel waarin een zulke parameter voorkomt, niets van het artikel toont doch slechts een foutmelding 'Fatal error: MWException'. Het wordt vrijwel zeker veroorzaakt door een softwareupdate op de server, onder controle van de Engelstalige 'bureaucraat' Carlb (de 'serverhost' die er tal van sites technisch beheert en uiterst zelden en pas na maandenlang wachten eventueel ingrijpt; dring niet aan want onze site staat dankzij uitzonderlijke goodwill gratis zonder advertenties op die commerciële buitenlandse server). Tijdelijk zette ik in alle getroffen artikels die parameters buiten werking dankzij <!-- en END20210109multimaps-->, bijvoorbeeld <!--~title=Tooltip [deel] in vetjes~text=Tooltip [deel] in normaal dunEND20210109multimaps-->. Die bizarre eindtag laat een beheerder toe, zodra het probleem opgelost zou blijken, met enkele zoek- en vervangopdrachten zeer vlot alles te herstellen; vervang echter 'END20210109multimaps-->' niet door '‍' (niets, het origineel) maar wel door '<!--END20210109multimaps-->' opdat bij eventuele herhaling van het probleem niet opnieuw artikel per artikel zou hoeven bewerkt te worden: dan volstaat een zoek- en vervangopdracht. Waar de voormalige tooltip duidelijk extra info bevatte, werd die hernomen in het bijschrift onderaan multimaps. In geval de tooltips ooit weer werken, zal slechts wanneer het iemand zou opvallen en echt storen, dat specifieke bijschrift door een manuele bewerking vereenvoudigd worden. Advies: Voeg in nieuwe multimaps waar normaal gepast alvast wel tooltips toe tussen beide tags tot buiten gebruikstelling.
— SomeHuman 2021-01-13 08:48-10:07 (UTC=WINTER-1 ZOMER-2)
Status: Open; multimaps tooltips buiten gebruik maar de meest nuttige info eruit werd permanent leesbaar. Prioriteit: Laag.