Onjuist gebruik van pre & code element en white-space CSS

In mijn eerdere artikel Code Snippets en Syntax Highlighting in WordPress met correcte HTML heb ik al uitgebreid aandacht besteedt hoe je blokken met code (of normale tekst) exact kunt weergeven op je website zoals je het ook in je code editor gestructureerd hebt, dit met behulp van het pre element.

Alles binnen het pre element wordt namelijk exact weergegeven, inclusief witregels, tabs en spaties die je veelvuldig gebruikt in code snippets. De code is immers niet goed leesbaar als alles achter elkaar staat.

Het pre element is niet specifiek voor code, maar kan bijvoorbeeld ook gebruikt worden voor een gedicht waarbij de witregels, tabs en spaties belangrijk zijn om aan de websitebezoeker te tonen.

Als je niet weet dat het pre element bestaat, dan gaan er gegarandeerd zaken mis. Zo ook bij de ontwikkelaars van de Toolset Bootstrap theme. Dit is een thema waar alle CSS van Twitter Bootstrap 2.3.2 wordt gebruikt, dit gecombineerd met de onwetendheid over het pre en code element hebben de ontwikkelaars er toe gebracht eigen CSS toe te voegen aan hun thema dat alleen maar voor meer problemen zorgde in plaats van oplossingen!

CSS alternatief voor het pre element, white-space!

Met white-space hebben we het natuurlijk over de witruimte, en zoals inmiddels duidelijk kan het belangrijk zijn om dit aan de bezoeker van je website te tonen, bijvoorbeeld bij een blok met code of bij een tekst zoals een gedicht. Het gebruik van het pre element is hiermee afdoende, en veel meer dan dit hebben we eigenlijk niet nodig.

Ondanks dat veel code plaatsen achter elkaar in een code element de code compleet onleesbaar maakt, en je daarvoor dus het pre elementen moet gebruiken, heeft Toolset toch getest wat er dan gebeurd. Toolset kwam erachter dat de CSS van Twitter Bootstrap 2.3.2 hier zorgt voor een probleem, zichtbaar op onderstaande afbeelding.

White-space no-wrap probleem code element

De white-space no-wrap value uit de CSS van Twitter Bootstrap 2.3.2 zorgt voor een probleem bij veel tekst in het code element

Het klopt dat de CSS van Twitter Bootstrap 2.3.2 hiervan de oorzaak is. Normaliter zou dit nooit gebeuren bij het code element. Als je veel tekst plaats in het code element loopt dit normaliter door op de volgende regel: het is namelijk een inline element! Onderstaande afbeelding toont dus het gebruikelijk gedrag van het code element.

Code inline element

Het code element is een inline element en dus gaat tekst gewoon verder op een volgende regel

Hoe kan het dat dit niet meer werkt bij Twitter Bootstrap 2.3.2? Dit is omdat ze in hun CSS gebruik maken van white-space: nowrap (lees meer over de werking van nowrap). De reden dat Twitter Bootstrap 2.3.2 de inline werking van het code element teniet doet is simpel. Zij hebben het code element voorzien van een background en een border. Als het stukje code dan aan het einde van de zin afgebroken wordt, ziet het er simpelweg niet meer uit:

Disable inline behaviour code element

Inline behaviour van het code element zorgt met Twitter Bootstrap 2.3.2 CSS voor een niet zo’n fraai aangezicht

Door de CSS white-space: nowrap toe te voegen, staat het stukje code in zijn geheel op één regel:

Code element white-space no-wrap

Bijgevolg van dit is dat als er grote lappen code in het code element gestopt worden, zoals Toolset Bootstrap getest heeft, dit voor een probleem zorgt omdat alles geforceerd op één lijn blijft en dus buiten de kaders van je pagina terecht kan komen. Dat is natuurlijk niet erg galant, maar zolang je het code element ook daadwerkelijk gebruikt voor kleine stukjes code in je tekst, en het pre element voor grote blokken met code, zal het probleem zich echter ook niet voordoen. De CSS van Twitter Bootstrap 2.3.2 zal dus niet snel voor problemen zorgen bij een juiste toepassing van het code en pre element.

Omdat dit besef nog niet bij Toolset aanwezig was, gingen ze het (niet bestaande) probleem oplossen, zodat de white-space: no-wrap CSS van Twitter Bootstrap 2.3.2 weer ongedaan gemaakt werd:

/* Fix for code line breaks */
code {
white-space: pre !important;           /* CSS 2.0 */
white-space: pre-wrap !important;      /* CSS 2.1 */
white-space: pre-line !important;      /* CSS 3.0 */
white-space: -pre-wrap !important;     /* Opera 4-6 */
white-space: -o-pre-wrap !important;   /* Opera 7 */
white-space: -moz-pre-wrap !important; /* Mozilla */
white-space: -hp-pre-wrap !important;  /* HP Printers */
word-wrap: break-word !important;      /* IE 5+ */
}

Deze fix ging totaal niet samen met goed gebruik van het pre element en zorgde alleen maar voor meer problemen. Wat betreft het code element stond alles wel weer binnen de kaders van de pagina, maar door de background en border zit dat er dus niet uit! Dit is exact waarom Twitter Bootstrap 2.3.2 juist de white-space: nowrap had toegevoegd.

pre-code

In het forumtopic CSS needs improvement heb ik dit voorgelegd en is hun CSS fix op mijn aanraden ook verwijderd uit Toolset Bootstrap versie 1.1 :-).

Natuurlijk hebben ze een punt dat als mensen tóch veel code plakken in het code element ze willen voorkomen dat deze helemaal lang word en buiten de kaders van de pagina komt. Daarom hebben ze een nieuwe fix toegevoegd:

/* Fix for code line breaks */
.entry-content code {
max-width: 100%;
}

Dit werkt als evenmin zoals je hier ziet:

[afbeelding nog toevoegen]

https://wp-types.com/forums/topic/code-line-breaks-fix-not-working/

Ik vraag me sowieso af of het verstandig CSS toe te passen op een class die aanwezig is vanwege hAtom microformat.

Meer informatie white-space:

http://css-tricks.com/almanac/properties/w/whitespace/

http://code.stephenmorley.org/html-and-css/white-space-handling/

Demografische en interesserapporten en WordPress (Analytics.js)

Google Analytics Demografische en interesserapporten inschakelen

Het zal velen die Google Analytics gebruiken niet ontgaan zijn dat ‘Universal Analytics’ de nieuwe standaard is geworden. Maakte de tracking code van Google Analytics voorheen gebruik van ga.js, in de nieuwe standaard is dit analytics.js. De upgrade bestaat simpelweg uit de nieuwe Google Analytics tracking code in WordPress implementeren.

Waarom upgraden naar Analytics.js?

Ik quote:

Wanneer u de upgrade uitvoert, blijft u toegang houden tot uw historische gegevens in dezelfde rapporten die u momenteel gebruikt, maar beschikt u ook over het volgende:

  • Aangepaste dimensies en statistieken
  • Nieuwe trackingcode
  • Meer rapportagefuncties

Universal Analytics moet binnenkort worden gebruikt voor alle Google Analytics-property’s. Property’s die niet worden overgezet, worden in de toekomst automatisch overgezet naar Universal Analytics.

Zie ook hier de voordelen van upgraden naar Universal Analytics. Op die pagina vind je ook een tijdlijn, en dit maakt duidelijk dat ze nu ook bezig zijn met het automatisch omzetten van ga.js naar analytics.js, mocht je de upgrade zelf nog niet uitgevoerd hebben.

Dat voordelen beloven veel goeds… dacht ik! Ik kwam er echter achter dat de Demografische en interesserapporten in Google Analytics niet werkten met deze nieuwe trackingscode, zie mijn bericht van 15 februari 2014.

Het moge duidelijk zijn, ik was me ervan bewust dat om de Demografische en interesse rapporten in te schakelen, ik eenmalig een wijziging in de tracking code moest aanbrengen. De documentatie ging echter nog steeds uit van het oude tracking systeem via ga.js, en daarmee was het dus onmogelijk om dit in orde te maken voor mijn website die reeds de upgrade had gedaan naar analytics.js.

Nu is het echter wel ondersteund, en ik leg je hieronder stap voor stap uit hoe je de Demografische en interesserapporten kunt inschakelen.

Allereerst klik je op de blauw button ‘Inschakelen’.

Google Analytics Demografische en interesserapporten inschakelen

Google Analytics Demografische en interesserapporten inschakelen

Vervolgens krijg je de melding dat je eenmalig de tracking code moet aanpassen, je moet namelijk ‘display-advertenties’ gaan ondersteunen. Dit klinkt misschien raar, maar de rapporten zijn dezelfde demografische en interessecategorieën waarmee advertenties worden getarget in het Google Display Netwerk! Binnen Analytics kun je deze informatie over uw gebruikers dus ook gebruiken om de strategieën voor advertentiecampagnes te verfijnen. De inmiddels up-to-date documentatie vind je in het artikel Uw Google Analytics-trackingcode bijwerken om display-advertenties te ondersteunen.

Nadat je de wijziging van code hebt geïmplementeerd op je website, kun je de tracking code valideren door op de blauwe button ‘Trackingcode valideren’ te klikken. Heb je een WordPress website, lees dan snel verder, want dan hoef je de code niet zelf te wijzigen.

Google Analytics trackingcode valideren

Google Analytics trackingcode valideren

Demografische en interesserapporten activeren in WordPress

Heb je eenmaal de demografische en interesserapporten ingeschakeld in Google Analytics, dan hoef je de vereiste wijziging in de tracking code niet zelf door te voeren als je gebruik maakt van de Google Analytics by Yoast plugin. Deze plugin zet de tracking code automatisch in je website zonder dat je zelf aan de slag moet met het header.php of functions.php bestand in WordPress.

Om de wijziging in de tracking code door te voeren is het simpelweg een instelling veranderen in de plugin, die is toegevoegd per 4 september 2014 in versie 5.0.0 van de plugin, zie de changelog.

5.0.0

Release Date: September 4th, 2014

Complete rewrite of the Google Analytics plugin.

Enhancements:
Universal tracking added
Better link tracking
New Universal demographics feature
New menu items in the WordPress admin menu

Zoals op onderstaande afbeeldingen is te zien, hoe je alleen maar naar het juiste tabblad te navigeren en daar twee vinkjes aan te zetten.

Google Analytics by Yoast Demografische en interesserapporten

Universal tracking en Demografische en interesserapporten inschakelen via Google Analytics by Yoast plugin.

Of lees het artikel Enable Demographics and Interest reports in Google Analytics.

YouTube e.a. video embeds in WordPress

WordPress YouTube video te klein

Als je een YouTube of video van een ander videoplatform wilt invoegen (embedden) in je WordPress website, dan gaat dit artikel je zeker helpen.

Embed (YouTube) video in WordPress

Het invoegen van een (YouTube) video in WordPress is erg eenvoudig. Je kunt gewoon de video-url kopiëren en plakken in de WordPress editor van je pagina of post die je aan het bewerken bent. Je moet er alleen op letten dat de link op een eigen regel staat, zoals hier:

Dit is een coole YouTube video: 

[De (YouTube) video-url hier plakken, op een eigen regel!]

Cool toch?

WordPress zet de link vervolgens om in de juiste HTML voor het betreffende videoplatform waar je een video van wilt invoegen (YouTube, Vimeo etcetera). Dit is mogelijk omdat WordPress gebruikt maakt van oEmbed:

The easy embedding feature is mostly powered by oEmbed, a protocol for site A (such as your blog) to ask site B (such as YouTube) for the HTML needed to embed content from site B.

Alle videoplatformen die ondersteund worden en meer informatie over deze functionaliteit van WordPress vind je in het WordPress Codex artikel Embeds.

Veel voorkomende problemen met video’s in WordPress

Zoals we hierboven hebben uitgelegd is het erg eenvoudig om een YouTube (of andere) video toe te voegen in WordPress. Dan is het tijd om het resultaat te bekijken op je website. Bij mij zag dit er als volgt uit:

YouTube WordPress video te groot

Op deze pagina is de YouTube video in WordPress te groot, de breedte van de pagina (zie tekst onder de video) is kleiner dan de video zelf.

WordPress YouTube video te klein

De YouTube video in WordPress is te klein ten opzichte van de breedte van de pagina (kijk maar naar de tekst!).

Wat zien we nou op bovenstaande afbeeldingen?

De YouTube video die we zojuist hebben ingevoegd passen zich duidelijk niet aan naar de breedte van de pagina is waar ze worden ingevoegd. Zoals we weten uit voorgaande uitleg zet oEmbed onze YouTube link die we in de WordPress editor geplakt hebben om in de juiste HTML op de website. Als we daar naar kijken zien we het volgende:

<iframe src="http://www.youtube.com/embed/ZR8oXE9feDk?feature=oembed&amp;wmode=opaque" width="770" height="433" frameborder="0" allowfullscreen="allowfullscreen"></iframe>

Uit de code blijkt dus dat de video altijd een fixed width heeft van 770 pixels. Dat gaat niet werken! Op mijn pagina van 940 pixels breed (zonder sidebar) is de YouTube video te klein, en op mijn pagina van 620 pixels (met sidebar) breed is de YouTube video te klein zoals we reeds zagen op mijn afbeeldingen.

Het blijkt echter dat de oEmbed functionaliteit wel prima rekening houden met hoe breed een pagina is om de (YouTube) video vervolgens dus “full width” in te kunnen voegen. Je thema moet dan deze “content width” wel gespecificeerd hebben in de code van het WordPress thema, dit wordt uitgelegd in het artikel How to Set oEmbed Max Width in WordPress 3.5 with $content_width. Met de code die in dit artikel aangedragen wordt kun je echter maar één breedte aangeven in pixels. Dit is voor mij geen oplossing omdat mijn “content width” voor de pagina zonder sidebar 940 pixels is, en voor de pagina’s met sidebar 620 pixels. Ik moet dus een oplossing hebben waarbij de video’s altijd 100% de breedte hebben van de pagina.

Responsive (YouTube) video plugin

Gelukkig ben ik niet de enige die YouTube video’s wil invoegen die zich automatisch aanpassen naar de breedte van de pagina. Dit kan belangrijk zijn als je, zoals in mijn geval, pagina’s hebt met verschillende breedtes. En ook bij responsive of fluid websites zijn de paginabreedtes continue anders. De oplossing is de Advanced Responsive Video Embedder plugin. Door toepassing van slimme CSS en Javascript zorgt deze plugin ervoor dat de video’s altijd op volledige breedte van desbetreffende pagina wordt weergegeven. Natuurlijk zijn er ook nog andere alternatieven die je bijvoorbeeld in het lijstje 16 Cool Responsive WordPress Plugins for Images and Videos kunt vinden.

Google+ pagina koppelen aan je WordPress website

Onlangs, bij het nalopen van de mogelijkheden in de WordPress SEO plugin, kwam ik via ‘social’ terecht bij onderstaande optie (rood gemarkeerd).

Google bedrijfspagina koppelen via WordPress SEO plugin

Google bedrijfspagina koppelen via WordPress SEO plugin

De plugin biedt mij de mogelijkheid, als ik een Google+ pagina heb, deze in te vullen. De vraag is echter, waarom zou ik dit willen doen?

Waarom een Google+ pagina koppelen aan je website?

Het antwoord verwacht ik vervolgens te vinden in het artikel WordPress SEO, The Definitive Guide To Higher Rankings For WordPress Sites op de website van Joost, maar helaas kon ik er niets over vinden. Na een korte e-mailwisseling met de supportafdeling van Yoast, is het gelukkig toch snel duidelijk geworden.

Willem-Siebe Spoelstra: Ik wil even het volgende aangeven. In de WordPress SEO plugin staat onder social het Google+ tabblad, daar staat vervolgens dit: Als je een Google+ pagina voor je bedrijf hebt, vul dan hier de URL in en link het op je Google+ Over Mij pagina. Ik kan echter nergens documentatie vinden wat dit doen en waarom ik dit moet doen.

Taco Verdonschot: Google+ biedt de mogelijkheid voor bedrijven om een Google+ bedrijfspagina aan te maken. Zo’n pagina heeft een eigen link die te vinden is op de ‘Over mij’-pagina van uw Google+ bedrijfspagina. Deze link kunt u vervolgens invullen in de plugin.

Willem-Siebe Spoelstra: Bedankt voor je reactie, maar ik ben er niet mee geholpen. Het punt is juist het gebrek aan documentatie waarom ik deze link in moet vullen. Wat gebeurd er als ik deze link invul en welk SEO voordeel heeft dit. Nergens in de plugin of op de website van Yoast (The definitive Guide) lees ik hier iets over. Wellicht dat ik er zo over heen lees hoor, maar ook dan hoor ik dat natuurlijk graag.

Taco Verdonschot: Je hoeft hem niet in te vullen hoor :) Het betreft hier publisher highlighting, https://support.google.com/webmasters/answer/1708844?hl=en. Naast dat je Google meer vertelt over je bedrijf als je je Google+ bedrijfspagina hebt ingevuld en gelinkt aan je website, is er de mogelijkheid dat Google je bedrijf uitlicht zoals gedaan met het blokje van Philips aan de rechterkant hier https://www.google.com/search?q=philips. De waarde voor SEO is dus:
Google kan zijn zoekresultaten beter afstemmen op de zoeker als ze meer info over je bedrijf hebben en je kunt uitgelicht worden en valt dan natuurlijk veel meer op in de zoekresultaten. Ik hoop dat dat je vraag beantwoord.

De Google+ koppeling achter de schermen

Wat gebeurt er nou exact als je deze link invult in de WordPress SEO plugin? Het doet niets meer en minder dan een stukje code toevoegen in het head gedeelte van je website.

Publisher link element in head gedeelte website

Publisher link element in head gedeelte website

Maar wat valt mij op als Google mij vraagt om deze koppeling te maken, een ander stukje code! Zie onderstaande afbeelding.

Je website koppelen aan je Google+ pagina

Je website koppelen aan je Google+ pagina

Ook via de pagina Google+ Pages waar de supportafdeling van Joost eerder naar refereerde, lees ik niets over de methode die gebruikt word in de WordPress SEO plugin. Pas na lang zoeken kwam ik eindelijk op een developers pagina van Google over de Google+ badge de gekozen methode tegen, zie onderstaande afbeelding.

Methode koppeling WordPress SEO op Google

Methode koppeling WordPress SEO op Google

Heeft de ene methode voorkeur boven de andere? Nee. Zie mijn forumtopic Connect website to Google+ page. Kun je controleren of de koppeling werkt? Ja! Ga naar de Tool voor gestructureerde gegevenstests, vul je URL in en controleer of je onderstaande opmerking ziet.

Google+ koppeling geverifieerd door Google Rich Snippet tool

Google+ koppeling geverifieerd door Google Rich Snippet tool

Gebruik géén nofollow links op je eigen website!

De rode lijn in alle video’s van Matt Cutts over het gebruik van nofollow links op je eigen website, is om dat niet te doen! In onderstaande video’s komen alle voorbeelden wel aan bod zoals:

  • links naar je login pagina;
  • links naar je winkelwagen pagina;
  • links naar je privacybeleid;
  • links naar je algemene voorwaarden.

Video van 01-05-2009:

Video van 29-06-2010:

Video van 22-04-2011:

Video van 30-09-2013:

Verschil tussen inline en inline-block!

display:inline-block

Wel eens afgevraagd wat het verschil is tussen display:inline, display:block en display:inline-block?

In woorden, inline vs block vs inline-block

Gevonden via Google: CSS display: inline vs inline-block.

Inline elements:

  • respect left & right margins and padding, but not top & bottom;
  • cannot have a width and height set;
  • allow other elements to sit to their left and right.

Block elements:

  • respect all of those;
  • force a line break after the block element.

Inline-block elements:

  • allow other elements to sit to their left and right
  • respect top & bottom margins and padding
  • respect height and width

Visueel, inline vs block vs inline-block

Gevonden via Google: What is the difference between display: inline and display: inline-block?.

Imagine a <span> element inside a <div>. If you give the <span> element a height of 100px and a red border for example, it will look like this with…

Inline elements:

display:inline

display:inline

Block elements:

display:block

display:block

Inline-block elements:

display:inline-block

display:inline-block

Verborgen tekst en links, niet slecht voor SEO!

Lees meer link niet erg voor SEO

Het verbergen van tekst en links is een veelgebruikte manier van vroeger om de zoekresultaten in Google te manipuleren. Simpelgezegd, in de broncode van de website is allerlei tekst (keyword stuffing) en/of links aanwezig die je niet toont aan de normale bezoeker! Voorbeelden: BMW (2006), Alex Chiu (2007).

Echter, er zijn natuurlijk ook veel situaties denkbaar waarbij het verbergen van tekst en/of links een functie heeft. De tekst en/of links worden op enig moment zichtbaar, vaak na een actie van de websitebezoeker (mouse-over, mouse-click). Geen kwade bedoeligen dus! Denk bijvoorbeeld aan:

  • dynamische navigatie;
  • lees meer, lees minder link/button;
  • diverse tabs, veelgebruikt in ecommerce websites.

Maar je wilt natuurlijk wel dat Google dit allemaal gewoon netjes crawlt en indexeert! Met het misbruik van verborgen tekst en links nog in ons achterhoofd, is het natuurlijk interessant om te weten hoe Google hier mee om gaat.

Verborgen tekst en links, manipulatie versus legitiem…

Google geeft in het artikel Verborgen tekst en links een aantal voorbeelden. Belangrijker is echter dat Google aangeeft dat niet alle verborgen tekst als misleidend wordt beschouwd. Het punt dat gemaakt wordt is dat je site simpelweg geen tekst en/of links mag bevatten die alleen voor de zoekmachine zijn bedoeld (manipulatie) en dus nooit zichtbaar zal zijn voor de bezoeker. Onderstaande mag dus niet.

Tekst (zoals overmatig veel zoekwoorden) kan op verschillende manieren worden verborgen, zoals:

  • Witte tekst gebruiken op een witte achtergrond
  • Tekst achter een afbeelding plaatsen
  • CSS gebruiken om tekst buiten het scherm te plaatsen
  • De tekengrootte instellen op 0
  • Het verbergen van een link door een link in te stellen via een klein teken, zoals een streepje in het midden van een alinea

In onze eerder genoemde voorbeelden is er geen sprake van dat we de zoekresultaten willen manipuleren, en Google zal deze verborgen tekst dus gewoon crawlen en indexeren. Ben je daarvan nog niet overtuigd? Lees dan eens Eric Enge Interviews Google’s Matt Cutts. Daar geeft Matt Cutts aan dat met gebruikelijke webdevelopement technieken, zoals dynamische navigatie, geen problemen hebben.

Eric Enge: Right. Are there hidden text scenarios that are harder for you to discern whether or not they are spam versus something like showing just part of a site’s terms and conditions on display, or dynamic menu structures? Are there any scenarios where it’s really hard for you tell whether it is spam or not?

Matt Cutts: I think Google handles the vast majority of idioms like dynamic menus and things like that very well. In almost all of these cases you can construct interesting examples of hidden text. Hidden text, like many techniques, is on a spectrum. The vast majority of the time, you can look and you can instantly tell that it is malicious, or it’s a huge amount of text, or it’s not designed for the user. Typically we focus our efforts on the most important things that we consider to be a high priority. The keyword stuffed pages with a lot of hidden text, we definitely give more attention.

Andere voorbeelden waarbij de hoeveel tekst niet past in het design van de website zijn de ‘lees meer’ links of de tabs. Een voorbeeld van de lees meer link met verborgen tekst zie je op onderstaande afbeelding.

Lees meer link niet erg voor SEO

Lees meer link niet erg voor SEO

Ook hier zijn gerustellende woorden van Matt Cuts te vinden op het World Wide Web, en wel in de vorm van een video.

Techniek voor het verbergen van tekst (toggling content)

Zelf maak ik momenteel gebruik van Twitter Bootstrap 2.3.2, en interessant om te zien is dat zij reeds twee classes beschikbaar stellen voor het tonen en verbergen van tekst, namelijk .hide en .show. Zie het bestand utilities.less.

// Toggling content
.hide {
  display: none;
}
.show {
  display: block;
}

In beginsel is het de juiste manier om via CSS met display: none; de tekst tijdelijk te verbergen. Hiermee verberg je de tekst visueel, voor de normale webbrowser gebruikers. Je verbergt de tekst hiermee ook voor mensen die gebruik maken van AT (afkorting voor Assistive Technology of Adaptive Technology), zoals screenreaders. Ook slechtziende of blinde mensen met een screenreader zullen dus pas de extra tekst lezen als zij op de ‘lees meer’ link geklikt hebben. Zo hebben alle gebruikers dus een zelfde ervaring.

Vanaf Twitter Bootstrap 3.0.1 is .hide vervangen door .hidden.

// Hide from screenreaders and browsers
//
// Credit: HTML5 Boilerplate

.hidden {
  display: none !important;
  visibility: hidden !important;
}

In het artikel How to: Hide Content wordt uitgelegd dat de toevoeging van visibility: hidden noodzakelijk is omdat sommige screenreaders display: none negeren.

Om de tijdelijk verborgen tekst zichtbaar te maken wordt via Twitter Bootstrap gebruik gemaakt van display: block. Ook dit is de juiste methode, maar schijnt volgens Yahoo in het artikel Accessible Solutions For Hiding Content niet voldoende gebruiksvriendelijk te zijn voor de screenreader gebruikers, zie onderstaande quote.

Now that you know how to use display:none to completely hide your panels. You need to do more than convert their display to block for accessibility.

Ian Pouncey’s article on the accessibility built into into the tabbed modules on the Yahoo! Home Page, Accessible Tabs in the new Yahoo Homepage –recreated with YUI3 and WAI-ARIA, shows you how to use YUI3 to handle the different events that hide/display the correct content, as well as allow screen readers to know how the page has changed.

Hebben we toch nog iets om te bestuderen voor een volgend artikel!

Factureren voor de webwinkelier

Een factuur versturen. Elke webwinkelier kan hier mee te maken krijgen. Maar wanneer ben je nou verplicht om een factuur te sturen, en aan welke eisen moet deze voldoen? Wanneer verstuur je de factuur? Bij de orderbevestiging, of pas achteraf? Allemaal relevante vragen die ik graag beantwoord zie. Op ontdekkingstocht dus.

Wie zijn verplicht te factureren?

De belastingdienst legt het gelukkig uit op de pagina ‘Wie zijn verplicht te factureren‘.

U maakt een factuur op voor alle goederen en diensten die u levert aan andere ondernemers. Ook rechtspersonen die geen ondernemer zijn (ook buitenlandse), stuurt u een factuur. Dit kunnen bijvoorbeeld zijn: verenigingen en stichtingen.

Verkoopt u goederen of diensten aan particulieren? Dan bent u niet verplicht een factuur uit te reiken…

Lever je als webwinkel dus aan ondernemers en/of rechtspersonen, dan zul je moeten factureren. Lever je alleen goederen aan particulieren, dan hoeft dit niet. Neem wel even notie van de uitzonderingen op de eerder benoemde pagina van de belastingdienst!

Factuureisen

Ook dit heeft de belastingdienst keurig uitgelegd, zie de pagina ‘Factuureisen‘.

  • uw volledige naam en die van uw afnemer
    U vermeldt de juridische naam. De handelsnaam mag ook, als die in combinatie met het adres en woonplaats bij de Kamer van Koophandel is geregistreerd. Bij fiscale eenheden is het gebruikelijk dat de naam van het onderdeel dat de prestatie levert op de factuur staat.
  • uw volledige adres en dat van uw afnemer
    U vermeldt het adres waar de onderneming feitelijk is gevestigd. Vermelding van alleen een postbusnummer is niet voldoende.
  • uw btw-nummer
    Bij fiscale eenheden is dat het btw-nummer van het onderdeel dat de prestatie levert.
  • uw KvK-nummer
  • de datum waarop de factuur is uitgereikt
  • een uniek volgnummer
  • een omschrijving van de goederen of diensten die u hebt geleverd
  • het aantal geleverde goederen of diensten
  • de datum waarop de goederen of diensten zijn geleverd, of de datum van een vooruitbetaling
  • het bedrag dat u in rekening brengt, exclusief btw
    Levert u prestaties met verschillende btw-tarieven? Vermeld dan de aparte bedragen. Neem daarnaast de eenheidsprijs op, als dit van toepassing is.
  • het btw-tarief dat u in rekening brengt
  • het btw-bedrag

Deze spreken allemaal aardig voor zich, behalve onderstaande.

de datum waarop de goederen of diensten zijn geleverd, of de datum van een vooruitbetaling

Het is niet ongewoon dat een webwinkelier, ongeacht de betaalwijze, pas een order verstuurd zodra de betaling binnen is. Uiteindelijk kwam ik dus tot de conclusie dat we in die situatie altijd met een (volledige) vooruitbetaling te maken hebben. Als een klant echter kiest voor de betaalwijze per bankoverschrijving, dan is de datum van vooruitbetaling uiteraard nog onbekend. Dit zou dus ook inhouden dat het niet mogelijk is als webwinkel de factuur reeds bij de orderbevestiging mee te sturen. Dat blijkt (gelukkig) niet juist te zijn.

Het antwoord krijg ik op een thread die ik gestart ben op Higherlevel: ‘Wanneer (welk moment) factureren in geval van webwinkel?‘.

Soms is het handig om gewoon even op de wettekst terug te vallen:

34g. De factuur wordt uitgereikt uiterlijk op de vijftiende dag van de maand volgende op die waarin de goederenlevering of de dienst is verricht. In geval van vooruitbetalingen als bedoeld in artikel 34c, eerste lidartikel 34c, eerste lid, onderdelen d en e, moet de factuur telkens worden uitgereikt vóór het tijdstip van de opeisbaarheid daarvan.

Artikel 35a
1 Op de factuur zijn de volgende vermeldingen verplicht:
a. de datum van uitreiking van de factuur;
(…)
g. de datum waarop de goederenlevering of de dienst heeft plaatsgevonden of voltooid is of de datum waarop de in artikel 34c, eerste lidartikel 34c, eerste lid, onderdelen d en e, bedoelde vooruitbetaling is gedaan, voor zover die datum vastgesteld is en verschilt van de uitreikingsdatum van de factuur; (…)

De wet bepaalt geen vaste uitreikingsdatum, slechts een uiterste datum. Eerder mag dus ook, maar het kan wel de verschuldigdheid van de btw (en het moment van teruggaaf voor de afnemer) beïnvloeden. Het gaat hier om een vooruitbetaling, waarbij de datum nog niet is vastgesteld danwel niet verschilt van de uitreikingsdatum van de factuur, dus hoeft die datum niet te worden vermeld.

En ook WikiPedia geeft in hun artikel over de factuur aan:

De factuur kan verzonden worden voorafgaand of na de feitelijke levering. Is het eerste het geval dan spreekt men van voorfactureren, in het tweede geval van nafactureren.

Er kan bij vooruitbetalingen echter ook gekozen worden een pro-forma factuur volgens WikiPedia:

De pro-formafactuur wordt vaak, voordat een en ander geleverd wordt, gebruikt bij vooruitbetalingen, waarna de afrekening gebeurt middels de factuur.

Maar als ik weer terugval op de wettekst, dan is een pro-forma factuur helemaal niet mogeijk bij vooruitbetalingen. In artikel 34g staat immers:

In geval van vooruitbetalingen als bedoeld in artikel 34c, eerste lid, onderdelen d en e, moet de factuur telkens worden uitgereikt vóór het tijdstip van de opeisbaarheid daarvan.

De uitleg van deze wettekst over vooruitbetalingen is in normaal Nederlands als volgt:

Bij vooruitbetaling moet je een factuur uitreiken vóór de uiterste betalingstermijn.

Komen wij dus overeen dat ik vóór 1 december bedrag X moet hebben (aan)betaald, dan moet jij mij
vóór 1 december een factuur sturen voor deze vooruitbetaling, die op 1 december opeisbaar (= invorderbaar ) wordt.

Digitaal factureren

We hadden het reeds over het meesturen van de factuur bij de orderbevestiging. Dit is echter om een andere reden niet vanzelfsprekend. De afnemer moet namelijk akkoord gaan met de digitale factuur. Dit kan op meerdere manieren. Vooraf overleggen is een mogelijkheid. Ook kun je gewoon de factuur versturen, en bij betaling kun je er vervolgens vanuit gaan dat de klant akkoord is met het ontvangen van digitale facturen.

Ondernemer in Business adviseert het op te nemen in de algemene voorwaarden, waar de winkelende klant mee akkoord gaat alvorens de order te plaatsen. Zie het artikel ‘Elektronische factuur: voordelen en voorwaarden‘.

Benoem digitalisering in algemene voorwaarden: Nog voordat de factuur de deur uit is gegaan, moet de klant akkoord zijn gegaan met de algemene voorwaarden. Wanneer je besluit (enkel) digitaal te factureren, moet je dat in de voorwaarden opnemen zodat de klant hier vooraf kennis van kan nemen.

Automatisch facturen in je WordPress/WooCommerce webwinkel

Ben je het zat om voor elke bestelling zelf een factuur op te maken, en maak je gebruik van de WordPress plugin WooCommerce om je webwinkel draaiende te houden? Dan kan ik je gratis plugin WooCommerce PDF Invoices & Packing Slips van het WP Overnight team van harte aanbevelen. Naast het feit dat je in staat bent om je eigen templates te maken voor de facturen kun je op hun website als aanvulling op de gratis plugin ook nog Premium templates vinden.

You do not have sufficient permissions to access this page

Nadat ik een plugin van WooThemes had geïnstalleerd kon ik niet van start gaan met de geplande werkzaamheden. Ik werd namelijk geconfronteerd met onderstaande melding toen ik de plugin settings page wilde bezoeken.

You do not have sufficient permissions to access this page.

De WooThemes helpdesk hebben mij fantastisch geholpen, en ik deel hier graag de mogelijke oplossingen van het probleem.

De eerste oplossing die bij mij niet geholpen heeft:

This behavior is caused by a bug in the WordPress core that can also affect other plugins. Changing the authorization keys from their default value is the safest way to avoid potential problems. Please first change the four authorization keys on your wp-config.php to something else. You can use the following link to create a set of four random keys ready to be pasted into your wp-config.php: https://api.wordpress.org/secret-key/1.1/salt/. Changing these keys will cause all logged in users to be logged out, forcing them to log in again the next time they access your blog. Other than that, there are no ill effect.

Het probleem bleek toen ook wel iets groter te zijn en niet aan de plugin te liggen. Ik had namelijk ook geen toegang meer tot de berichten in WordPress.

I can see that WordPress’ built-in WordPress Dashboard, Posts, Posts screen is unavailable also. It should also be available by visiting this URL: http://[domeinnaam].nl/wp-admin/edit.php. I have deactivated all plugins, and the WordPress Dashboard, Posts, Posts screen still doesn’t show. Do you have any custom code in your theme (or another file) that is customising the permissions of WordPress’ built-in posts? The [plugin-name] screen uses the same permissions as the “posts” screen, so until the user has permissions to access normal posts, they won’t be able to access the [plugin-name] screen. This problem isn’t being caused by the [plugin-name] plugin, so you’ll need to identify what is causing WordPress’ built-in “Post” screen from not being available.

Gelukkig stond ik er niet alleen voor, want de support van WooThemes bleef zoeken naar het probleem. En onderstaande was in mijn geval de simpele oplossing.

I just went to http://[domeinnaam].nl/wp-admin/users.php, and changed the “[username]” role to Administrator. This reset the permissions on that user account, and it is now able to access WordPress’ posts feature. This also means that it is now able to access the [plugin-name] section. One of your other plugins must have somehow broken the user permissions for your user account.

Git op Windows installeren

Bijna iedere webdeveloper weet inmiddels van het bestaan van Git. Ermee werken is een ander verhaal. Gelukkig is er het boek Pro Git dat gratis te downloaden is vanaf de Git website. Dit boek is ook in het Nederlands beschikbaar. Stap 1 om met Git aan de slag te gaan is om Git op je computer te installeren.

Voor Windows is er een installatieprogramma beschikbaar, Git for Windows. Volgens het eerder genoemde boek is installeren heel makkelijk.

Je hoeft alleen maar het installatieprogramma te downloaden van GitHub, en het uit te voeren

Tijdens de installatie wordt je echter met een aantal keuzes geconfronteerd waar je geen verstand van hebt, en wat bovendien niet in het boek wordt uitgelegd. Uiteindelijk heb ik ervoor gekozen de stappen en keuzes te volgen van een BeanStalk artikel, zie Installing Git of onderstaande afbeelding.

Git op Windows installeren

Git op Windows installeren

Mocht iemand nog op- of aanmerkingen hebben op bovenstaanden, dan hoor ik dat uiteraard graag!