Forum:Ondoeltreffend bewerken: verschil tussen versies

Uit Mechelen Mapt, het vrije naslagwerk over Mechelen
Naar navigatie springenNaar zoeken springen
k (Wijzigingen door 198.2.208.35 (Overleg) hersteld tot de laatste versie door SomeHuman)
 
Regel 47: Regel 47:
 
::Het dubbelklikken is dan weer ''nog'' minder interessant bij gebruik van een touchpad, dat ook een tik als een klik aanvaardt. Dat is instelbaar, en handig voor een ''enkele'' klik maar het gevaar ongewild te dubbeltikken i.p.v. bedoeld 'klik + beweeg cursor' is niet geheel onbestaande, dus aan het dubbelklikken mag best geen potentieel groot gevolg ingesteld worden.
 
::Het dubbelklikken is dan weer ''nog'' minder interessant bij gebruik van een touchpad, dat ook een tik als een klik aanvaardt. Dat is instelbaar, en handig voor een ''enkele'' klik maar het gevaar ongewild te dubbeltikken i.p.v. bedoeld 'klik + beweeg cursor' is niet geheel onbestaande, dus aan het dubbelklikken mag best geen potentieel groot gevolg ingesteld worden.
 
::Bij het categoriseren van sjablonen dacht ik al eerder nog een ander sjabloon met dat probleem opgemerkt te hebben, maar vond het achteraf toch niet terug. Misschien zette ik er zonder veel nadenken (bandwerk) ook al een 'includeonly' in terwijl ik een 'noinclude' plaatste met de categorie erin.<br>— [[Gebruiker:SomeHuman|SomeHuman]] <span style="font-size:.87em;">2013-05-24 02:40-02:50&nbsp;(UTC<span style="font-size:87%">=CEST-2</span>)</span>
 
::Bij het categoriseren van sjablonen dacht ik al eerder nog een ander sjabloon met dat probleem opgemerkt te hebben, maar vond het achteraf toch niet terug. Misschien zette ik er zonder veel nadenken (bandwerk) ook al een 'includeonly' in terwijl ik een 'noinclude' plaatste met de categorie erin.<br>— [[Gebruiker:SomeHuman|SomeHuman]] <span style="font-size:.87em;">2013-05-24 02:40-02:50&nbsp;(UTC<span style="font-size:87%">=CEST-2</span>)</span>
  +
  +
==Aanmelden en registreren onmogelijk==
  +
''Het volgende werd van een overlegpagina van het artikel [[KRC Mechelen]] naar hier gekopieerd:
  +
<hr />
  +
Wat is er loos met de video-rangschikking, want na de server-uitval lijkt de line-up verdwenen ? --[[Gebruiker:Gimycko|Gimycko]] 8 feb 2015 19:13 (UTC)
  +
:Hoezo? Ik zie niets abnormaal, tenzij een wat lange wachttijd vooraleer Rik "(1 van 7)" (nochtans slechts 1 filmlink) verschijnt.<br />— [[Gebruiker:SomeHuman|SomeHuman]] <span style="font-size:.87em;">2015-02-09 09:56&nbsp;(UTC<span style="font-size:87%">=CEST-2</span>)</span>
  +
:Ik haalde die "Rik, de Racinger (deel 1 van 7)" zopas weg, want bij afspelen verscheen slechts "This video is private". So be it.<br />— [[Gebruiker:SomeHuman|SomeHuman]] <span style="font-size:.87em;">2015-02-09 10:03&nbsp;(UTC<span style="font-size:87%">=CEST-2</span>)</span>
  +
::Op mijn Mac ( Chrome Browser ) zijn alle kaders rond de video's verdwenen en staan alle Youtube-video's onder elkaar. Dit in elk artikel. En pas na de recente Server-uitval. --[[Gebruiker:Gimycko|Gimycko]] 9 feb 2015 15:53 (UTC)
  +
:::Geen probleem met Mozilla. Even in IE willen aanloggen lukt weer niet. De domme wikisoftware wil dat ''van eenzelfde IP'' en ''andere browser'' '''apart''' ingelogd wordt maar gaat er dan opeens vanuit dat de sessie 'gehijacked' moet zijn en weigert het aanloggen. De wiki draait weer verschrikkelijk traag, dus begon ik niet af te loggen enz. want dan ben ik vannacht nog bezig. Ook bij Opslaan van dit hier, kreeg ik 4 x na telkens ruim 30 seconden een 'sessie gegevens verloren' en moest ik dus nogmaals Opslaan. "Als" dat niet lukt, zou ik moeten afloggen en opnieuw proberen. Vorig jaar ondervond ik in die gevallen, dat ik niet meer kan aanloggen. De kl*tesoftware heeft bij de eerste weigering waarschijnlijk de zogezegd hijackende IP of die gebruikersnaam als verdacht opgeslagen en weigert nu ook de originele browser vanaf dat IP met die gebruikersnaam. Idioot zijn doet niet zeer; jammer want dan raakte het mischien uitgeroeid. 2015-05-10 17:08 Belgische tijd lokaal als tekstbestand bewaard, tot ik kan aanloggen. Je ziet het wel wanneer dat gelukt is.<br>
  +
:::Dit hierboven was dus gisteren. Ik kan nog steeds niet inloggen, ook aanmaken van een nieuwe gebruiker geeft weigering. Rotwikibeveiliging. Ik gebruik nu even een omweg om zonder inloggen (en dus zonder gebruikersnaam) dat bericht te laten.<br />— [[Gebruiker:SomeHuman|SomeHuman]] [[Speciaal:Bijdragen/31.151.129.116|by proxy 31.151.129.116]] <span style="font-size:.87em;">2015-05-11 19:17-19:40&nbsp;(UTC<span style="font-size:87%">=CEST-2</span>)</span>
  +
:::Eindelijk gaat het hier opnieuw normaal, bijna. NavContent blijkt overal initieel uitgeklapt i.p.v. verborgen en de 'Mechelen Mapt'-banner die daarnet tegen 05:25&nbsp;(UTC<span style="font-size:87%">=CEST-2</span>) terug te zien was, bleek rond 05:30&nbsp;(UTC<span style="font-size:87%">=CEST-2</span>) opnieuw verdwenen. Wat later bleken ook die euvels weer (even?) opgelost.<br />— [[Gebruiker:SomeHuman|SomeHuman]] <span style="font-size:.87em;">2015-02-12 05:25/05:34/05:52&nbsp;(UTC<span style="font-size:87%">=CEST-2</span>)</span>
  +
:::Ik logde af en poogde dan vanuit een ander IP-adres een 'nieuwe gebruiker' te registreren. Eerst verscheen een nieuw soort 'captcha': men moet een puzzeltekening samenstellen. Weer een domme wijziging omdat die absoluut vereist dat Flash werkt, al zit dat bij mij wel goed. Bij 'Registreren' gebeurde er niets. Ik ging dan opnieuw naar de hoofdpagina en poogde het opnieuw... en er verscheen gewoon geen spoor van enige puzzel. Ditmaal gebeurde er wel iets bij 'Registreren': Een melding dat de puzzel niet goed is opgelost en ik het even opnieuw moet proberen. Kortom: Nieuwe gebruikers kunnen zich momenteel ''niet'' registreren. Tussendoor, ook bij pogingen om dit huidige berichtje op te slaan, verschijnt geregeld een 'File not found' op een overigens blanco pagina. Zut.<br />— [[Gebruiker:SomeHuman|SomeHuman]] [[Speciaal:Bijdragen/31.151.129.116|by proxy 31.151.129.116]] <span style="font-size:.87em;">2015-05-12 06:54-07:00&nbsp;(UTC<span style="font-size:87%">=CEST-2</span>)</span>
  +
<hr />
  +
Ook nu kan ik nog steeds niet aanmelden. Wat mij betreft is de wiki dus 100% om zeep.<br />— [[Gebruiker:SomeHuman|SomeHuman]] [[Speciaal:Bijdragen/31.151.129.116|by proxy 31.151.129.116]] <span style="font-size:.87em;">2015-05-13 16:17&nbsp;(UTC<span style="font-size:87%">=CEST-2</span>)</span>

Huidige versie van 13 feb 2015 om 16:18

Naarmate ik de pagina aanvulde, ondervond ik in progressief toenemende mate problemen bij het opslaan. Het visualiseren van mijn klaargemaakte versie, en het vergelijken ervan met de reeds bewaarde versie, verliep telkens vlot. De server kan dus zijn taken best aan. Maar wanneer 'Opslaan' geklikt wordt, begint daarop een ondertussen schier eindeloze procedure te draaien. Met veel geluk verschijnt dan na een aantal minuten eindelijk de eenvoudige controlesom. Daarna vergt het opslaan opnieuw een al minstens even lange wachttijd, na mijn laatste bijwerkingen zelfs oneindig. Slechts in een ander browservenster naar Mechelen Mapt gaan en er de bewerkingsgeschiedenis van opvragen (of de pagina zelf goed inspecteren) kon me geruststellen. Maar de wachttijd tot het controlesommetje verschijnt, bleek de laatste keren meestal onbeperkt. Mijn laatste klaargemaakte wijziging kostte me dan ongeveer vijf uren (300 minuten) gewoon om ze te kunnen opslaan (met driemaal gegevensverlies en dus opnieuw beginnen en opnieuw referenties opzoeken enz.). Ik moet dit dus opgeven, tenzij een oplossing voorhanden komt. Het probleem zit kennelijk bij een uitermate slecht geschreven routine om de externe links na te kijken, want een wijziging zonder nieuwe externe links opslaan, kan blijkbaar wel behoorlijk.

Uit die ervaring leid ik af dat die routine wellicht steeds alle externe links (meer bepaald de gelinkte url's) overloopt en misschien aan een vermoedelijk ellenlange zwarte lijst (en waarschijnlijk op een daartoe te traag opslagmedium) aftoetst. En dat nog eens opnieuw wanneer het controlesommetje ingevuld werd. Ik denk dat nu wel met de oude versie vergeleken wordt om te achterhalen of er nieuwe links zijn, maar zo ja onnodig alle links uit de nieuwe pagina aan de zwarte lijst afgetoetst worden. Een fatsoenlijke routine zou de url's van de externe links uit de laatst bewaarde pagina in een array in (snel) geheugen plaatsen en die uit de op te slagen versie daarmee vergelijken. In geval er externe links niet in die array gevonden worden wijl aangeboden zonder rekensommetje, wordt reeds bij vinding van de eerste zonder verder vergelijken en zonder zelfs die ene te controleren met de zwarte lijst, het eenvoudige sommetje vertoond. Zodra een pagina ter opslag wordt aangeboden samen met goed sommetje, wordt de array opnieuw aangemaakt (want het geheugen moest meteen vrijgekomen zijn omdat een gebruiker kan en een spambot zal moeten afhaken zonder op te slaan), de externe links uit de dan aangeboden (eventueel ondertussen door gebruiker nog verder gewijzigde) pagina ermee vergeleken, en dan uitsluitend die externe links (inzake. url's) welke nog niet in de array staan, (dus de nieuwe en automatisch ook de eventueel gewijzigde) gecontroleerd met de zwarte lijst. Dat gaat ontzettend veel sneller, met een minimum aan serverbelasting.

Er zijn dus slechts drie eventuele mogelijkheden om verder te kunnen werken:

  • Iemand schrijft een fatsoenlijke routine. Vandaag. ;-)
  • Een sysop schakelt de controlefunctie uit voor deze specifieke pagina. Ze wordt dan best zo nu en dan eens terug ingeschakeld (zo nodig door copy naar clipboard van de laatste pagina, vanuit 'geschiedenis' bewerken van de laatste reeds gecontroleerde versie en die opslaan, inschakelen van controle, bewerken door alles te selecteren en het clipboard in de plaats te pasten, en dan op te slaan (op een moment dat de server weinig belast is), dag-tijd noteren om te weten naar welke versie men bij volgende gelegenheid moet terugkeren, de controle opnieuw uit schakelen.
  • Indien men de controlefunctie niet zou kunnen uitschakelen slechts voor een specifieke pagina, geeft men mij de nodige sysop-bevoegdheid om de controle op site-niveau uit te schakelen. Ik doe dat dan net voor ik wil opslaan, en herstel de controlefunctie meteen erna. Ik zal wel in staat blijken om ongewenste links te vermijden. Dit lost het probleem niet op voor andere gebruikers, maar er staan er niet veel te dringen. Dat laatste beperkt ook de kans dat iemand net een pagina met nieuwe externe links zou opslaan gedurende de enige minuten dat de beveiliging zou uitgeschakeld zijn. In elk geval bekijk ik de recente wijzigingen (link in linkerkolom) en als toch eens iemand net gewerkt heeft, kijk ik die bijdrage wel even na.

Graag een reactie, — SomeHuman 2012-07-14 19:22-21:50 (UTC=CEST-2)

Extra tip: Nadat bovenstaande verbeterde routine zou tot stand gekomen zijn, kan de tijd om de met goede rekensom aangeboden nieuwe url's aan de zwarte lijst te toetsen, nog verkort worden door die laatste geregeld op te kuisen: Een procedure kan enkele weken na mekaar elke url eruit pingen en mits respons die in een de eerste week nieuw aangemaakt bestand wegschrijven. Na drie weken vervangt dat bestand de oudere zwarte lijst. Die is daardoor niet meer nutteloos dermate ellenlang. Om de paar maanden wordt deze procedure dan best herhaald.

Het euvel kan ook verklaard worden als de zwarte lijst nu reeds als één grote brok in een geheugenarray geladen wordt, maar dermate lang geworden is dat de server er problemen door krijgt. De 'extra tip' kan dan een oplossing bieden, hoewel eigenlijk best de zwarte lijst in handelbare kleinere brokken wordt in geheugen gelezen en al de nieuwe url's van de array der op te slagen pagina ermee wordt geverifieerd; dan wordt de zwarte-lijst-array vrijgemaakt voor de volgende handelbare brok, enz. tot uiteindelijk de hele zwarte lijst doorploegd geraakt is.
SomeHuman 2012-07-14 22:10-22:34 (UTC=CEST-2)

Als je zeker weet dat die controlesom (een van de oorzaken) de oorzaak van het probleem is, dan zal ik dit melden aan de eigenlijke sysop/serverbeheerder die de php scripts beheert. Onze server staat in Canada en wordt er verniet beheerd. Ik zal zeker nadenken of ik je tot admin zal maken (we zijn met niet veel en je kent ook vrij goed het wikisysteem). Stuur een e-mail naar [email protected] als je mij persoonlijk wil contacteren | Cartoonist | Contact | 20 jul 2012 12:28 (UTC)
Noot: Verdere correspondentie verliep per e-mail. — SomeHuman 2012-08-28 08:44 (UTC=CEST-2)

Spamfilter[bewerken]

Bij bewerking van A.B.-straat wou ik nog externe links toevoegen: foto's van Karel Somers (waarvan er ook een reeks op de site staan en in de galerij van het artikel getoond worden). Maar deze staan op Flickr, een ervan met een interessant commentaar van de fotograaf. Enkele keren 'ter controle bekijken', alles prima. Pagina opslaan. Blaf! spamfilter: www.flickr.com (blacklisted by l1.apews.org.) [kleine L cijfer 1]. Geen weg terug. Alle werk vergeefs. Gelukkig was dit nu maar een kwartiertje. Maar het wil wel zeggen dat als iemand ooit een halve dag schitterend werk voorbereid en het ongeluk heeft dat tussen al die fantastische inhoud bijvoorbeeld als bronvermelding (zoals dat commentaar van Karel Somers) één ( 1 ) url staat die iemand om wat voor (afgaande op mijn ervaring, wellicht geen goede) reden ook onwenselijk achtte, alles onherroepelijk verloren is. Ik vind het absoluut onverantwoord. Men zou altijd moeten terugkeren naar het bewerkingsvenster zodat men die url of alleen "http://" er uit kan halen en al het andere opslaan. Daarna zou men in de overlegpagina moeten kunnen vragen dat een sysop die url toevoegt (spamfilter override). Vervelend is dat ik (ook sysoppeke) niet weet of/hoe we dat kunnen.
SomeHuman 2012-08-28 08:44 (UTC=CEST-2)

@CartoonistHenning: Dit sysoppeke zag wat je gisteren gedaan hebt. A.B.-straat kreeg veel meer 'Flickr'-links dan ik me vanochtend voornam. Als een weigering van een url nu nog zou terugkeren naar het laatste bewerkingsscherm... Je oplossing is prima indien de spamfilter veel te streng is, maar niet vergelijkbaar met een 'spamfilter override' (voor een complete url) als sysop-bevoegdheid: elkeen kan nu tewerk gaan als ik in A.B.-straat. Die methode kan dus best niet voor gelijk welk domein gebruikt worden. In elk geval, zeer bedankt!
SomeHuman 2012-08-29 01:59-02:10 (UTC=CEST-2)
Ik dacht eerder te antwoorden, maar zag nog 't een en 't ander staan. Ik heb geen idee of die whitelist werkt, voor de bevestiging heb ik Carl een e-mail gestuurd (met ook een req om een uitzonderingsregel te maken in de software op hetgeen Apews blokkeert). In ieder geval is dit probleem uniek: ik ben het nergens anders tegengekomen. Voor alle zekerheid heb ik nog die interwiki gemaakt.
Nu nog zien of dat bericht waarover sprake te vinden is in de systeembestanden, zoniet kan ik het niet aanpassen. Helpt de terug-knop in je browser dan niet? Ik werk momenteel met Firefox en daar ondervind ik geen verlies van tekst. In Internet Explorer weet ik dat de terug-knop bijna een volledige refresh van de pagina doet | Cartoonist | Contact | 29 aug 2012 02:19 (UTC)
Ik werkte inderdaad in IE9. Bij het eerste probleem dat op dit forum gesignaleerd werd, lukte het soms om met de 'terug'-knop mijn bewerkingsscherm met laatste gegevens terug te vinden, soms kreeg ik spijtig genoeg het bewerkingsvenster met de in den beginne opgeslagen pagina (en dan kon niets meer baten), soms echter verschijnt een venstertje dat iets stelt als 'gegevens zijn verlopen, opnieuw doorsturen?' en als men dat doet is ofwel meteen de laatst voorbereide bewerking daar, ofwel alle redding ondenkbaar, soms lukte merkwaardig genoeg een 'refresh' om de laatste bewerking terug te vinden, soms rechtermuisklik op 'terug' en in de lijst de voorlaatste 'ter controle bekijken' klikken om die bewerking gaaf terug te krijgen (dikwijls kan men zich de enkele aanpassingen die sindsdien gebeurden vlot herinneren en gewoon even intikken), in dat laatste geval kan echter ook voor één of elke gekozen bewerkingsversie 'gegevens zijn verlopen, opnieuw doorsturen?' verschijnen (gevolgen als beschreven en als het eens mislukt gaat het zeker niet met een andere versie kunnen lukken), maar in de meeste gevallen slaagde geen enkele methode: van voor af aan alles opnieuw (trachten) te doen... Ik kon nooit achterhalen wat nu precies bepaalde of ik iets ging kunnen terughalen en zo ja op welke wijze; allicht spelen de verlopen tijdsduur en wat de wikiserver ondertussen eventueel communiceerde met de client PC een rol, bovendien hangt de browser cache toestand van nog meer dingen af.
Het nieuwe euvel deed me alles verliezen: de eerste keer poogde ik de 'terug' en een tweede keer (met 1 url als test) was 'refresh' nutteloos. Ook een link die in het spamrapportvenster verscheen (zoiets als 'terug' of 'A.B-straat') bracht me slechts naar de artikelpagina, zelfs geen bewerkingsscherm; dan uit de 'terug'-lijst een 'ter controle bekijken'-bewerking kiezen, gaf ongelukkiglijk het bewerkingsscherm met de opgeslagen pagina. Ik zag nooit eerder een gelijkvormige spamfilterboodschap, ook niet op andere MediaWikis.
SomeHuman 2012-08-29 02:50-02:55-06:55 (UTC=CEST-2)

Opnieuw blijkt het spamfilter een wellicht bonafide site te blokkeren: Marc Alcide bij de Sempse (heemkundige kring van Zemst) publiceerde op alcide[dot]tripod[dot]com dat door hetzelfde l1.apews.org geblacklist is en de whitelist blijkt opnieuw niets uit te halen. Opnieuw werd dus een interwiki voor dit oneigenlijk doel aangemaakt. Gelukkig gebruikte ik nu Firefox zodat ik van mijn voorbereide bewerking niets kwijt was geraakt.
SomeHuman 2013-02-02 15:31 (UTC=CEST-2)

Geschiedenis: versies vergelijken[bewerken]

Sinds vannochtend ondervond ik een bizar en gans nieuw euvel: het blijkt onmogelijk om in 'geschiedenis' versies te vergelijken: Titel 'Ongeldige doelversie' verschijnt in wat een pagina lijkt hoewel de tabs erboven nog steeds het artikel of de overlegpagina betreffen waarvan de versiesvergelijking gevraagd werd. De tekst stelt "U hebt geen doelversie(s) voor deze handeling opgegeven, de aangegeven versie bestaat niet of u probeert de laatste versie te verbergen." en dat is onzin. Waar staat de procedure die de vergelijking sinds zeer onlangs foutief verwerkt, werd er iets nogal onhandig gewijzigd?
SomeHuman 2012-08-28 22:30 (UTC=CEST-2)

Vreemd. Ben ik nog niet tegengekomen. Was dit toevallig bij het vergelijken van een verborgen/gedeletede versie? Ik heb dit namelijk gegoogled en kwam uit op wp:MediaWiki:Revdelete-nooldid-text. Cartoonist | Contact | 29 aug 2012 02:28 (UTC)
Niks 'deleted': Daarstraks in gewone artikels. En nu bovenaan deze Forumoverlegpagina tab 'geschiedenis' klikken, niets wijzigen aan automatisch gepreselecteerde 'radio buttons' bij voorlaatste en laatste versie, simpel op 'aangevinkte versies vergelijken'... daar was ie weer. Ik poogde het ook vergeefs met de 'checkbox'-jes naast die 'radio buttons' aangevinkt (zoals de knop eigenlijk zegt). Altijd en overal, ook nergens oude onderling, of oude met recente vergelijken. Ik kan doodgewoon niets vergelijken op deze wiki. Alles gaat heel normaal zoals tot gisterennacht hier, zopas op de nl Wikipedia (waar er geen aanvinkbare 'checkbox' naast de 'radio buttons' staat en de tekst op de knop ook niet de term 'aanvinken' gebruikt). Ik krijg er kop noch staart aan. Kan jij nog steeds normaal vergelijken?
SomeHuman 2012-08-29 03:17 (UTC=CEST-2)
P.S. Op de nl Wikipedia ben ik geen sysop. Alhier op MM met die checkboxjes echt aangevinkt, kwam ik met die 'aangevinkte versies vergelijken'-knop wel in het scherm "Versies verwijderen/terugplaatsen". Daar kan ik de 'wijz' openen en dus de laatste wijziging bekijken, die truuk gebruikte ik daarstraks om te zien welke (uitstekende) bewerking Gimycko na mij in 'Sint-Katelijnestraat' had uitgevoerd. Eens in die vergelijkingspagina kan ik wel 'terugwandelen'. Maar versies vergelijken met tussenliggende versies overgeslagen, is er helemaal niet bij.
SomeHuman 2012-08-29 03:28 (UTC=CEST-2)
Je MediaWikilink: Bericht 'pagina bestaat niet meer' en opgegeven reden, maar toch nog steeds inhoud met identiek de tekst die ik hier te zien krijg, lijkt erop te wijzen dat in lang vervlogen tijden nog geen 'radio buttons' in elke kolom gepreselecteerd werden: sindsdien is het daarmee namelijk onmogelijk om geen doelversie te selecteren.
SomeHuman 2012-08-29 03:52 (UTC=CEST-2)
Ik kan wel normaal in de geschiedenis versies vergelijken. Ik heb dus echt geen enkel idee wat dit zou kunnen betekenen. Zou je misschien screenshots kunnen uploaden van de stappen die achtereenvolgens doet? Cartoonist | Contact | 29 aug 2012 09:47 (UTC)
Niets anders dan altijd normaal was. Ik ontdekte zopas dat ik heel normaal versies kan vergelijken zodra ik aflog. Als ik daarna opnieuw aanlog, is het meteen opnieuw hopeloos. Tot voor een paar dagen vergeleek ik ook ingelogd alles heel normaal. 't Is echt vervelend nu.
SomeHuman 2012-08-29 18:36 (UTC=CEST-2)
Ik meen niets gewijzigd te hebben in mijn 'voorkeuren', maar checkte die nu toch even: Standaard een extern vergelijkingsprogramma gebruiken (alleen voor experts - voor deze functie zijn speciale instellingen nodig): nooit aangevinkt; Uitgebreide Recente Wijzigingen-pagina gebruiken (vereist JavaScript) : nu uitgevinkt, opgeslagen, uitgelogd, ingelogd, uitgeprobeerd zonder verbetering, terug aangevinkt, opgeslagen; in tab 'Verschillen' bleven de beide opties uitgevinkt. Browserinstellingen of zo waren ook niet gewijzigd.
(Vergelijking van tijdens 'bewerken' voorbereide versie met de opgeslagen versie, bleef steeds normaal.)
SomeHuman 2012-08-29 18:54-19:09 (UTC=CEST-2)
Het euvel doet zich (nog steeds) alleen in IE voor. In Firefox en Opera gaat alles heel normaal.
SomeHuman 2012-08-31 10:23 (UTC=CEST-2)

Geen tab 'bewerken'[bewerken]

Sjabloon:Noedit heeft bovenaan geen tab 'bewerken'. Waar men die verwacht, staat 'geschiedenis'. Hoe kan men dan wijzigingen aanbrengen? Klik 'geschiedenis' en zodra je die inderdaad ziet, klik je 'bewerken': Je bewerkt dan niet de geschiedenis maar wel het sjabloon. Simpel, maar men moet het weten. Dan ziet men ook de display:none die wellicht het euvel veroorzaakt, al weet ik niet hoe de software precies bepaalt welke tabs getoond moeten worden.
SomeHuman 2013-05-23 01:49 (UTC=CEST-2)

Op MM (en alle wiki's trouwens) bestaan er handige shortcuts. Ik gebruik ze vaak. Bewerken is bijvoorbeeld Alt + Shift + E of je typt in de url http://mechelen.mapt.be/index.php?title=Artikeltitel&action=edit. Nog een manier is in je instellingen > bewerken "dubbelklikken voor bewerken" aanvinken, maar persoonlijk vind ik dat irritant. In het sjabloon zelf zette ik een eenvoudige includeonly-tag die aangeeft dat de inhoud ertussen alleen bestemd is voor de pagina's die het sjabloon opvragen | Cartoonist | Contact | 23 mei 2013 23:39 (UTC)
Shortcuts dienen om een schitterend ontworpen systeem voor mensen met drie handen aan ons, tweehandige gehandicapten, aan te passen. Vermits ik constant een laptop benut, gebruik ik zeer weinig shortcuts (Ctrl-C, Ctrl-V en soms Ctrl-F5, dat is het zo ongeveer): de duimen rusten als het ware op het touchpad (en de knoppen) wijl mijn vingers over het klavier hun werk doen. Dat gaat dus veel vlotter dan met een muis en een uitgebreide batterij gememoriseerde shortcuts. Ik gebruikte vele jarenlang beide systemen (werk / thuis) maar ben ondertussen de meeste shortcuts met plezier vergeten, en die van MM zocht ik (voor mij) vanzelfsprekend nooit op.
Het dubbelklikken is dan weer nog minder interessant bij gebruik van een touchpad, dat ook een tik als een klik aanvaardt. Dat is instelbaar, en handig voor een enkele klik maar het gevaar ongewild te dubbeltikken i.p.v. bedoeld 'klik + beweeg cursor' is niet geheel onbestaande, dus aan het dubbelklikken mag best geen potentieel groot gevolg ingesteld worden.
Bij het categoriseren van sjablonen dacht ik al eerder nog een ander sjabloon met dat probleem opgemerkt te hebben, maar vond het achteraf toch niet terug. Misschien zette ik er zonder veel nadenken (bandwerk) ook al een 'includeonly' in terwijl ik een 'noinclude' plaatste met de categorie erin.
SomeHuman 2013-05-24 02:40-02:50 (UTC=CEST-2)

Aanmelden en registreren onmogelijk[bewerken]

Het volgende werd van een overlegpagina van het artikel KRC Mechelen naar hier gekopieerd:


Wat is er loos met de video-rangschikking, want na de server-uitval lijkt de line-up verdwenen ? --Gimycko 8 feb 2015 19:13 (UTC)

Hoezo? Ik zie niets abnormaal, tenzij een wat lange wachttijd vooraleer Rik "(1 van 7)" (nochtans slechts 1 filmlink) verschijnt.
SomeHuman 2015-02-09 09:56 (UTC=CEST-2)
Ik haalde die "Rik, de Racinger (deel 1 van 7)" zopas weg, want bij afspelen verscheen slechts "This video is private". So be it.
SomeHuman 2015-02-09 10:03 (UTC=CEST-2)
Op mijn Mac ( Chrome Browser ) zijn alle kaders rond de video's verdwenen en staan alle Youtube-video's onder elkaar. Dit in elk artikel. En pas na de recente Server-uitval. --Gimycko 9 feb 2015 15:53 (UTC)
Geen probleem met Mozilla. Even in IE willen aanloggen lukt weer niet. De domme wikisoftware wil dat van eenzelfde IP en andere browser apart ingelogd wordt maar gaat er dan opeens vanuit dat de sessie 'gehijacked' moet zijn en weigert het aanloggen. De wiki draait weer verschrikkelijk traag, dus begon ik niet af te loggen enz. want dan ben ik vannacht nog bezig. Ook bij Opslaan van dit hier, kreeg ik 4 x na telkens ruim 30 seconden een 'sessie gegevens verloren' en moest ik dus nogmaals Opslaan. "Als" dat niet lukt, zou ik moeten afloggen en opnieuw proberen. Vorig jaar ondervond ik in die gevallen, dat ik niet meer kan aanloggen. De kl*tesoftware heeft bij de eerste weigering waarschijnlijk de zogezegd hijackende IP of die gebruikersnaam als verdacht opgeslagen en weigert nu ook de originele browser vanaf dat IP met die gebruikersnaam. Idioot zijn doet niet zeer; jammer want dan raakte het mischien uitgeroeid. 2015-05-10 17:08 Belgische tijd lokaal als tekstbestand bewaard, tot ik kan aanloggen. Je ziet het wel wanneer dat gelukt is.
Dit hierboven was dus gisteren. Ik kan nog steeds niet inloggen, ook aanmaken van een nieuwe gebruiker geeft weigering. Rotwikibeveiliging. Ik gebruik nu even een omweg om zonder inloggen (en dus zonder gebruikersnaam) dat bericht te laten.
SomeHuman by proxy 31.151.129.116 2015-05-11 19:17-19:40 (UTC=CEST-2)
Eindelijk gaat het hier opnieuw normaal, bijna. NavContent blijkt overal initieel uitgeklapt i.p.v. verborgen en de 'Mechelen Mapt'-banner die daarnet tegen 05:25 (UTC=CEST-2) terug te zien was, bleek rond 05:30 (UTC=CEST-2) opnieuw verdwenen. Wat later bleken ook die euvels weer (even?) opgelost.
SomeHuman 2015-02-12 05:25/05:34/05:52 (UTC=CEST-2)
Ik logde af en poogde dan vanuit een ander IP-adres een 'nieuwe gebruiker' te registreren. Eerst verscheen een nieuw soort 'captcha': men moet een puzzeltekening samenstellen. Weer een domme wijziging omdat die absoluut vereist dat Flash werkt, al zit dat bij mij wel goed. Bij 'Registreren' gebeurde er niets. Ik ging dan opnieuw naar de hoofdpagina en poogde het opnieuw... en er verscheen gewoon geen spoor van enige puzzel. Ditmaal gebeurde er wel iets bij 'Registreren': Een melding dat de puzzel niet goed is opgelost en ik het even opnieuw moet proberen. Kortom: Nieuwe gebruikers kunnen zich momenteel niet registreren. Tussendoor, ook bij pogingen om dit huidige berichtje op te slaan, verschijnt geregeld een 'File not found' op een overigens blanco pagina. Zut.
SomeHuman by proxy 31.151.129.116 2015-05-12 06:54-07:00 (UTC=CEST-2)

Ook nu kan ik nog steeds niet aanmelden. Wat mij betreft is de wiki dus 100% om zeep.
SomeHuman by proxy 31.151.129.116 2015-05-13 16:17 (UTC=CEST-2)