WordPress theme ombouwen naar mobiele – responsive versie

 Google heeft ons weer een bang gemaakt met de melding dat websites die vanaf 21 april niet toegankelijk zijn gemaakt voor mobiele apparaten (smartphones, tablets), zullen zakken in de zoekresultaten. Nu heb ik een aantal klanten die heel verstandig hebben geinvesteerd in de vindbaarheid van hun website en veel aandacht hebben gegeven aan zoekwoorden optimalisatie en het zou natuurlijk jammer zijn als die investering voor niets zou zijn geweest. Nu denk ik dat het mogelijk meevalt omdat een positie altijd bepaald wordt door wat de concurrent doet. Dus mijn klant uit Ede (autotransmission) die zijn website optimaliseert voor “revisie versnellingsbak” gaat natuurlijk alleen dalen als de concurrenten ook meegaan in de trend en hun site mobiel toegankelijk of responsive hebben gemaakt. Maar natuurlijk gaat dewebmeester de uitdaging aan om eventueel alle websites van alle klanten om te bouwen naar een responsive versie. Hier aandacht voor het ombouwen van een WordPress theme. Een checklist: Deze lijst zal ik verder uitwerken. Mijn tarief voor het ombouwen van een WordPress theme naar een responsive theme is 4 uur. Dat betekent voor klanten van

Verder lezen

Verschillende stylesheets voor verschillende pagina’s in WordPress

WordPress is nog steeds het meest gebruikte website CMS systeem ter wereld. Verreweg. Maar WordPress is niet flexibel wat betreft layout. Zeker niet in vergelijking tot Joomla. Om layout naar eigen wensen in te vullen, zijn vaak “hacks” nodig in theme bestanden. Daarbij is het dan handig om “snippets” (stukjes code) bij de hand te hebben. Probleem: WordPress gebruikt voor elke pagina hetzelfde theme en daarmee dezelfde stylesheet. Dat is anders in Joomla. Daar is het heel eenvoudig om aan te vinken welke template voor welke pagina of menu items gebruikt moet worden. Een groot gemis in WordPress. Zo zou je bijvoorbeeld voor elke pagina een andere achtergrond afbeelding willen gebruiken of andere kleuren of zoals in mijn geval: een andere “border class” voor de content. Hier een oplossing. Plaats de volgende snippet vlak boven  <?php wp_head(); ?>  binnen header.php file. Snippet: <?php if (is_page(‘contact’)) { ?> <link rel=”stylesheet” href=”<?php bloginfo(‘template_url’); ?>/new-styles.css” type=”text/css”> <?php }; ?> Waar ‘contact’ staat, moet de pagina “slug” worden ingevuld. Om die te achterhalen moeten permalinks op “naam” gezet worden en vervolgens is de slug

Verder lezen

Backup maken van (WordPress) website

Het belang van een backup Het is belangrijk dat u een backup maakt van uw website. Dat moet u niet slechts eenmaal doen, maar iedere keer dat u aanpassingen heeft gemaakt aan uw website en als die aanpassingen tijd hebben gekost. Die tijd wilt u niet verloren laten gaan. Het hebben van een backup wordt steeds belangrijker omdat het aantal hackers toeneemt en daarmee het aantal aanvallen op uw website. Daarnaast heeft u te maken met virussen en spamaanvallen die allemaal er voor kunnen zorgen dat uw website er anders uitziet dan u wilt en de verkeerde informatie biedt of helemaal niet meer beschikbaar is. Ook dewebmeester.nl kent dit. Ik heb het zelfs meegemaakt dat een complete server geleegd werd en daarmee alle websites van die server verdwenen waren. Waar moet een backup van gemaakt worden? Dit laatste laat zien dat een backup op een server niet voldoende is. De server kan ook gehackt worden en alle website bestanden verdwenen zijn. Kortom: een backup moet gedownload kunnen worden en bewaard op een extern medium zoals een (offline) computer, usb stick

Verder lezen

HTML in de post titel van een WordPress website

Mijn vorige artikel ging over de mogelijkheid om de titel van een WordPress post te gebruiken om een video te embedden. Dat lukte. Wat ik toen nog niet wist was dat ik daarmee ook de post pagina (waar het artikel getoond wordt) totaal in de war had gegooid. HTML in de titel van een WordPress post levert allerlei ongewenste bij effecten op. En dus was ik van plan om de vorige blogpost te verwijderen en af te stappen van het idee. Totdat ik de volgende oplossing werkende kreeg: Custom post types om HTML in post titels toe te laten Als eerste heb ik een extra custom post type aan moeten maken binnen de blogpost waar ik html (video embed) code in de titel wil gebruiken. Ik noem die HTML_title en als waarde gebruik ik de code die ik in de titel wil gebruiken: de HTML code. De blogpost zelf krijgt een gewone titel. Vervolgens ga ik naar de editor van het WordPress thema dat ik gebruik en kies de pagina template waarop ik de html titel wil gebruiken. En daar

Verder lezen

Repareren gehackte WordPress website

Vandaag kreeg ik te maken met een WordPress website die was gehackt. Dat wist  ik niet direct. De layout van de website was in de war gegooid en de klant dacht dat het een Bug betrof. En via www.debugmeester.nl of www.tweakweb.nl kom je dan al snel bij mij terecht. Stap 1: Via Firebug de page source bekijken. Dat levert alleen wat op als je hier de pagina per element bekijkt. En dan vooral de gedeelten die vreemd er uit zien. Nog geen enkel teken van een hacker. Gewoon, html, php en css code. Maar de vraag is dan: welke code zorgt voor dit vreemde uiterlijk? In de rechterkolom van firebug kwam ik bij css code terecht die de pagina breedte definieerde op 480px. Dat is wel erg smal. Stap 2: bevindingen in Google stoppen Alles dat vreemd is stop ik in Google om te kijken of anderen met hetzelfde probleem kampen. En ja hoor, er is iemand die precies dezelfde css code aanmerkt als probleem. Deze persoon merkt op dat de css code in de stylesheets nergend te vinden is.

Verder lezen

Van WordPress.com naar WordPress.org, hoe en waarom.

De afgelopen dagen ben ik verhuisd. Van wordpress.com (gehost bij WordPress) naar wordpress.org (zelf gehost). De volgende redenen hebben hierin meegespeeld: Door het WordPress script bij mezelf op de server te plaatsen heb ik toegang tot de code en daarmee tot alles wat mogelijk is binnen de digitale wereld. Een website gehost bij wordpress.com biedt gewoon te weinig extra opties. Het is een mooi maatpak dat kostuum bij wordpress.com maar gewoon iets te strak. WordPress.com laat mij (en u) niet toe om plugins te gebruiken (en tjonge, dan mis je echt veel. Die plugins, waarvan er wekelijks tientallen gepubliceerd worden, maken 80% van het succes van WordPress). WordPress.com laat niet toe om enig javascript te gebruiken binnen een bericht,pagina of widget. En opnieuw: dan kan je heel veel niet. Bijvoorbeeld: ik kan mijn populaire chat script niet plaatsen terwijl mijn (vorige) blog mijn meest bezochte website was en ik daarmee dus een geweldige communicatie mogelijkheid misliep. WordPress.com staat niet toe, technisch en wettelijk, om te adverteren of om geld te verdienen aan advertenties. En dan loop je niet alleen communicatie

Verder lezen

Adsense deel 2: van wordpress naar Blogspot? (blogger.com)

Gisteren heb ik aangegeven om Adsense te willen gaan uitproberen. Ja, reclames kunnen heel vervelend zijn en dat wil ik mijn bezoekers niet aandoen. Dus: mocht u als lezer vervelende reclame tegenkomen op een website van mij, dan zou ik het op prijs stellen als u dat zoudt willen doorgeven. Stap 1: integreren Adsense in website Om se Adsense advertenties te laten verschijnen binnen mijn websites, moest ik wat code plaatsen. Niet alleen html maar ook eens script (logisch). In joomla betekent dat ik gebruik maak van een aparte module die dit mogelijk maakt en die voorkomt dat het script geschrapt wordt. Direct plaatsen binnen een artikel  is niet mogelijk. Via een aparte module wel (insert module). Voorbeeld: zie www.dewebmeester.nl onderaan of www.projektduga.nl aan de rechterkant. Vervolgens heb ik advertentie code geplaatst binnen een startpagina van me op intrastart.nl (webdesign.intrastart.nl). Dat is me gelukt via de categorie beschrijving waar ik de script code direct heb kunnen plaatsen. Wat betreft een zelfgehoste WordPress website zie ik veel verschillende opties. Ik kan bijvoorbeeld een html widget plaatsen met de code (eventueel tussen

Verder lezen

Meerdere gebruikers, 1 website, verschillende opties (WordPress)

Dit is een belangrijk concept en iets dat een webdeveloper in veel situaties nodig heeft: een website die de mogelijkheid biedt aan andere gebruikers (klanten) om zelf een website te onderhouden of te bouwen. Nu lijkt dat makkelijk te realiseren met een (open source) CMS maar algemene probleem lijkt mij dat medegebruikers standaard dezelfde mogelijkheden hebben als de administrator en de andere gebruikers. Bijvoorbeeld: zowel bij Joomla als WordPress hebben mede gebruikers beschikking over dezelfde templates en thema’s als de andere gebruikers. Het is nog niet zo makkelijk om verschillende gebruikers binnen 1 website, verschillende websites te laten bouwen en te onderhouden. Dewebmeester.nl onderzoekt de mogelijkheden en de beste worden op de markt gebracht. Deze week is dat het concept van http://www.mobilewebbuilder.nl : een website waar verschillende gebruikers allemaal verschillende mobiele websites kunnen maken en onderhouden. In mijn vorige blogpost heb ik aandacht gegeven aan een mogelijkheid om een WordPress plugin beschikbaar te stellen aan andere gebruikers zonder hen toegang tot thema’s of posts van anderen te geven. Dat kan werken voor bepaalde plugins maar zal niet voor alle plugins

Verder lezen

Gecontroleerde en beperkte toegang voor gebruik plugin in WordPress

Dit was een nieuwe avontuur voor me. Ik ben bezig met een nieuw concept voor dewebmeester.nl: een online website builder tool waarmee klanten zelf een mobiele website kunnen maken of onderhouden. Dat concept is al aardig uitgewerkt maar hoe geef ik klanten nu beperkte toegang tot het gebruik van deze WordPress plugin? Situatie: Ik heb een WordPress website met verschillende thema’s, plugins, pagina’s enzovoorts. Nu wil ik 1 plugin beschikbaar stellen voor gebruik aan klanten van dewebmeester.nl WordPress biedt standaard eigenlijk maar twee mogelijkheden wat betreft gebruikers: 1) Een gebruiker is een administrator en heeft toegang tot alles of 2) een gebruiker is geen administrator en heeft al dan niet toegang tot de content (blog posts) van de website. Kortom: WordPress biedt standaard niet de mogelijkheid om een gebruiker beperkte toegang te geven tot back -end (dashboard). Je hebt of helemaal toegang, of helemaal niet. Het heeft me wel enige uren geduurd voor ik de oplossing gevonden heb en hem verschillende plugins geprobeerd zoals: – s2members -, – members – en – user role editor – maar die bieden allemaal

Verder lezen