Polls werken al maanden niet

phpBB heeft dit al ingebouwd sinds 2000 of zo. Misschien tijd voor een upgrade?!

* Ample Energy rent snel weg.

Dit forum heeft ook een poll-functie, echter enkel voor crewleden.
Maar ik zou het wel tof vinden als er een forumbrede poll-functie kwam.

Maar het probleem is dat de afbeelding gecached wordt. In het verleden kon dit worden uitgesloten van de cache. maar nu wordt het dus (weer) gecached.

[ Voor 14% gewijzigd door AW_Bos op 07-09-2026 01:46 ]

Ik kan hier zelf als developer niet zoveel mee, gezien het sec gezien geen bug is. Ik gooi hem dus even over de schutting vraag mijn lieve collega's van MF om hier naar te kijken

Hoezo is dit eigenlijk geen bug? Het heeft wel goed gewerkt, maar tegenwoordig niet meer.

Anders moeten we toch op een manier kunnen afdwingen dat Camo een afbeelding gaat cachen?

En als de devvers van Tweakers dit geen bugv vinden. Wat is dan de beste oplossing om een poll te plaatsen in een topic?

[ Voor 59% gewijzigd door AW_Bos op 07-09-2026 18:02 ]

AW_Bos schreef op maandag 7 september 2026 @ 18:00:
Hoezo is dit eigenlijk geen bug? Het heeft wel goed gewerkt, maar tegenwoordig niet meer.

Anders moeten we toch op een manier kunnen afdwingen dat Camo een afbeelding gaat cachen?

Een goed werkende website is tegenwoordig een mooie feature kennelijk...

AW_Bos schreef op maandag 7 september 2026 @ 18:00:
Hoezo is dit eigenlijk geen bug? Het heeft wel goed gewerkt, maar tegenwoordig niet meer.

Anders moeten we toch op een manier kunnen afdwingen dat Camo een afbeelding gaat cachen?

En als de devvers van Tweakers dit geen bugv vinden. Wat is dan de beste oplossing om een poll te plaatsen in een topic?

Het is een externe tool vziw, die heeft caching ingebouwd omdat het anders wel heel veel geld gaat kosten

AW_Bos schreef op maandag 7 september 2026 @ 18:00:

Anders moeten we toch op een manier kunnen afdwingen dat Camo een afbeelding gaat cachen?

het probleem is juist dat dit serverside steeds veranderende plaatje hier wordt gecached. Een omweg is dan ook linken naar https://poll.dezeserver.nl/results.cgi?pid=407750&layout=2&sort=prc

AW_Bos schreef op maandag 7 september 2026 @ 18:00:

En als de devvers van Tweakers dit geen bugv vinden. Wat is dan de beste oplossing om een poll te plaatsen in een topic?

J&J poll op een forum zonder poll-functionaliteit:

• maak een aantal topics aan: topicNaam_pollOptie1/2/3/etc
• wijs mensen er in elk van de topics op dat het deel van een set is
• leg in elk topic de verschillende pollOpties uit, toon duidelijk de actieve en overige opties
• vraag mensen om een + te geven aan één van pollTopics in de set
• verzamel na periode x de plusjes per pollOptie

418O2 schreef op maandag 7 september 2026 @ 18:22:
[...]

Het is een externe tool vziw, die heeft caching ingebouwd omdat het anders wel heel veel geld gaat kosten

Die tool heeft geen caching, dat doet Tweakers.

Dit hieronder is zo'n een poll.
Je ziet in de HTML-source / Inspector-tool dat de afbeelding naar deze URL gaat:

https://tweakers.net/camo/SleB-TYiTn5UjJ7OHj935L1ZQpc/?url=https%3A%2F%2Fpoll.dezeserver.nl%2Fresults.cgi%3Fpid%3D407753%26layout%3D1%26sort%3Dprc

i.p.v. https://poll.dezeserver.nl/results.cgi?pid=407753&layout=1&sort=prc

Dus ergens lijkt de parser dus de afbeelding door Camo te halen.
Maar waarom dan eigenlijk? Kan er geen override komen dit niet via camo in te laden?

---

Poll: test polletje?
• Ja
• Nee
<sup>Tussenstand:

Ook een poll maken? Klik hier</sup>

[ Voor 26% gewijzigd door AW_Bos op 07-09-2026 19:06 ]

G_Dragon schreef op maandag 7 september 2026 @ 19:18:
Ik heb gestemd op nee als test

Als je de afbeelding als losse link opent (dus niet via Tweakers), dan zie je de telling:
https://poll.dezeserver.n...=407753&layout=1&sort=prc

Niet handig dus

[ Voor 3% gewijzigd door AW_Bos op 07-09-2026 20:06 ]

Misschien kan Tweakers een [img,cache=0] attribuut toevoegen voor dit soort doeleinden?

Heb er niet voor doorgeleerd, maar kwam dit laatst tegen toen ik in een ander topic las en er eens naar gezocht heb: https://github.com/orgs/c...iscussioncomment-14979580

Neem aan dat het dan wel op de poll server moet komen en niet bij Tweakers. Maar dan nog geen garantie, mogelijk override de implementatie van Tweakers het alsnog?

LXXI schreef op maandag 7 september 2026 @ 19:37:
Neem aan dat het dan wel op de poll server moet komen en niet bij Tweakers. Maar dan nog geen garantie, mogelijk override de implementatie van Tweakers het alsnog?

Cache-Control headers worden door de caching laag ook genegeerd helaas.

Ik heb een eigen versie van de Polls gemaakt en die heeft ook last van caching:



Geef een antwoord:
• Gathering of Tweakers
• Pricewatch
• Frontpage
• Vraag & Aanbod
• Reviews

LXXI schreef op maandag 7 september 2026 @ 19:37:
Heb er niet voor doorgeleerd, maar kwam dit laatst tegen toen ik in een ander topic las en er eens naar gezocht heb: https://github.com/orgs/c...iscussioncomment-14979580

Neem aan dat het dan wel op de poll server moet komen en niet bij Tweakers. Maar dan nog geen garantie, mogelijk override de implementatie van Tweakers het alsnog?

Ik heb geen idee of Tweakers voor het camo-proces kijkt naar de headers van de server.

[ Voor 7% gewijzigd door AW_Bos op 07-09-2026 20:08 ]

AW_Bos schreef op maandag 7 september 2026 @ 20:07:
[...]

Dit staat los van Bootz poll-server.

Ja en nee zoals ik het lees. Als bij het plaatje wordt aangegeven dat het niet in de cache mag zou het zo te zien moeten werken. Maar blijkbaar negeert Tweakers dat soort headers en dat is zoals ik het begrijp in die link een keuze om dat te doen.

Maar zoals gezegd, ik heb voor wat anders doorgeleerd dus ik kan er kilometers naast zitten.

Edit: niet stiekem een edit doen hè.

[ Voor 4% gewijzigd door LXXI op 07-09-2026 20:10 ]

AW_Bos schreef op maandag 7 september 2026 @ 20:07:
Ik heb geen idee of Tweakers voor het camo-proces kijkt naar de headers van de server.

Het antwoord lijkt dus nee, want op mijn eigen poll plaatje zet ik zowat alle gangbare anti-cache headers en het plaatje wordt nog steeds gecached

Ik heb ook maar eens een anti-cache header aan de plaatjes toegevoegd. Maar als de cache-laag besluit om die headers te negeren, dan is er verder ook niks wat ik daar nog aan kan doen helaas.

Overigens heeft het poll-script zelf ook wel een cache, zodat niet elke keer de plaatjes opnieuw gegenereerd hoeven te worden (scheelt CPU-load op de server). Maar omdat ik die cache zelf bijhoudt kan ik die ook invalidaten zodra er gestemd wordt, zodat de plaatjes altijd up-to-date zijn.

Ik vind het idee van CyBeRSPiN hierboven om de [img]-tag uit te breiden met een nocache-optie wel aardig, maar ik kan me ook wel voorstellen dat er goede redenen zijn om dat niet te doen.

BOOTZ schreef op dinsdag 8 september 2026 @ 13:56:


Ik vind het idee van CyBeRSPiN hierboven om de [img]-tag uit te breiden met een nocache-optie wel aardig, maar ik kan me ook wel voorstellen dat er goede redenen zijn om dat niet te doen.

Dit is ook de enige usecase waarin het handig zou kunnen zijn, althans, ik kan weinig anders bedenken

DaFeliX schreef op maandag 7 september 2026 @ 16:19:
Ik kan hier zelf als developer niet zoveel mee, gezien het sec gezien geen bug is. Ik gooi hem dus even over de schutting vraag mijn lieve collega's van MF om hier naar te kijken

Het lijkt me wel nuttig om een conclusie te hebben over dit fenomeen en één van onderstaande (beleids)scenario's is hier denk ik van toepassing:

Scenario 1:
Tweakers "camo" zal per image URL exact 1 lokale versie/cache bijhouden en deze is nooit meer veranderbaar "by design". Hoofdreden is dat mensen achteraf niet stiekem een ander plaatje uploaden en zo de discussie kunnen beïnvloeden. Past in het beleid dat je na twee weken je post niet meer mag aanpassen. Dynamische plaatjes met bijvoorbeeld polls zijn dan slachtoffer van deze keuze en het poll "probleem" blijft hierbij onoplosbaar.

Scenario 2:
Tweakers "camo" is bedacht met het idee dat plaatjes nog wel eens kapot willen gaan op het forum doordat de externe URL van het plaatje niet meer werkt. Door een versie van het plaatje lokaal te cachen verdwijnen er op die manier nooit meer plaatjes op het forum. Onbedoeld werken "poll" plaatjes niet meer, maar zouden met een kleine ingreep wel weer kunnen gaan werken (poster geeft aan dat het plaatje niet gecached moet worden)

In het geval van scenario 1 is het dus géén bug en waarschijnlijk een WONTFIX en in scenario 2 is het dus wél een bug. Of het is een "scenario 3"...

@DexterDee Volgens mij was camo oorspronkelijk bedoeld om mixed content-meldingen te voorkomen als de site zelf via https maar externe afbeeldingen via http werden geladen.

edit: review: Tweakers stapt over op https (ctrl+F Https-camouflage-proxy )

[ Voor 31% gewijzigd door Raven op 08-09-2026 16:07 ]

Raven schreef op dinsdag 8 september 2026 @ 16:06:
@DexterDee Volgens mij was camo oorspronkelijk bedoeld om mixed content-meldingen te voorkomen als de site zelf via https maar externe afbeeldingen via http werden geladen.

Dat is inderdaad de taak van Camo en dat werkt prima.

De Tweakers implementatie van Camo functioneert echter niet hetzelfde als de "standaard" Camo. Die heeft namelijk geen cache en zal plaatjes altijd opnieuw van de bron laden bij elk verzoek. Met dat gedrag hadden we dit issue niet en zouden poll plaatjes dus gewoon bijgewerkt worden.

Tweakers heeft ergens nog een extra mechanisme die het plaatje in een cache stopt. Dat kan een proxy als Varnish zijn, of de broncode van Camo die zelf is aangepast, of iets anders. Die implementatie respecteert een header als Cache-Control: no-cache, no-store, must-revalidatein ieder geval niet. En dat lijkt een bewuste keuze te zijn.

AW_Bos schreef op maandag 7 september 2026 @ 18:00:
Hoezo is dit eigenlijk geen bug? Het heeft wel goed gewerkt, maar tegenwoordig niet meer.

[...]

Beetje stom antwoord misschien: omdat wij het geen bug vinden.

Ik snap jouw redenatie 'het werkte vroeger wel, nu niet, dus het is een bug' wel. Vanuit mijn kant werkt het iets anders. Het is een bug als het per ongeluk stuk gegaan is.

Als er dus bewuste keuzes worden gemaakt, en daardoor de kans loopt dat er iets op een later moment stuk zou gaan dan is dat een bewuste keuze geweest en de gevolgen daarvan geen bugs.

@DexterDee Hoe onze Camo precies ingericht is weet ik niet, daar zal ik even naar moeten kijken. Wel is het zo dat we ondertussen volgens mij 4 lagen hebben die kunnen cachen, dus misschien dat het op een andere laag misgaat en niet in Camo zelf. Misschien dat @Kees het uit z'n hoofd weet, anders zal ik daar later 'ns naar moeten kijken.

DexterDee schreef op dinsdag 8 september 2026 @ 18:39:
[...]

Dat is inderdaad de taak van Camo en dat werkt prima.

De Tweakers implementatie van Camo functioneert echter niet hetzelfde als de "standaard" Camo. Die heeft namelijk geen cache en zal plaatjes altijd opnieuw van de bron laden bij elk verzoek. Met dat gedrag hadden we dit issue niet en zouden poll plaatjes dus gewoon bijgewerkt worden.

Tweakers heeft ergens nog een extra mechanisme die het plaatje in een cache stopt. Dat kan een proxy als Varnish zijn, of de broncode van Camo die zelf is aangepast, of iets anders. Die implementatie respecteert een header als Cache-Control: no-cache, no-store, must-revalidatein ieder geval niet. En dat lijkt een bewuste keuze te zijn.

Wij cachen camo resultaten op de servers, daarnaast nog een keer in de loadbalancer en als klapstuk ook bij Akamai. En inderdaad, we gooien bewust alle headers weg en cachen het resultaat ongeacht wat de bron aangeeft.

Dat doen we vanwege security (zodat je niet met een tracking pixel mensen kan volgen), vanwege dataverkeer (zodat we niet elk plaatje elke keer opnieuw hoeven op te halen) en vanwege snelheid (zodat je niet hoeft te wachten op langzame backends)

Kees schreef op woensdag 9 september 2026 @ 07:36:
Dat doen we vanwege security (zodat je niet met een tracking pixel mensen kan volgen), vanwege dataverkeer (zodat we niet elk plaatje elke keer opnieuw hoeven op te halen) en vanwege snelheid (zodat je niet hoeft te wachten op langzame backends)

Dat is een helder verhaal, dank @Kees, het bevestigt mijn vermoeden dat dit een bewuste keuze was en dat we niet de verwachting moeten hebben dat dynamische plaatjes (lees: polls) weer gaan werken.

Ik ben persoonlijk van mening dat het tracking pixel probleem eigenlijk al met Camo als passthrough proxy is opgelost omdat het plaatje dan vanuit een server van Tweakers opgevraagd wordt en de eigenaar van het plaatje geen metadata kan vergaren over de forumbezoeker (IP, user-agent, referer, etc.). En voor de use case "ik wil een poll resultaat laten zien" is het belangrijker dat het plaatje "vers" is dan dat het snel geladen wordt.

Uiteindelijk bepaalt Tweakers zelf hoe ze hier mee om willen gaan en met deze duidelijkheid verandert de vraag van dit topic van "poll plaatjes moeten weer gaan werken" naar "er is behoefte aan een poll functie op het forum".

Het lijkt dus in Camo te zitten, want de afbeelding linkt altijd naar Camo toe.
Is er geen uitzondering te maken voor specifiek deze URL? Er is blijkbaar een functie in de parser die dus normaal alle externe afbeeldingen naar een Camo-link doorstuurt (en cached).

Maar kan de URL poll.dezeserver.nl daar niet van uitgesloten worden, zodat je de directe afbeelding ziet staan?

Ik snap jullie redenen wel qua veiligheid, maar jullie ontnemen eigenlijk een externe dienst, die eigenlijk ontstaan is vanuit een gemis in jullie forumsoftware.

[ Voor 18% gewijzigd door AW_Bos op 09-09-2026 12:32 ]

AW_Bos schreef op maandag 14 september 2026 @ 11:27:
Dat meen je niet!

* AW_Bos zoekt de Kees is een Held banner....

Poll: Kees is een held!
• Echt!
• Zeker!
• Een echte held!
^Tussenstand:
[Afbeelding]
^{Ook een poll maken? Klik hier}

Uhh...


Ik weet niet wat daar nog mis gaat?

Edit: Paar keer refreshen en hij doet het.

Dan moet je die die (dooie) afbeelding eens openen in je browser. Vermoedelijk krijg je dan textuele content terug met een reden...

Misschien was het de WAF-firewall?

Kees schreef op maandag 14 september 2026 @ 11:24:
[...]

Ja, en die uitzondering had ik er ook al staan. Maar die werkte niet goed. Naar aanleiding van dit topic er toch weer eens naar gekeken en uiteindelijk de hele config in Claude gegooit met de vraag 'waarom werkt dit niet'.

Het antwoord was te simpel...


[...]

* Kees fluit onschuldig. Twee jaar overheen gelezen.. :X

De polls worden nu niet meer gecached.

Soms is het zo iets stoms he

Maar dank je wel voor de uitzondering, ik denk dat veel mensen daar erg blij mee zullen zijn

PEBKAC.

Haha, dit benadert de lol die ik had in het epische 'help ik heb lichtblauwe keukendeurtjes gekregen in plaats van witte wat is de beste juridische aanpak'-topic (#opavertelt)

Voor wie dat topic niet in zn herinnering heeft: