Er zijn allerlei tools om ze te helpen met invoeren van html (wysiwyg editors) en weer andere tools die html die ze uiteindelijk opsturen nog op te schonen. Het is sowieso aan te raden om zo min mogelijk opmaak erin te hebben en met name de structuur van de tekst vast te leggen in de html (dus werk met css, zo min mogelijk met css-classes in wat je opslaat en bij voorkeur geen inline style).
Bedankt voor de tips en info.. Dit ga ik opnemen in mijn besluiten lijst.
Databases hebben vrij uitgebreide ondersteuning voor datums met tijdzones. Dat kan je het beste gewoon gebruiken. Omrekenen naar UTC is dan niet nodig, zolang de database maar weet welke tijdzone bij een ingevoerde datum gold (dus een datum opsturen met gebruikte tijdzone).
Specifiek date en datetime worden opgeslagen met een tijdzone (in het geval van mysql de 'timestamp' niet!). Op die manier kan je zowel in de database als in php die informatie gebruiken om e.e.a. om te rekenen naar de juiste tijdzone.
Ik ga dat eens even uitzoeken wat ik kan vinden hierover in de documentatie van MariaDB.
Maar op dit moment ziet mijn systeem op papier er grof weg zo uit:
Zodra de organisator een evenement aanmaakt, moet er de tijd, datum en locatie ingevoerd worden.
Aan de hand van de locatie gegevens zou het mogelijk moeten zijn of daar de juiste timezone, winter/zomertijd offset bij te bepalen.
Ik verwacht, dat als ik ga zoeken op het internet, dat er al tabellen of liberies bestaan die ons daarbij kunnen helpen.
Dus even grof de functie voor de invoer van een nieuw evenement in de database voor wat betreft tijd:
(Invoer datum/tijd) + (timezone correctie) + (zomer/wintertijd correctie) = UTC
Ongeacht welk evenement op welke locatie, kunnen we steeds dezelfde functie gebruiken.
Wanneer een bezoeker / organisator iets opzoekt, dan hebben we grof weg de volgende functie:
UTC + (timezone correctie) + (zomer/wintertijd correctie) = weergave gegevens in browser
Doordat er geen tijd/datum, tijdzone, offset direct gekoppeld is aan een eventement, maar tijd/datum & locatie zou het bij een wijziging van time/zone of zomer/wintertijd offset alleen het desbetreffende tabel aangepast hoeven te worden.
Anders zou je alle evenementen moeten nalopen of zij wel of geen aanpassingen nodig hebben.
Misschien dat ik met dit systeem compleet de plank mis sla...Laat me het vooral weten.
Wel begrijp ik, dat het maken van de functies die ervoor zorgen dat de juiste time/zone en offset geselecteerd wordt, ook pittige uitdagingen kan geven.
Voor met name php zou ik je wel aanbevelen om een paar libraries te gebruiken. Het scheelt bijvoorbeeld erg veel werk om iets als "HTMLPurifier" (of een van de alternatieven) te gebruiken voor het opschonen van de html. En je voorkomt ook alle beginnersfouten daarmee die zij al opgelost hebben (zoals dat je javascript: kan doen in een a's href of nare dingen met inline css)
Zal ik ook naar gaan kijken. Maar ben me ervan bewust dat ook het CMS gedeelte een pittige santizing nodig voor wat betreft de invoer van de gebruiker. Dit geldt natuurlijk ook voor input vanuit de account gedeelte ed.
Wij hadden bij Tweakers ook een sterke "not invented here"-afkeer... Maar uiteindelijk scheelt het je wel erg veel werk als je toch ook serieus libraries overweegt. Maar je leert inderdaad wel veel meer van het zelf ook een keer doen.
Vooral het leren, opzoeken op internet en zelf bedenken zorgt er voor dat je, in mijn mening, ook echt gaat begrijpen wat je aan het bouwen bent.
Als je relatief vlug resultaat wilt boeken, ja dan zijn liberies geweldige stukken codes.
Ik raad je wel aan om direct al voorbereid te zijn op meertaligheid, ook al doe je eerst maar 1 taal. Het is een hoop werk om dat later nog aan te passen. Dus al je schermtekstjes uit een I18n lib laten komen, datum/tijd formaten direct goed, getalnotatie direct goed.
Bedankt voor de tip. Ik begrijp de achterliggende gedacht van, geen werk verrichten van wat je later weer compleet overnieuw moet doen.
(en wat betekent 'opmaak in de database'?)
Met opmaak bedoek ik eigenlijk dat de opmaak van een website (bijv CSS ed), dus niet de teksten, als gegevens in een database te zetten.
Ik begrijp dat dit wel heel erg ver gaat. Maar zou in de toekomst ervoor kunnen zorgen, dat ander mensen de website gedeeltelijk kunnen aanpassen voor wat betreft de look en feel. Via een soort CMS portal oid.
Handigst is om een educated guess te doen voor de tijdzone en de gebruiker deze te laten wijzigen (bv in een profiel ofzo).
Stel, ik ben Nederlands en zie je evenementen in de Nederlandse tijdzone. Alles prima. Nu ga ik naar New York en bezoek je site daar. Hoe zou ik mijn tijden willen zien? EST? CET? UTC? voor alles wat te zeggen.
Hierover heb ik al zitten nadenken en heb nog niet echt een definitieve technische oplossing bedacht.
Om een goede educated guess te kunnen doen, moet je informatie hebben.
Als iemand een account heeft, zou je de gebruiker kunnen aanbieden om deze instellingen op te slaan en aan te bieden wanneer er ingelogd wordt.
Je zou dan tevens kunnen aanbieden GPS posititie, taal/regio OS instellingen, webbrouwser instellingen te mogen gebruiken hiervoor.
Dit is dan een bewuste keuze van de gebruiker.
Voor mensen die anoniem de website bekijken wordt het een andere uitdaging.
Daar zou je elke keer dus moeten vragen wat ze willen delen aan info om de website goed te laten functioneren als ze de site bezoeken.
Ik zelf heb een hekel aan die cookie meldingen die je eerst moet accepteren of aanpassen om door te kunnen gaan.
Zelf bezoek ik vaak pagina's niet meer waar dit groot irritant in het scherm komt te staan.
Ben dus nog aan het leren /zoeken / bedenken hoe dit zou moeten gaan werken zonder (sessie) cookies ed. voor de anonieme bezoeker
Dan hoef ik ook geen cookie banner op de website te plaasten i.v.m. AVG ed.
/u/1830/acm.png?f=community)
:strip_exif()/u/88216/Goomba-animated.gif?f=community)
:strip_exif()/u/259931/stuiterbal2.gif?f=community)
:strip_icc():strip_exif()/u/116726/crop5e3ee297a8a03_cropped.jpeg?f=community)
:strip_exif()/u/396800/D-_3427da0a9c293b63f2a66dea2e642102.gif?f=community)
Hierop was men nog niet ingegaan.