Nog enkele nuttige resources:

http://www.scanit.be/uploads/php-file-upload.pdf

http://www.radinks.com/upload/config.php

1. Query om de benodigde blog post data op te halen
2. Query om alle bijhorende commentaren op te halen

Dit zijn 2 query’s. Hoe zouden we dit nu kunnen gaan optimaliseren? Als we de data van beide tabellen gaan bekijken zien we dat er veel gelijkenissen zijn tussen beide tabellen. De blog post tabel kan bijvoorbeeld volgende data hebben:

1. titel
2. titel slug (bv applicatie-optimalisatie zoals bovenaan in de url)
3. auteur (bv foreign key naar de user tabel)
4. publiceer datum
5. inhoud

De tabel commentaar kan deze velden bezitten:

1. titel (Re: <blog post titel>)
2. auteur (naam van de auteur)
3. goedgekeurd datum
4. commentaar

Zoals je ziet zijn er op enkele velden na heel wat gelijkenissen. Nu kunnen we via het UNION statement (engels) deze tabellen samenvoegen zodat deze één resultaat zullen vormen en we dus nog maar slechts één query nodig hebben. Het cartesisch product (Wikipedia) blijft hetzelfde maar in plaats van 2-maal een vraag te maken (en een mogelijke extra vertraging oplopen) naar de database server doen we het nu in één en sparen we een vraag voor een eventuele andere gebruiker.

Een volledige uitleg en voorbeelden kan je vinden in een post van mij op het forum van PHPFreaks.

Voor wie onbekend is met het onderwerp dit is het voorzien van meerdere talen op jouw website. Traditioneel lossen ze dit op via volgende wijze:

1. Een PHP bestand met daarin een array waarin alle gemeenschappelijke elementen zitten, voor elke taal die ze ondersteunen is er zo één bestand.
2. Voor de database structuur zijn er verschillende implementaties beschikbaar bijv. één tabel voor elke taal (pages, pages_en, pages_fr, ..) of het uitbreiden van de tabel met extra taal specifieke velden (title, title_en, title_fr, ..)

Deze lijst is niet uitsluitend maar is zo een beetje wat je meermaals tegenkomt. Voor de database structuur loop je zo al snel vast want als de klant een extra taal wil ondersteunen is daar steevast een programmeur voor nodig. Hoe kunnen we dit nu gaan oplossen? Wel er zijn zoals altijd meerdere oplossingen beschikbaar maar zelf gebruik ik onderstaande methode en die werkt zeer goed voor mij:

create table language (
id integer not null auto_increment,
name varchar(32), — Naam van de taal in jouw moedertaal (Frans)
name_translated varchar(32), — Naam van de taal in de oorspronkelijke taal (Français)
code char(2), — 2-letter landscode (http://www.modemsite.com/56k/_ccodes.asp)
unique language_code_un (code),
primary key (id));

create table translation (
id integer not null auto_increment,
language_id integer,
message text,
message_translated text, — zelfde principe als hierboven
unique translation_message_un (message),
key translation_language_id_fk (language_id),
primary key (id));

Alle text in mijn website omsluit ik door een functie zowel deze die er standaard in zit en deze dat uit een database word gehaald. Deze functie haalt de taal van de gebruiker op uit een cookie als die bestaat of de Accept-Language header van de gebruiker zijn browser. Als geen van voorgaande beschikbaar is, word er gebruik gemaakt van de standaard taal van het systeem (de aan de functie doorgegeven tekst word gewoon getoond zonder te worden vertaald). Op deze manier zal men nooit teksten zien staan als TR_MENU_MAIN_HOME.

Gebruik jij een andere manier? Of vind je deze manier niet goed om één of andere reden? Laat het weten in het commentaar!

Note: If different scripts have different values of session.gc_maxlifetime but share the same place for storing the session data then the script with the minimum value will be cleaning the data. In this case, use this directive together with session.save_path.

Zoals de tekst hierboven reeds aangeeft kan je dit probleem verhelpen door het save_path te veranderen naar een map binnen het privé gedeelte van jouw webruimte.

Andere problemen die mensen ondervinden met sessies in het algemeen is wanneer zij een specifiek interval opgeven waarin een gebruiker is aangemeld blijkt dit niet altijd te stroken met de werkelijkheid. Zo zal na het verlopen van dit interval de gebruiker nog enige tijd kunnen verder surfen op de website zonder dat hij zich opnieuw moet aanmelden. Dit kan men oplossen door zowel gc_probability als gc_divisor op 1 te zetten waardoor dat bij elke aanroep van de functie session_start verlopen sessies verwijderd worden. Dit is echter niet aan te raden op servers waar veel gebruikers dagelijks op surfen.

Om de sessies toch zo accuraat mogelijk te blijven verwijderen kan men op basis van statistiek de instellingen wijzigen op basis van het aantal bezoekers. Dit zou betekenen dat bij een laag aantal de sessies accuraat worden verwijderd terwijl bij een hoog aantal deze geleidelijk aan worden verwijderd.

Vandaag wil ik dat nog wat verder nemen. MSN bijvoorbeeld verteld jou wanneer jouw account zich opnieuw aanmeld om zo de persoon die mogelijk gehackt word te waarschuwen en hem aan te zetten tot het veranderen van het wachtwoord voor zijn account.

Bij de uitleg van deze techniek gaan we wel een iets andere aanpak gebruiken die de veiligheid van de account houder zal moeten verzekeren. Voor de toepassing van deze techniek gebruiken we een database zoals in de vorige post. Telkens wanneer iemand zich aanmeld sla je (buiten de sessie data) ook de gebruikersnaam op en van zodra de gebruikersnaam tweemaal voorkomt:

1. annuleer je het aanmeld proces
2. meld je de aangemelde persoon af (verwijder het record)
3. versleutel je de account en voorzie je een nieuw zelf gegeneerd wachtwoord (verdere aanmelding voorkomen)
4. verstuur je een e-mail naar de account houder met de nieuwe aanmeld gegevens

Vergeet bij deze laatste stap de account houder niet in te lichten over wat er mogelijk gebeurd is en waarom hij nu plots een nieuw wachtwoord heeft, wat hij hiermee moet doen en wat zijn volgende mogelijke stappen zouden moeten zijn (bijv. wachtwoord veranderen)

Alternatief kan je de account versleutelen (om verdere aanmeldingen te voorkomen) en een unieke link sturen naar de account houder waarmee hij een nieuw wachtwoord kan kiezen.

Deze techniek berust op de aanname dat de gebruiker zijn e-mail adres niet kan veranderen of dit alleen kan nadat er een e-mail met daarin een link ter bevestiging werd verstuurd naar zijn e-mail adres.

Er zijn verschillende initiatieven de revue gepasseerd maar we hebben uiteindelijk toch moeten concluderen dat er geen eenduidige wijze is waarop men moet omspringen met deze incompatibiliteit. Ervaren ontwerpers en ontwikkelaars weten één ding zeker je website kan niet, zal niet en moet niet er hetzelfde uitzien in elke verschillende browser omdat elke browser nu eenmaal een andere manier van weergave toepast waardoor jouw lettertype Arial, Verdana of Helvetica in Firefox er anders zal uitzien in Opera en Internet Explorer.

Deze hele achterwaartse compatibiliteit heeft nog een groter nadeel dan alleen de tijdsduur die zij inneemt nl. kostprijs. Die niet elke klant wenst te betalen, zeker niet als kan worden aangetoond dat zijn doelpubliek hypermoderne browsers gebruiken of één bepaalde browser bijv. add-ons distributie voor de Firefox browser, widget distributie voor de iPhone.

Maar ook al kan je aantonen dat jouw doelpubliek hypermoderne browsers gebruikt dan is de kans reëel dat er wel af en toe een IE6 browser op bezoek komt tot gevolg dat zij een gebroken website voorgeschoteld krijgen, wat de gebruiksvriendelijkheid van je website doet zakken tot een dieptepunt.

Dean Edward presenteert wat mogelijk een oplossing kan vormen nl. een universeel css bestand dat jouw website voor IE6 gebruikers op een waardige manier vormgeeft, zonder al de fancy afbeeldingen en langs jouw kant geen inspanning vereist. Deze oplossing neemt één stelling aan nl. gebruikers bezoeken jouw website voor de inhoud (niet zijn vormgeving). Deze methode kan dus niet worden toegepast op bijv. een portfolio van een kunst-ontwerper.

Het volledige artikel kan je terugvinden op forabeautifulweb. Edward somt ook alternatieven op die werden toegepast in het verleden waaruit wij hebben kunnen concluderen dat er geen eenduidige wijze is waarop er kan worden omgegaan met verouderde browsers en de incompatibiliteit die zij meebrengen.

Hoe spring jij om met IE6 en verouderde browsers in het algemeen?

Stel in een deel van je applicatie gebruik je thumbnails en dus schrijft jouw applicatie:

/images/thumbs/an-image-thumb.jpg

Stel nu even dat deze afbeelding nog niet bestaat? Iedereen weet dat met wat .htaccess magie kan je url’s herschrijven zoals dit gewoonlijk gedaan word bij het Zend framework. Dus ook deze url zal worden herschreven en word dus doorgegeven aan het Zend framework waarna jij via de controller images met een actie thumbs deze informatie kan opvragen en de benodigde thumbnail kan maken. Je kan deze functionaliteit ook verder uitbreiden naar bijv. iets als:

/images/thumbs/an-image-thumb-100×100.jpg

Hiermee zou het mogelijk worden om thumbnails te maken op een specifieke grootte. Dit heeft wel één groot nadeel natuurlijk, de eerste ongelukkige eindgebruiker zal een aanzienlijke tijd moeten wachten voordat alle thumbnails gemaakt zijn. Alle eindgebruikers daarna zullen zelfs niet via Zend moeten passeren om hun afbeeldingen te laden omdat het pad nu wel geldt.

Het volledige artikel dat eigenlijk gaat over een implementatie van het Delegation Pattern kan je terugvinden op de website van mrburly.

// highlight=true is in deze context een "antoniem" voor search=false
// highlight=false is dan een "synoniem" voor search=true
?query=zoek+parameter&highlight=true

Verder kan je deze informatie gebruiken voor zoekmachine optimalisatie, je slaat dan alle zoektermen op in een database en vermeerderd steeds het aantal wanneer deze opnieuw opduikt. Andere mogelijkheden zijn linkbacks.

Voor wie het meer zou zoeken in de richting van interactiviteit kan misschien eens proberen de sessies interactief te maken waarbij jij aanpassingen zou maken en de gebruiker aan de andere kant plots een bericht krijgt dat hij niet langer toegang heeft tot een bepaald deel van de website.