Posts by FangorN

Ok, ik heb hier nog even langer dan goed voor mij is naar gekeken en heb het nu aan de praat.

Allereerst wat observaties:

• firstChild.data retourneert "undefined", dit kun je oplossen door voorkomens (2x) van firstChild.data te vervangen door firstChild.innerHTML
• de regenboog functionaliteit verwacht een element met een id om het element wat de regenboog functionaliteit moet hebben heen anders wordt de "span" (nogal misleidende naam) niet gevonden
• omdat je nu potentieel meerdere regenbogen hebt is het handig om alle voorkomens op te slaan in een array, te meer omdat deze ook allemaal aparte timers hebben

Om dit aan de praat te krijgen moet je het volgende doen:

1. Zoals aangegeven, vervang de voorkomens (2x) van firstChild.data door firstChild.innerHTML
2. Schrijf wat extra code die het gebruik van meerdere regenbogen mogelijk maakt, bijvoorbeeld als volgt (met gebruikmaking van jQuery):

$().ready(function() {
    var rainbows = [];
    function createRainbow(element, id) {
        $(element).wrap('<div id="'+id+'"></div>');
        rainbows[id] = new RainbowSpan(document.getElementById(id), 0, 360, 255, 50, 18);
        rainbows[id].timer = window.setInterval(function() {
            rainbows[id].moveRainbow();
        }, rainbows[id].speed);
    }


    $('.rainbow').each(function(index, element) {
        createRainbow(element, 'r'+index);
    });
});

Het bovenstaande is getest en werkt in FireFox, Chrome en IE Edge.

Citaat van sukel

Bovenstaande oplossing kan ik gebruiken maar zit nu al aan 7k users dus dat wordt wel een flinke load.

Zie niet helemaal hoe dit relevant is want JavaScript = clientside, of ik moet je verkeerd begrijpen.

EDIT: tijdelijk werkend voorbeeld

Ah ja, dan heb ik niks gezegd. Sorry ^^;

@mommi even voor de duidelijkheid: dit heeft voorheen wel gewerkt in de huidige live omgeving?

Dat zou dan inhouden dat er iets veranderd moet zijn in de tussentijd.

Is er code gewijzigd?
Is de versie van PHP of Apache gebumpt?
Staat mod_rewrite nog aan?

Het komt namelijk zelden tot nooit voor dat (in dit geval: de navigatie van) een site ineens niet meer werkt zonder dat er iets in de technische opzet wijzigt.

On a side note: het lijkt mij onwenselijk dat het mogelijk is dat je de inhoud van een pagina rechtstreeks kunt opvragen (bijvoorbeeld via modules/leden/registreren.php). Hier zou je een eenvoudige beveiliging voor in kunnen bouwen zodat dit soort code enkel geinclude kan worden in een maintemplate / index-file.

EDIT: afgaande op het oorspronkelijke bericht is dit alles recent online gezet en heeft dit nooit live gewerkt; klopt dit?

Ik meen mij te herinneren dat ik op dit topic had gereageerd, maar kan mij vergissen.

Misschien kunnen er wel wat quick fixes uitgevoerd worden zodat het forum voor nu in ieder geval weer werkt (en daarvoor zou een analyse moeten plaatsvinden naar wat er nu precies misgaat) maar ik denk dat ik bij mijn stelling blijf die ik volgens mij eerder plaatste: indien bovenstaande code representatief is voor hoe de site in elkaar zit zou ik sterk overwegen om iets nieuws te maken of eens te kijken naar alternatieve bulletin boards oid.

Graag ontvang ik (en anderen met mij waarschijnlijk ook) van moderators een bericht indien berichten worden verwijderd met een reden voor verwijdering. Of op zijn minst een verzoek om een antwoord wat verder uiteen te zetten ofzo. Het siert deze site niet als er te pas en te onpas zomaar reacties worden verwijderd (als hier sprake van is).

Laat ik het anders verwoorden: wat is/zijn de conditie(s) voor het toevoegen van die span? En waar regel je dat dit specifiek "r1" moet zijn? Komt hier een scriptingtaal aan te pas? Regel je dit rechtstreeks in een template/in HTML?

Je hebt het over een markeren van een gebruikersnaam? Een specifieke? Alle?

Je zou al die delen die met een regenboog opgemaakt moeten worden (als dit vantevoren al op een of andere manier vastligt) kunnen voorzien van een class X. Vervolgens voeg je een snippet JavaScript toe die alle spans met class X afloopt en deze voorziet van een uniek id waar je vervolgens de regenboog-functionaliteit aan koppelt. Je maakt dus via een tussenstap een koppelstuk zodat je deze delen aan de regenboog-code kunt klikken zonder dat je hiervoor de regenboog-code inhoudelijk hoeft aan te passen.

Het implementeren van dit principe wordt wel lastig als je niet uitlegt hoe dit proces verloopt of wanneer je zelf niets/heel weinig kunt schuiven in de forumcode.

En als je nu een mechanisme hebt/verzint waarbij je unieke id's genereert, dan kun je je regenboogcode blijven gebruiken zoals voorheen omdat je dan niets aan functionaliteit hoeft te wijzigen.

Je zegt dat je dit gebruikt op een forum, heb je daar UBB-code of wat dan ook? De oplossing hangt voor een groot deel af van hoe iemand passages tekst kan markeren voor regenboog-opmaak. Dit bepaalt namelijk in een grote mate je oplossingsrichting.

Mijn eerste vraag zou dan ook zijn: hoe markeer je tekst voor deze opmaak?

Indien de code uit je andere topic representatief is voor de rest van de code is het misschien beter om dit alles te herschrijven.

Citaat van wimmpie

Ik zou eventuele oplossingen alsnog graag horen!

Zorgen dat de kolom NULL waarden kan accepteren? NULL betekent dan ook echt "niet ingevuld", je kunt dan ook makkelijker onderscheid maken tussen records die wel een datum hebben en records zonder datum, dit doe je dan met WHERE ... column_name IS (NOT) NULL. In plaats van column_name > '0000-00-00 00:00:00' of wat je ook als default datum wilt pakken.

NULL waarden geven geregeld uitzonderingen aan. Zo zou een kolom die normaal alleen foreign-key waarden zou mogen bevatten (vanwege een constraint) ook de waarde NULL mogen hebben (mits de kolom niet NOT NULL is uiteraard). NULL betekent in dat geval "geen relatie met de verwijzende table". Dit moet natuurlijk wel hout snijden in wat je probeert te modelleren, het is niet de bedoeling dat data op deze wijze onterecht ontkoppelt raakt.

Het gebruik van NULL kan handig zijn om gevalsonderscheid te maken tussen een geinitialiseerde en ongeinitialiseerde toestand van een kolom (of variabele).

Citaat van K.Rens

- Klachten dat in de recente activiteit bovenaan ook de likes stonden

Vind ik wel handig, hiermee kun je (opnieuw) iets onder de aandacht brengen. Je zou hier wellicht een optie van kunnen maken dat je dit uit kunt zetten als je hier niet van gediend bent?

Citaat van K.Rens

- Klachten dat we te weinig nieuws postten van ICTs zelf

Zoals @Aaron al aangaf kun je hier zelf ook iets aan doen :). Het is altijd makkelijk roepen vanaf de tribune.

Vaak is het ook beter om niets te zeggen als er niets te zeggen valt in plaats van de leemtes te vullen met blabla verhalen.

En waarom pas je dan de News rubriek aan als er "klachten" zijn over het "Recent Activities" blok (zou dat niet "Recent Activity" moeten zijn trouwens?) of mis ik nu iets?

Citaat van K.Rens

- Klachten dat de homepage zo kaal was, zonder foto's. Vandaar dat er af en toe nu berichten in kunnen komen met foto's.

Nieuws is in eerste instantie om te informeren, niet om te vermaken toch? Je kunt dit wel opvullen met memes of stockfoto's, maar het effect daarvan verliest toch snel zijn waarde imo.

Ik denk ook dat het beter is om deze gescheiden te houden. Voornamelijk omdat forumberichten en (officiële) nieuwsberichten vanuit "de organisatie" nu eenmaal niet hetzelfde gewicht / dezelfde autoriteit (zouden moeten) hebben.

Het hoort simpelweg niet bij elkaar. Appels !== peren.

Ik heb proberen te beredeneren wat de beweegredenen zouden kunnen zijn om dit zo aan te pakken, maar ik kom er niet uit. Is dit omdat het "komkommertijd" is?

Citaat van Aaron

Zo kan je door naar onze website te surfen al 3 topics in het kort lezen die recent zijn toegevoegd.

Dit staat al in de zijkaders in "Latest posts in..."?

Of je leest eens een boek (of de krant).

Aanrader: Fahrenheit 451 van Ray Bradbury. Heeft ook een mooie (verontrustende?) parallel met nu waarin eenieder zich haast permanent wil onderdompelen in media-afleiding.

@WMDiensten
Lees nogmaals wat ik zeg/typ. Dit heeft niets te maken met al dan niet "slim bezig zijn". Het gaat erom welke mogelijkheden je tot je beschikking hebt. En als je dan niet anders kunt dan live debuggen kun je er beter voor zorgen dat dit veilig gebeurt inderdaad. Dit is altijd (het) belangrijk(ste). Dat laatste was eigenlijk mijn punt...

Maar prima als je een draai wilt geven aan wat ik zeg, en dat je het daar dan vervolgens niet mee eens bent :p.

Wellicht, maar er is weinig (lees: geen) ruimte voor alternatieve interpretaties van wat de intentie van dat soort sites is.

Dit is net zoiets als winkels die alle benodigdheden verkopen voor de verbouw van wietplanten. Die doen in principe ook niets strafbaars maar dit kun je moeilijk overeind houden door maar te zeggen dat je (als verkoper) vervolgens hoopt dat niemand vervolgens wietplanten gaat verbouwen (dit was X jaar geleden zelfs een nieuwsitem geloof ik).

Los daarvan, er is ook zoiets als het goede voorbeeld geven.

Zijn deze reacties niet in strijd met jullie eigen regelgeving (1.4)?

Allereerst: je hoeft niet alles om te zetten naar UNIX_TIMESTAMPs. Een DATETIME (YYYY-MM-DD HH:MM:SS) is namelijk zo opgebouwd dat deze alfabetisch dezelfde ordening / sortering volgt als een numerieke variant. Je kunt met DATETIMEs dus op precies dezelfde wijze rekenen (en dezelfde operatoren gebruiken) als dat je met getallen/floats zou doen.

Ten tweede: dit is wel een hele bijzondere mix van AND, OR en (vervolgens) && en ||. Het is voor mij lastig om direct te zeggen wat deze code / query nu concreet zou doen :p (iha: de query leest allesbehalve prettig). Het is denk ik beter wanneer je één schrijfwijze (bij voorkeur AND en OR) aanhoudt. Te meer omdat in MySQL ook de operatoren & en | bestaan die iets heel anders betekenen.

Ook heeft MySQL functies als DATE() waarmee je het datum-deel van een DATETIME kunt opvragen.

Tot slot: het maken van een simpel tekeningetje kan enorm helpen. Teken een of meer tijdslijnen en het tijdsinterval waarin je geinteresseerd bent en kijk dan naar de verschillende situaties die kunnen optreden om het gevalsonderscheid (in de gevallen waarin je geinteresseerd bent) in je query te kunnen maken.

Er zijn dus al een heleboel dingen die je kunt doen om de query flink in te korten en dingen voor jezelf overzichtelijk te maken.

Echter, misschien wil je je strategie herzien of op zijn minst herbestuderen. Zo zou je kunnen overwegen om dingen in tijdsblokken (kwartier? half uur? uur? dagdeel? dag?) op te delen. Het grote voordeel hiervan is dat je expliciet vastlegt wie wat op welk moment aan het doen is. Want op dit moment moet je dit elke keer indirect herberekenen / afleiden uit intervallen, wat mogelijk niet altijd handig is. Wanneer je je databasevragen dan bijvoorbeeld uit een ander perspectief gaat stellen ("Wie is er op tijdstip/tijdsinterval X beschikbaar") dan wordt het verdomd lastig zoniet onmogelijk om hier direct/makkelijk een antwoord op te geven. Vraag dus jezelf (mede) af: welke vragen wil ik kunnen beantwoorden bij dit roostersysteem (of wat het ook is). Het (technische) databaseontwerp zou in dienst moeten staan van wat je (functioneel) met dit systeem wilt kunnen doen.

Citaat van K.Rens

Kennen jullie nog alternatieven?

Weet niet precies waar je naartoe wilt met deze vraag en ook niet of dit de boodschap is (welke deze ook mag zijn) die ictscripters uit zou moeten dragen.

Sidenote: bron?

Maar alle HTML en (clientside) JavaScript code die de browser ontvangt is toch niet geëncodeerd? Als dat niet het geval is zou dat inhouden dat een browser speciale voorzieningen zou moeten hebben om met dat soort bestanden om te gaan?

Citaat van Ferhat.Remory

Het Javascript gedeelde zal wel in een php-file staan die geïnclude wordt. Alleen is deze gecodeerd.

Wut? Tenzij IonCube of whatever een plugin heeft voor een browser zal de JavaScript niet geëncodeerd zijn omdat een browser iets moet kunnen doen met deze code aan de clientside (moet leesbaar/uitvoerbaar zijn als JavaScript)?

Rmouseclicks afvangen als "beveiliging" is uit de tijd van webpagina's met frames en het gebruik van stripslashes() om SQL injectie te "voorkomen".

Of ik moet het verkeerd begrijpen.

Een waarschuwing heeft geen zin. Het strafbaar stellen met boetes wel.

Het is ook niet de schuld van een specifieke applicatie maar het feit dat je als verkeersdeelnemer op een schermpje aan het koekeloeren bent terwijl je je omgeving in de gaten zou moeten houden.

"ROKEN IS DODELIJK" in koeienletters op een pakje sigaretten weerhoudt mensen ook niet van roken. Zolang iemand iets niet direct (en fors) merkt in zijn/haar portemonnee zal elke waarschuwing in de wind geslagen worden.

Citaat van Ferhat.Remory

Niantic kan er niet aan doen dat er in 2016 veel retards zijn.

Duidelijke regelgeving lijkt mij dan handig. Veel eenduidiger dan een totaalverbod wordt het denk ik niet.

Dit is trouwens een algemener en wijdverbreider probleem tegenwoordig :).

Waarom stel je bovenstaande oplossing dan voor?

Bij het beantwoorden van een vraag zou je voorbij moeten gaan aan het simpelweg beantwoorden van de vraag maar ook zelf opgedane kennis en ervaring hierin moeten verwerken.

Indien een vraag een oplossing zoekt in een verkeerde richting of wanneer de aanpak gewoon krom is dan moet je niet voortborduren op deze verkeerde richting/aanpak maar simpelweg aangeven dat de aanpak veranderd moet worden.

Output escaping zou in alle facetten van (PHP) programmeerwerk moeten zitten, ongeacht de omgeving.

Citaat van D.Oomens

dus dat zal niet zo'n probleem zijn.

Het is niet heel erg ver gezocht dat de data van je development omgeving een afspiegeling is van je live omgeving. Het is ook niet altijd zo dat een development omgeving compleet is afgeschermd van de buitenwereld.

Ook is het niet gegarandeerd dat je enkel data dumpt op een ontwikkelomgeving. Soms gebeurt het wel eens dat bepaalde kwesties alleen "live gedebugged" kunnen worden.

Het (soms) niet escapen van (user) data vormt te allen tijde een potentieel risico. Dit risico kun je niet het hoofd bieden door simpelweg te zeggen "dat zal niet zo'n probleem zijn". Assumption is the mother of all f*ckups. Op eenzelfde wijze kun je daaropvolgende inbraken / veiligheidslekken / diefstal van gevoelige informatie van zo'n foutieve aanname niet verexcuseren met "oeps".

Citaat van D.Oomens

Maar ook op mijn development environment wordt alles ge-escaped. So no worries .

Hier gaat het ook niet om. Je stelt iets voor (waarvan je weet) dat (het) (potentieel) onveilig is. Mja, no worries, zo lang je je eigen schaapjes maar op het droge hebt?

Predik ajb geen slechte programmeergewoontes, hoe onschuldig deze ook in eerste instantie lijken te zijn. Je weet namelijk niet hoe je codesnippets worden gebruikt.

Nnet zoals met medicijnen zou een codesnippet met een bijsluiter of in ieder geval een "word of warning" of toelichting moeten komen... Simpelweg een codefragment plaatsen zonder enig commentaar vertelt je niets over het wat en (wellicht nog belangrijker) ook niet over het waarom. Je kunt hier dan ook niet uit afleiden of deze met een zekere rationele gedachtengang totstand is gekomen, of zo maar uit de mouw wordt geschud in een onbewaakt moment. Voor minder ervaren gebruikers is dit onderscheid minder duidelijk. Als je hier code plaatst moet je deze ook kunnen onderbouwen.

+1 voor het scheiden van het debuggen van data en het beeindigen van de applicatie
-2 want nog steeds niet veilig

Nogmaals: var_dump() escaped géén output.

Misschien moet het gewoon een keer grondig misgaan voordat jullie tot inkeer komen. Een gebrande hand is in het algemeen de beste leermeester.