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.