Category: Web programming

Migrate your (former) Skematik theme framework to Twitter’s Bootstrap 3: Instructions for theme developers

At Jamedo Websites we work with the Skematik Theme(work) to build responsive websites. Unfortunately the website was down for a while and Skematik use Twitters Bootstrap 2 only. Cause we need a new version of Skematik i start to migrate it to TB3. You will find this new version on: https://github.com/bassjobsen/jamedo-bootstrap-start-theme.

To use the theme work to build your own child theme use the instruction below:

  1. download from: https://github.com/bassjobsen/jamedo-bootstrap-start-theme/archive/master.zip
  2. copy the content of this .zip to the folder skematik in the wp-content/themes folder (the zip file creates the folder “https://github.com/bassjobsen/jamedo-bootstrap-start-theme/archive/master.zip” you have to rename this to “skematik” )
  3. (search and) replace all “span*” classes in your theme files with “col-lg-*”, see also: http://stackoverflow.com/a/17890898/1596547
  4.  fix all other points (general issues should be send by email to bass@w3masters.nl or send as a pull request to https://github.com/bassjobsen/jamedo-bootstrap-start-theme )

Basic setup for your child themes:

Read: http://codex.wordpress.org/Child_Themes#How_to_Create_a_Child_Theme. So basically create style.css in your child theme folder. Start this file with: @import url("../skematik/style.css");

Learn more about Bootstrap 3

Bootstrap 3 don’t have a separate responsive CSS file any more.

From now Twitter’s Bootstrap defines three grids: Tiny grid for Phones (<480px), Small grid for Tablets (<768px) and the Medium-large grid for Desktops (>768px). The row class prefixes for these grid are “.col-”, “.col-sm-” and “.col-lg-”. The Medium-large grid will stack below 768 pixels screen width. So does the Small grid below 480 pixels and the tiny grid never stacks.

For this reason the “span*” classes in your theme files are replaced with “col-lg-*” in step 3 above. With “col-lg-*” the grid become horizontal above a screen width of 992px (desktop). Below this screen width elements will stack. To start the stacking at 767px use the “col-sm-*” prefixes instead of “.col-lg-”. Read Twitter Bootstrap 3 breakpoints and grid for more information.

Read Bootstrap your (designer’s) mind  also and ask your designer to deliver different designs for screen widths (from low to high). This will help you to choose the right grid settings.

For other changes read: Migrate your templates from Twitter Bootstrap 2.x to Twitter Bootstrap 3 and http://bootply.com/bootstrap-3-migration-guide.

You will find the official documentation of Twitter’s Bootstrap 3 now on: http://getbootstrap.com/.

Het vak van de webbouwer en online marketeer wordt steeds leuker en uitdagender!

“Het vak van de webbouwer en online marketeer wordt in ieder geval steeds leuker en uitdagender!” dat schreef @qtag_qrcode in een reactie op het artikel    Responsive design, development en content in één flexibele aanpak. Inderdaad refereert hij daarbij terecht aan: 60% van internetverkeer is mobiel (zie het CBS persbericht van 23 oktober). Voor webbouwers is dit inderdaad een uitdaging. Of het ook leuker en uitdagender wordt, browsers, schermresoluties ondersteunen doen we al sinds we websites bouwen.

De benadering van content first is wel nieuw en interessant. En ik zou zeggen uiteraard kunnen we daarbij niet meer zonder de ‘responsive gedachte’. De meeste webbouwers denken bij responsive toch steeds aan de CSS3 media queries. Wat mij betreft zou het (weer) meer de breedte in mogen.

Uitgaande van CSS3 media queries geeft @nielsvanmidden ook als reactie op het bovengenoemde artikel een mooi overzicht van breekpunten. Een breekpunt is een minimale of maximale schermbreedte waarop je de weergave van je site aanpast. Je kunt dat heel strict toepassen, waarbij je je aandacht vooral richt op het device; bijvoorbeeld … pixels breed is een tablet in landscape mode. Een meer flexibelere aanpak wordt voorgesteld in Responsive Design: Why You’re Doing It Wrong. In dat artikel wordt voorgesteld je breekpunten te bepalen op wat je ziet in de browser(s) naarmate je het window verkleint of vergroot. Daarbij wordt dan ook meteen weer aandacht gevraagd voor de ondersteuning voor verschillende browsers. Microsoft ondersteunt media queries bijvoorbeeld pas vanaf IE9.

Hoe je uiteindelijk je breekpunten ook samenstelt in beide benaderingen kun je werken van klein naar groot of andersom. Per breekpunt kan ook de content aangepast worden. Verschillende breekpunten zullen vragen om het weglaten, toevoegen of herpositioneren van content. De contentkeuze wordt moeilijker bij een responsive benadering vanuit schermbreedte i.p.v. het soort device. Want zoals in 11 Reasons Why Responsive Design Isn’t That Cool! (punt 10) wordt aangegeven is het soort apparaat vaak bepalend in de behoefte van de gebruiker. De andere 10 genoemde redenen mogen ook niet onderschat worden. Schalen van plaatjes, elementen verbergen op basis van media queries optimaliseren de laadtijd van de website niet. De laadtijd, juist ook voor de mobiele gebruiker zo belangrijk, wordt overbodig lang doordat onnodige en onnodig grote bestanden geladen worden.

Voor een goede gebruikerservaring lijkt de inzet van media queries op termijn dan ook niet toereikend. Alternatief om toch weer aan de serverkant aan de slag te gaan. Mensen die met WordPress werken zouden bijvoorbeeld eens naar de wp_is_mobile()  functie kunnen kijken. Daarmee is het mogelijk om aan de serverkant vast content te schalen, tonen of juist niet tonen. Ook dit past prima in een content en / of mobile first benadering. Het combineren van client- en serveroplossingen vormt mogelijk een goed compromis tussen een losstaande mobiele website en een volledig op media queries gebaseerde responsive website.

Ook Jamedo Websites bouwt nu, mede op mijn advies, responsive designs op basis van media queries. Dat was reden genoeg om deze benadering nog eens kritsich te bekijken. En hoe ziet jouw website er eigenlijk uit op een mobiele telefoon of tablet? Via Responsinator.com kun je hiervan snel een goede indruk krijgen.

 

Upgrade naar php 5.3

Bijna een jaar geleden (30 juni 2009) kwam PHP 5.3 uit. PHP 5.3 wordt o.a. standaard geleverd bij Ubuntu 10.04 LTS (“Lucid Lynx”). Een upgrade van versie 5.2 gaf enkele problemen, hieronder een samenvatting. Sinds versie 5.3 ondersteunt PHP ook namespaces, juist daarmee hadden daarmee enkelen van de hieronder beschreven problemen voorkomen kunnen worden.

Nieuwe functies
Vanaf versie 5.3 zijn o.a de volgende functies beschikbaar getHostname en lcfirst. Beide functies waren al gedefinieerd in Opensourcecms. De eerste functie is hernoemt. Voor lcfirst is nu het volgende gebruikt:

if (!function_exists('lcfirst'))
{
function lcfirst($string)
{
return strtolower(substr($string,0,1)) . substr($string,1);
}
}

lcfirst() biedt afhankelijk van de lokale instellingen (via setlocale()) ook ondersteuning voor speciale teken zoals ë.

Regular expressions
PHP had altijd een eigen implementatie van Regular expressions (POSIX Regex Functions). Daarnaast kon ook gebruik gemaakt worden van regular expressions zoals die in Perl gebruikt worden (PCRE Functions). Van de laatste was al bekend dat deze vele malen sneller waren. Sinds versie 5.3 wordt dan ook afgeraden nog langer gebruik te maken van de POSIX Regex Functions, zoals ereg() en ereg_match(). Webapplicaties die bijvoorbeeld error level E_ALL gebruiken geven nu een waarschuwing.
Voor de verschillende foutmeldingniveaus in php (instelbaar via error_reporting()) kent php een aantal (voorgedefinieerde) constanten zoals E_ALL (2047). Sinds versie 5.3 komen hier de volgende constanten bij: E_DEPRECATED en E_USER_DEPRECATED. Daarmee kunnen dus de eerder beschreven foutmeldingen ook onderdrukt worden:

error_reporting(E_ALL ^ E_DEPRECATED);

Naast de POSIX Regex Functions worden sinds versie 5.3 nog een hoop meer functies afgeraden, zie hier voor een overzicht.

Wie heeft er straks nog een website?

Onlangs deelde ik de volgende mening met Mathias HD (recent afgestudeerd informaticus uit Vlaanderen); “In de toekomst hebben websites (domeinen) mogelijk steeds meer een samenvat- en doorverwijsfunctie. E.e.a. is al terug te vinden in de (amateur)muziekindustrie. Op de website van een artiest is slechts beknopt informatie te vinden, verder staan foto’s flicker, muziek op myspace en filmpjes op youtube.
Daar kwam ik achter tijdens mijn werkzaamheden aan Jazz Festival Delft.
Terugkoppeling naar de website van deze netwerksites wordt nog maar zelden gebruikt, daarbij zou gedacht kunnen worden overzichten van updates op flicker, myspace, twitter, etc. bijvoorbeeld via rss. De website wordt dan een samenvatting van wat elders te vinden is.
Als je deze lijn doortrekt kun je ook afvragen hebben personen in de toekomst
nog een website? Of is een linkedinpagina voldoende of zelfs beter?
Hoe gaan bedrijven daarmee om?
Heb je een webshop? Bouw je die zelf of verspreid je slechts een productfeed
(xml) waarbij de gebruiker zelf de device / shopapplicatie kiest?”

Mathias reageerde hierop met een verwijzing naar: Google Chrome OS is 7 years too late.

Tja….. zelf bouw ik webapplicaties en websites……… hoe lang nog?

En misschien is het nog wel waar ook…..

Vanmiddag wees @birgerjansen mij op een leuke en vooral interessante blog; “Web Applications Should Be Compiled“. Reageren op het artikel kan niet meer. Zelf kan ik nog steeds niet reageren via twitter, dus dan maar op deze manier….

Zelf ontwikkel ik webapplicaties en websites in Opensourcecms.eu, wat is geschreven in PHP. Ontwikkelen gaat inderdaad snel. PHP is helemaal toegesneden op het ontwikkelen voor het web, dus dat biedt zeker voordelen voor ‘ad hoc’ implementaties. Performance issues spelen natuurlijk altijd een rol en in die zin zou compiled code absoluut een verbetering opleveren.

Bij de comments van het genoemde artikel wordt verwezen naar Mongoose. Mogoose is een webserver, m.i. in eerste instantie te vergelijken met bijvoorbeeld Jetty. Er van uitgaande dat de gecompileerde webapplicaties, tevens webserver zijn (onder port 80) kan het toch interessant zijn Mogoose nader te bekijken.

Goed stel; ik zou een webapplication framework willen bouwen, wat bij voorkeur ook direct inzetbaar is als CMS, in C of C++, wat zou ik dan nodig hebben. Beginnen ‘from scratch’, is meestal alleen leuker, maar niet per definitie efficiënter. De auteur van het artikel geeft de voorkeur aan C boven C++. Mijn mening is, wanneer herbruikbare code even snel geschreven kan worden als niet herbruikbare code, dan te kiezen voor het eerste. Naast C zou C++ dus zeker een optie zijn.

Zelf heb ik de volgende reeds bestaande projecten kunnen vinden:

Wexus Labs een C++ library voor web application development. Het idee achter Wexus lijkt duidelijk. Verder is mijn indruk dat er na 2006 weinig meer is gebeurd. Veel verder dan een ‘hello world’ wordt dan niet gekomen.

Wt, uitgesproken als ‘witty’, is zeker een interessant project. Wederom een C++ library. Zelf beschrijven ze het als een applicatieserver voor het ontwikkelen en onderhouden van webapplicaties. Goede indruk maakt natuurlijk, dat de site zelf gebouwd is in Wt. Nadere inspectie van de html-broncode wijst wel uit, dat Wt code produceert waarvan de zoekmachines waarschijnlijk niet echt blij worden….. na een korte analyse denk ik dat dit niet simpel op te lossen is. Wt lijkt mij bepalend in de uiteindelijke output. Webapplicaties die werken met en zonder javascript is natuurlijk mooi, maar voor het bouwen van websites is zoekmachineoptimalisatie (voor mij) ook belangrijk.

De meeste indruk maakte CppCMS op mij. Zoals ze zelf zeggen;
“CppCMS is Free C++ Web Development Framework (not CMS) aimed for Rapid Web Application Development“. Het is dan op zichzelf geen CMS, er is wel een implementatie voor database-connectie(sql), sessies en caching. CppCMS lijkt mij een interessant project om binnenkort nog eens beter te bekijken.

Tot slot nog een vraag voor ‘de heren’ van CNOC. Hoe zien jullie de mogelijkheden wat dit betreft voor het ontwikkelen in Free pascal?

Wel of geen indexbestand?

Bij een website is de structuur te vergelijken met een directory- of mappenstructuur op een PC. Op een PC verwacht je bij het opvragen van een directory een lijst bestanden. Bij een website is het net iets anders. De meeste webservers tonen dan een bestand met de naam index.*. Dat kan bijvoorbeeld een .htm, .html of .php bestand zijn.
Op een apache webserver kun je de volgorde aangeven d.m.v. DirectoryIndex in de virtual host configuratie. Eventueel kan de instelling weer ‘overruled’ worden door het plaatsen van een .htaccess bestand in de betreffende directory.

Door deze constructie zullen voor een website /{subdirectory}/ en /{subdirectory}/index.htm verwijzen naar dezelfde content (bestand). Vanuit een zoekmachine gezien kan dit leiden tot ‘duplicate content’. Veel website tonen bij het opvragen van de domeinnaam een menu, waarop ‘home’ bijvoorbeeld verwijst naar /index.htm. Hoewel dit misschien een vreemd voorbeeld is bestaat het risico dat een zoekmachine beide URL’s gaat indexeren en deze vervolgens ziet als ‘duplicate content’.

Op een webserver kan dit worden opgelost door het opnemen van redirect. Dus als /index.* wordt opgevraagd krijgt de bezoeken een redirect naar / of v.v. Op apache is Mod Rewrite hiervoor zeer geschikt. Op Windows-machines is er tegenwoordig voor IIS 7.0+ ook een URL Rewrite Module beschikbaar.

Vraag is nu verwijst je op een website naar de /{subdirectory}/index.* of laat je het index bestand weg. Tot op heden heb ik altijd gedacht je hierin een vrije keuze had. Mij leek de enige voorwaarde consequent zijn. In de laatste versies van Opensourcecms.eu hanteerde ik de volgende strategie. Bij het opvragen van de domeinnaam wordt geen index bestand gebruikt, dus bijvoorbeeld http://www.bhmaat.nl/. Bij het opvragen van een ‘subdirectory’ moet altijd een index.htm gebruikt worden. Bijvoorbeeld: http://www.ingetrokkentepels.nl/nl/home/hoffman_exercises/index.htm. Uiteraard is dit een keuze waarover je kunt twisten. D.m.v. Mod Rewrite zorgde ik dat ‘verkeerde’ bestanden niet kon worden opgevraagd. Indien toch een aanvraag werd gedaan voor /index.htm(l) of /{subdirectory}/ gaf ik een redirect (response code 301) naar het juiste bestand.

De boven beschreven strategie werd niet alleen doorgevoerd in de virtual host configuratie. Opensourcecms.eu zorgde dat ook binnen een website de links klopte. In interne links, menu’s en broodkruimelpaden (breadcrumbs) verwees ‘home’ naar /. Overige links verwezen naar */index.htm. Ook werd dit doorgevoerd in zichtbare html-sitemaps, zoals http://www.lynxen.nl/nl/sitemap/index.htm en ook voor de xml-sitemaps. Een voorbeeld van het laatste is te vinden op: http://www.voedingsbeha.nl/sitemap.gz.

Ondanks dat de beschreven strategie mij correct leek heeft google moeite met het indexeren van de pagina’s die uitsluitend onder *index.htm worden getoond. Google biedt een aantal hulpprogramma’s voor webmasters, hier kun je o.a. jouw xml-sitemap uploaden en deze vervolgens laten analyseren.

Ook al staat in de sitemap aangegeven dat het opvragen van /{subdirectory}/index.htm gewenst is, vraagt de spider van google toch alleen /{subdirectory}/ op. Deze aanvraag wordt door verwezen via een 301 waarop google concludeert dat er sprake is van een doorverwijzing. Concreet leidt dit in de ‘Hulpprogramma’s voor webmasters’ tot een aantal waarschuwingen (gelukkig wordt nog gezien dat het geen fout is):

URL’s niet gevolgd
Tijdens het testen van een aantal URL’s uit uw sitemap hebben we vastgesteld dat bepaalde URL’s de gebruiker omleiden naar een andere locatie. We raden u aan URL’s in uw sitemap op te nemen die naar de uiteindelijke bestemming verwijzen (de bestemming van de omleiding) in plaats van om te leiden naar een andere URL.

Ondanks dat ik deze waarschuwingen niet terecht vind heb ik toch besloten voor de toekomstige versie van Opensourcecms.eu min strategie weer aan te passen. In hyperlinks zullen geen index.* meer voorkomen, index-bestanden kunnen uitsluitend nog opgevraagd worden via een */ request. Oudere versies van Opensourcecms.eu deden dat al. Dergelijke website zoals http://www.seksuelevoorlichting.be/ geven in de ‘Hulpprogramma’s voor webmasters’ van google geen waarschuwingen.

Sinds het begin van dit jaar is de volledige broncode van Opensourcecms.eu te downloaden op http://www.opensourcecms.eu/nl/download_en_installatie/index.htm. De zip-versie zal voorlopige nog de ‘oude’ strategie hanteren. Op de via cvs beschikbare code zullen de wijzigingen z.s.m. worden doorgevoerd. Weirdmaker.be zal de eerste website zijn, die van deze nieuwe aangepaste benadering gebruik zal maken.