Posts by FangorN

Deze is niet aanklikbaar omdat dit een afbeelding is?

Dit zeiden @AarClay en @Ferhat.Remory al min of meer. Het voortraject (lookup + laden van pagina) duren al veelste lang. Je zou dus kunnen kijken:
- waarom lookup zolang duurt (brakke host? iets verkeerd geconfigureerd in DNS ofzo?)
- waarom de pagina zelf zo lang bezig is met laden (wat @AarClay dus zei: plugins?)

En dan inderdaad zoals @Ferhat.Remory aangaf kun je kijkrn of verdere optimalisatie nog/direct nodig is, maar dat zou je natuurlijk altijd kunnen meenemen, ongeacht of dit noodzakelijk is of niet. Als je ergens (een flinke) performance(winst) kunt pakken zou je dat eigenlijk altijd moeten doen.

De TTFB (Time To First Byte) is geen boosdoener, dit is slechts een tijdsindicatie die het resultaat is van andere zaken.

Wat we moeten zien te achterhalen is de veroorzaker van de hoge TTFB.

Als ik deze benchmark mag geloven (en goed begrijp) duurt de DNS lookup al ~2.5 seconden?

En dan duurt het laden van het HTML-document zelf een eeuw?

Daarin zitten ook nog een hoop grote -en ongecomprimeerde- elementen. Twee JPEGs van over een megabyte? o_O

Kijk anders eens in de netwerk-tab van je developer console van je browser, meestal onder de F12 functietoets. Daar zie je de tijdslijn waarin de bestanden waaruit je site bestaat wordt geladen. In mijn tijdslijn staat het HTML hoofddocument zelf 3-5 seconden te stampen.

Ik zou zeggen: brakke HTML? hier zitten onderdelen in die het snel laden / renderen op een of andere manier belemmeren / blokkeren. Dit lijkt overigens structureel, na een page-refresh speelt nog steeds hetzelfde euvel.
EDIT: of liever gezegd: het laden van het HTML-document zelf duurt lang, vraag is hoe dit komt.

Verplaats anders eens een of meer JavaScript bestanden naar de voet van de pagina en/of schakel er een of meer tijdelijk uit net zolang totdat je de boosdoener hebt gevonden en zoek vervolgens hoe deze vertraging in dat specifieke geval kan worden voorkomen.

Daarbij: heeft WP geen caching voor JS/CSS bestanden? Ik zie niet veel externe dingen / CDNs enzo?

Citaat van Jesse

daarnaast hebben de klanten op hun beurt de mogelijkheid om over te stappen!

Ook dat staat in de algemene voorwaarden:

Citaat van Algemene Voorwaarden Versio

Indien Klant een wijziging niet wil accepteren, dient Klant dit binnen twee weken naaankondiging schriftelijk gemotiveerd mede te delen aan Versio. Versio kan daarop dewijziging heroverwegen. Indien Versio daarop de wijziging niet intrekt, kan Klant binnen zevendagen nadien de Overeenkomst beëindigen tegen deze datum

Je kunt dus (het beste lijkt mij aangetekend) schriftelijk je beklag doen en als ze daar niets mee doen opzeggen.

Citaat van AarClay

'feestje!!'

Waar wordt dit woord gebruikt? In een mail? In een nieuwsbericht? Tot zover wordt dit alleen aangehaald in een vorige reactie? En dat dat samenvalt met een prijsverhoging is mogelijk niets meer dan slechte timing, al wordt dit hier allemaal aan elkaar gemetseld alsof er een verband is en er opzet in het spel zou zijn om hun klanten te naaien ofzo. Ook vraag ik mij af wat de daadwerkelijke prijsverhoging inhoudt in elk specifiek geval. Er wordt wel gesmeten met percentages en bedragen enzo, maar klopt dit wel?

Los van het feit dat je zo'n actie kunt afkeuren is de objectieve beeldvorming echt ver te zoeken.

Ik weet verder niets van Versio, maar:

Citaat van LadyOfHell

de nieuwe eigenaren van Versio

Ik kan hier niets over vinden. Of was dat sarcastisch bedoeld?

Om even een advocate of the devil te spelen: Versio staat volledig in zijn recht om op elk moment hun prijzen te veranderen, dit staat immers in hun algemene voorwaarden. Je weet wel, die gortdroge tekst die niemand leest, en waar jij op een gegeven moment een vinkje bij aantikt waarmee je aangeeft dat je hiermee akkoord gaat.

Het is natuurlijk niet erg netjes dat de prijzen ineens fors omhoog gaan, en vooral als dat onaangekondigd gebeurt. En natuurlijk is een van de redenen dat ze meer geld willen verdienen, dat wil elk bedrijf. Maar ik kan mij ook voorstellen dat er andere beweegredenen zijn. Ik kan mij vergissen, maar Versio is een prijsvechter onder hosting correct? Met (spot)goedkope hosting trekt dit ook een hoop bagger aan. Wellicht willen ze door de prijs op te drijven de partijen die problemen veroorzaken hun bestand uitjagen? Vergelijk het met vervelende (onder)verhuurders van panden. Dit kan voor hun een kostenbesparing betekenen omdat ze dan minder tijd kwijt zijn met dweilen.

En als je het niet bevalt ga je toch naar een andere partij? Oh maar ze zijn nog steeds relatief goedkoop, maar nu maak je zelf minder winst? Dus je blijft toch lekker zitten waar je zit ook al ben je het principieel oneens met wat zij doen, maar ondertussen veroordeel je wat zijn doen en laat je ten faveure van het kostenplaatje je eigen principes ook varen?

Daar is een woord voor.

Dat kan ook, maar een token die je een enkele keer kunt gebruiken werkt ook prima.

En je zegt het zelf al: Facebook of Twitter. Dan zou je theoretisch eerst kunnen stemmen via je Facebook-account, en vervolgens via Twitter? Of ben jij voor zowel Facebook als Twitter één en dezelfde persoon?

Het probleem blijft natuurlijk dat je nooit echt zeker weet of het verschillende personen betreft of niet.

Of je laat mensen inschrijven, en stuurt ze dan een eenmalig token om te stemmen voor een petitie. Op die manier kunnen ze dus ook niet meerdere keren stemmen via een ander ip en/of e-mail adres.

Met deze code zou je een eind moeten komen. Het enige wat mogelijk nog moet gebeuren is de poll_participants tabel uitbreiden, en wellicht bijhouden voor welke petitie ze zich opgeven. En dan zul je nog mailtjes de deur uit moeten doen om hun te voorzien voor een stem-token. Maar dit zou je makkelijk kunnen doen door deze code wat uit te breiden met een eenvoudige admin.

Overigens zijn er voor het afnemen van petities toch ook online zat gratis alternatieven te vinden?

Mja maar goed, wanneer start een conversatie, en wanneer stopt deze? Als die grens toch vaag is dan kun je net zo goed een berichtensysteem hebben waarbij je een bericht van A (verzender) naar B (ontvanger) stuurt. Je kunt dan berichten lezen wanneer jij A of B bent. En als je dit dus meer wilt onderverdelen dan zul je een soort van aparte "thread" moeten aanmaken (bijvoorbeeld zoals conversaties op deze website werken) zodat je een berichtenbundel als "gesprek" kunt behandelen.

En dan het volgende: is het echt interactief, dus een soort van AJAX-applicatie waarbij je met iemand chat? Of toch meer een soort van forum-formaat (langere tijd tussen reacties / geen rechtstreekse respons). In het laatste geval zal het denk ik toch vaker voorkomen dat je iemand af en toe een persoonlijk bericht stuurt, dus dat zal meer "af en aan" zijn dan dat je echt één op één een gesprek aan het voeren bent, de vraag is of er dan echt de noodzaak is om dingen te bundelen in gesprekken.

Als je source X uitbreidt die onder de GPL valt, zou je *alle* code mogen inzien, dus ook eventuele uitbreidingen, lijkt mij. De GPL gaat niet alleen over wat er initieel is, maar ook over wat er daarna nog bijkomt.

Sterker nog, als je de GPL nog wat verder doorleest, lijkt het erop dat:
- je expliciet moet aangeven dat dit een aangepaste source is
- dat alles (inclusief nieuwe zut) OOK onder voorgenoemde GPL en dus de daarvoor geldende regels valt

Aan de andere kant, wat je "verkoopt" is een dienst - het is de output van het GPL-product. Wat dat betreft zijn webapplicaties misschien een vreemde eend in de bijt. In dat opzicht kan closed source misschien wel, omdat de eindgebruiker het product toch niet bezit.

Maar het maakt in het algemeen niet uit of je uitbreidingen schrijft of niet, alle aanpassingen die je in een GPL-applicatie doet vallen nog steeds onder dezelfde GPL. Je kunt je hier niet "uitprogrammeren".

Dus wellicht kan het wel gewoon verder als closed source ontwikkeld worden, maar niet om de reden die jij denkt :).

Euh, waarom een random gesprek-id? Je kunt toch gewoon het eerstvolgende vrije id (auto_increment kolom) pakken?

Hoe luidt de definitie van een gesprek: is dit een conversatie met (exact) twee (verschillende) personen, of ook meer? Kan iemand de conversatie gaan bijwonen nadat deze is gestart, en verlaten voordat deze wordt beëindigd? Wanneer start een conversatie en wanneer is deze voorbij?

Pas als je deze regels hebt uitgewerkt (functionele spec) kun je dit omzetten naar een technische (database-)implementatie en pas als dat is gebeurd kun je dit vertalen naar een werkend stuk functionaliteit. Of je zou parallel al wat schermen kunnen ontwerpen als een soort van proof-of-concept.

Je zult dus eerst over de precieze vorm moeten nadenken, dit dan uitwerken, en dan gaan bouwen. In die volgorde.

Dat lijkt mij lood om oud ijzer, omdat je volgens de licentie nog steeds het recht hebt om de source in te zien?

Als de basis criminals is dan kan het, als ik de GPL goed begrijp, technisch en waarschijnlijk ook juridisch gezien geen closed source worden. Iedereen heeft volgens deze GPL namelijk het recht om code in te zien, dus ook van (betaalde) uitbreidingen.

EDIT: ah @Patrick was me voor.

Citaat van tigermaffia

makkelijk forum script

Bestaat niet. Daarbij. Dit is een collectie van PHP-bestanden, of zelfs een complete applicatie / systeem, niet een "script".

Citaat van AarClay

n je teller voor de topics bijhouden, want die wil je niet real-time uitrekenen

True. Maar die kun je ook redundant opslaan in bijvoorbeeld de categorie. Dan hoog je deze op als een topic wordt gepost en pas je deze aan als deze verplaatst en of verwijderd wordt.

Citaat van AarClay

forumrechten, spam/bot preventie etc.

Denk ook aan een goede zoekfunctie, zodat je op den duur ook informatie kunt terugvinden. Sommige sites *kuch*phphulp*kuch* kun je echt geen biet vinden. Alle informatie en kennis verdwijnt dan in een groot zwart gat. Zonde.

Dat is nog een dingetje: je zou zinnige informatie ook kunnen overhevelen in een kennissysteem/FAQ/artikelen waarin je allerhande informatie verzamelt zodat je ook echt ergens "waarde" kunt creëren. Zooi op een forum is volgende week al vaak weer vergeten. En dan worden dezelfde vragen opnieuw gesteld (klinkt bekend?). Stuur ze eerst langs dit systeem en de vraag is dan wellicht meteen beantwoord.

Citaat van pricehost

closed

Als de snippets code die ik recent van @pricehost te zien heb gekregen hier onderdeel van uitmaken is dat misschien maar beter ook ;).

Oude code is niet per definitie slecht en nieuwe code is niet per definitie goed.

Plus je haalt zelf ook al iets interessants aan: als de architectuur van zo'n... euh... applicatie niet berekend is op (modulaire) uitbreidbaarheid dan... veel succes :).

Als dat PHP-bestand rechtstreeks wordt aangeroepen klopt dat waarschijnlijk wel. Vooral ook omdat dit alles out-of-the-box is neem ik aan? Als je niets aan code hebt veranderd is het misschien nog een configuratie-dingetje ofzo.

Worden de afbeeldingen die niet getoond worden gerandomized ofzo? En welke afbeeldingen (pad enzo) zijn dat precies? En als ze gegenereerd worden loopt misschien dus je imagecreatefromjpeg() stuk.

Ook errorlogs kunnen een hoop informatie verschaffen, heb je daar al in gekeken?

Maar het is allemaal nogal vaag op dit moment, vooral omdat ik mij geen goed beeld kan vormen over de situatie. Heb je misschien ergens een werkend voorbeeld? Een (niet werkend) plaatje zegt ook hier meer dan duizend woorden waarschijnlijk :).

Als je code daar gebruik van maakt, klopt dat pad dan ook? Komt dit dan overeen met $imageurl? Wat geeft imagecreatefromjpeg() terug?

Euh, waar staan deze afbeeldingen? Ik denk dat imagecreatefromjpeg() een intern bestandspad verwacht (hierbij is een absolute verwijzing waarschijnlijk het beste)? Of mogelijk wordt de code die imagecreatefromjpeg() aanroept relatief gezien ten opzichte van de images niet 1 directory hoger uitgevoerd dan waar de images staan. Controleer anders eens of imagecreatefromjpeg() false retourneert, dat houdt dan in dat de afbeelding niet gemaakt kon worden met dat pad.

En anders controleer je errorlog, mogelijk produceer je output voordat/terwijl je die afbeelding aanmaakt, je code gaat dan ook over de zeik.