Bug/feature? FP reactie edit werkt niet (?)

[ehtweak]

Het volgende issue:

Ik plaats een reactie bij een FP nieuwsartikel:
ehtweak in 'nieuws: Amazon.de test betalen via iDeal'
gaat prima, pas 'm nog een keertje aan om wat spelfoutjes te verbeteren, wat zinnen aan te passen, e.d. Klik op "Wijzig reactie" en mijn wijziging wordt opgeslagen en de timestamp onderaan het bericht wordt aangepast met "[Reactie gewijzigd door ehtweak op 1 november 2017 12:26]"

Alleen, nu komt het vreemde, ff later reageert iemand op mijn bericht en vervolgens zie ik nog een tikfoutje. Ik open mijn eigen bericht weer, edit wat, klik wederom op "Wijzig reactie" en het scherm keert weer terug naar het oorspronkelijk bericht, maar ZONDER dat de wijziging te zien is?!? Maar wel wordt de zin "[Reactie gewijzigd door ehtweak op 1 november 2017 hh:mm]" geupdate.
M.a.w. volgens het vermelde tijdstip zou mijn reactie aangepast zijn, maar in werkelijkheid is 'ie dat niet!

Is dat een bug of een feature?

En ja, ik heb ondertussen al eens de browser cache gecleared, pagina opnieuw geopend, etc. Maar tekstuele wijzigingen worden, zo te zien, niet opgeslagen, maar de timestamp wordt wel aangepast...

[ Voor 8% gewijzigd door ehtweak op 01-11-2017 12:33 ]

[Zvennn]

Ervaar je dit probleem nog steeds?

[ehtweak]

@Zvennn JA!
Zojuist nog geprobeerd.
En nog vreemder; als ik op 'Wijzig' klik, krijg ik wel het edit venster te zien, met mijn al eerder (!) toegevoegde tekst, maar het wordt gewoonweg niet opgeslagen/verwerkt.

How comes?

[crisp]

Dan wordt waarschijnlijk de ongeparsede versie wel opgeslagen, maar de geparsede niet

[ehtweak]

crisp schreef op woensdag 1 november 2017 @ 15:33:
ongeparsede

QUE?

En hoe/wat moet ik/jullie dan wel parsen (is dat een nederlands werkwoord??????)

[crisp]

ehtweak schreef op woensdag 1 november 2017 @ 15:36:
[...]

QUE?

En hoe/wat moet ik/jullie dan wel parsen (is dat een nederlands werkwoord??????)

We slaan 2 versies op van het bericht; eentje met de ubb/rml code zoals je hem intypt, en de HTML versie daarvan. Dat kan het gedrag dat jij waarneemt verklaren. Verder is dat vooral van belang voor de devver die dit gaat fixen (not me want ik ben vrij vanmiddag )

[Zvennn]

Ik heb er een ticket voor aangemaakt. Bedankt voor het doorgeven. We gaan het fixen

[crisp]

Dan moeten we het wel kunnen reproduceren. Bij mij werkt editten van reacties gewoon op de frontpage...

[ehtweak]

De reden waarom ik vroeg of het een bug of een feature was:

Ik zou me namelijk kunnen voorstellen dat je je bericht niet meer kunt wijzigen, als er eenmaal op gereageerd is. Want dan zou je aan 'geschiedvervalsing' kunnen doen.

Maar dan nog hoort niet de timestamp van je laatste edit mee te wijzigen, net alsof je wel wat gewijzigd zou hebben...

net ff getest, en bij dit bericht:
ehtweak in 'nieuws: Amazon.de test betalen via iDeal'
wat gewijzigd. En die wijziging wordt wel getoond.

Maar m'n oorspronkelijke bericht:
ehtweak in 'nieuws: Amazon.de test betalen via iDeal'
kan ik wijzigen wat ik wil, maar ik zie NIET de tekstuele wijziging, maar wel dat de timestamp wordt aangepast... (?)

[ Voor 47% gewijzigd door ehtweak op 01-11-2017 20:25 ]

[crisp]

@ehtweak het is een probleem in je opmaak:

code:

[list]
  [li]...[/li]
  Maar ook sommige onderdelen of [willekeurig ander artikel] willen ze niet versturen naar een NL adres. :? 
  [li]...[/li]
[/list]

content binnen een list die niet in li-tags staat wordt genegeerd

en de parser snapt het in code-tags ook niet helemaal

[ Voor 10% gewijzigd door crisp op 01-11-2017 20:34 ]

[ehtweak]

Probleem in mijn opmaak, of snapt de parser z'n eigen code niet?

Want ik gebruik slechts de functionaliteit die wordt aangeboden...

[crisp]

ehtweak schreef op woensdag 1 november 2017 @ 20:36:
Probleem in mijn opmaak, of snapt de parser z'n eigen code niet?

Want ik gebruik slechts de functionaliteit die wordt aangeboden...

Je hebt op zeker moment de tekst "Maar ook sommige onderdelen of [willekeurig ander artikel] willen ze niet versturen naar een NL adres. " toegevoegd, maar buiten de context van de li-tags (dus feitelijk direct binnen het list-element). Dat zondermeer parsen naar HTML zou ongeldige HTML opleveren, dus wordt die content genegeerd...

[ehtweak]

Whatever; maar ik tik niet in html, ik gebruik de aangeboden editor en de daarin aanwezige opmaakelementen. Blijkbaar zijn die niet user-hufter-proof.... en/of krijg je geen melding dat je iets doet wat (blijkbaar?) niet zou kunnen...

[ Voor 20% gewijzigd door ehtweak op 01-11-2017 21:36 ]

[crisp]

ehtweak schreef op woensdag 1 november 2017 @ 21:35:
Whatever; maar ik tik niet in html, ik gebruik de aangeboden editor en de daarin aanwezige opmaakelementen. Blijkbaar zijn die niet user-hufter-proof.... en/of krijg je geen melding dat je iets doet wat (blijkbaar?) niet zou kunnen...

tsja, parsers zijn vaak ook maar dom

[ehtweak]

@heren devvers: begrijp ik hieruit dat het geen kever is, maar een 'feature' van de aangeboden editor dat in het onderhavige geval, niet voorziene gebruikersgedragingen, tot doe-maar-net-alsof-het-niet-gebeurd reacties, van de ontleder leiden?

[crisp]

ehtweak schreef op donderdag 2 november 2017 @ 09:28:
@heren devvers: begrijp ik hieruit dat het geen kever is, maar een 'feature' van de aangeboden editor dat in het onderhavige geval, niet voorziene gebruikersgedragingen, tot doe-maar-net-alsof-het-niet-gebeurd reacties, van de ontleder leiden?

Zoiets ja Het is dus op te lossen door te zorgen dat je die toegevoegde tekst ook binnen de [li]...[/li] plaatst in plaats van daarbuiten.

Ik heb wel een notitie gemaakt om eens te kijken of we dat op een nettere manier op kunnen lossen waarbij er geen content 'verloren' gaat

[crisp]

Dat laatste heb ik in de nieuwe parser die in ontwikkeling is inmiddels doorgevoerd