Mijn server begon wat vol te lopen en voordat ik ruimte bij wilde kopen ben ik toch eerst maar eens op onderzoek uitgegaan. Het bleek dat mijn backup schijf behoorlijk wat ruimte in nam.. Nu staan daar van alle WordPress websites die ik onderhoud heb, de backups van de databases. Van elke website blijven er 14 bewaard. Op zich niet zo’n probleem, maar wel als sommige databases opeens groot zijn geworden terwijl het aantal berichten op de website niet echt ontzettend groot is. Tijd voor dieper onderzoek. Het bleek dat de options tabel (wp_options – bij standaard instellingen) meer dan 4000 rijen groot was en ook de tabel wp_commentmeta was enorm. In de wp_options stonden vooral veel rijen met _transients en in de wp_commentmeta waren de meeste rijen gevuld met “iets” van Akismet. Klein onderzoek op google gaf al aan dat ik niet de enige was met een exploderende database door de history van Akismet en ook _transients waren geen onbekenden. Alles is op te ruimen via PHPMyAdmin, maar dat is meer voor de meer geoefende gebruiker. Ik ben dus op zoek gegaan naar een plugin om dit op te lossen, want veel sites in onderhoud betekent dan ook even zovele keren inloggen in phpmyadmin en dus ook alle inlogs onthouden Ik vond twee plugins, die helaas net is verschilden op het cruciale punt. Ze is er WP optimize – die de database opruimt, optimaliseert en dat eventueel op gezette tijden doet. WP-optimize haalt de _transients weg, maar doet helaas niets met de Akismet geschiedenis. Een tweede plugin die ik vond, doet dat wel. Dit is WP Clean UP. Deze overlapt dus veel met WP optimize, maar haalt ook alle history uit de wp_commentmeta. Met beide plugins kun je de database daarna optimaliseren. Na een goede opschoonbeurt ging de grootte van mijn database van 60mb terug naar 1,4mb. Een heel verschil is er dus te halen.

HELLUP mailtje van klant. Ze heeft 1 bestand geupload en nu staat er in de mediamarkt niet 1 upload maar 3000 dezelfde plaatjes. Paniek dus. Gelukkig zie ik al gauw dat alle andere plaatjes er ook nog zijn, maar inderdaad van 1 afbeelding lijken er meer dan 3000 exemplaren in de mediabibliotheek te zitten. Gelukkig biedt Twitter dan altijd snel hulp. Ramon Fincken had het probleem al ontdekt en een query geschreven om de database mee op te schonen (op zijn website mijnpress.nl vind je deze query) – maar ook belangrijk was zijn tip om in ieder geval naar de versie van WPML te kijken. En inderdaad, daar stond nog een oude versie. WPML direct geupdate en geregistreerd. Het probleem lijkt te zitten in een combinatie van een niet geregistreerd en/of oude versie van WPML in combinatie met de update naar WordPress 4.0. Iets dus om goed in de gaten te houden. Zolang als WPML niet is geregistreerd volgens de nieuwe methode krijg je ook niet te zien dat er een update is. Je kijkt er dus makkelijk over heen.

Na de update van WPML en het uitvoeren van de queries in de database (waarbij meer dan 4000 records werden verwijderd) bleek nog niet alles weg. De mediabibliotheek was inderdaad helemaal opgeruimd, maar toen ik WPML media wilde vertalen begon hij netjes af te tellen vanaf 4000+ afbeeldingen. Bleek dat er nog heel wat verwijzingen in de database stonden. Gelukkig had ik op die website WP-cleanup en WP-optimize staan. Een eerste sessie leverde niet veel op, maar bij een tweede keer draaien van WP-Cleanup werden opeens 4000+ orhan meta’s gevonden. Deze bleken inderdaad nog in de weg te zitten. Nadat ik ook deze had verwijderd waren alle verdere problemen ook verdwenen.

DE TIP: Heb je WPML geinstalleerd en wil je updaten naar WordPress 4.0 check dan eerste je WPML versie. Zorg dat deze ook wordt geupdate én geregistreerd.

Loop je tegen hetzelfde probleem aan en durf je niet in de database te duiken, neem dancontact op, dan lossen we het samen op.

Via WordPress producten of diensten verkopen kan op meerdere manieren. Heb je echt veel producten, dan is een webshop handig. Wil je slechts één of enkele producten of diensten verkopen dan kan een bestelformulier met bijv Gravity Forms een goede oplossing zijn. Gravity Forms kent productvelden en er zijn verschillende betaalopties aan te koppelen, zoals betaling via iDeal, Paypal of gewoon incasso of overboeking. Het enige waar ik tegenaan liep is dat er bij die producten geen BTW oplossing zit. Een product heeft gewoon één prijs en Gravity Forms telt netjes de prijs van de  aangeschafte producten bij elkaar op en klaar. Geen optie om BTW te berekenen. Maar gelukkig is er een oplossing.

In het formulier heb je twee extra velden nodig. Een “nummer” veld. Hierin ga je het subtotaal berekenen. Dat is even geconcentreerd aan het werk gaan als je meerdere producten via het bestelformulier verkoopt. In het nummerveld zet je berekening aan en je maakt een formule waarbij je van elk product de prijs en aantal met elkaar vermendigvuldigt en daarna de producten bij elkaar optelt dus:

({product1 (Prijs):1.2}*{product1 (Aantal):1.3})+({product2 (Prijs):2.2}*{product2 (Aantal):2.3})+({product3 (Prijs):3.2}*{product3 (Aantal):3.3})

Dit kun je heel simpel in Gravity Forms doen via de “insert Merge Tags” binnen het nummerveld.

Sla nu het formulier op om het subtotaalvak te activeren

Je hebt nu het subtotaal wat nu nog gelijk is aan het totaal. Voor de berekening van de btw voegen we nog een productveld toe. Bij Veldsoort kiezen we voor Calculatie. Via Insert Merge Tags kiezen het veld Subtotaal

{Subtotaal}*0.21

(dit zijn een voorbeeldformules – je moet deze formules zelf samenstellen via de insert Merge Tags, voor de juiste benaming en veldnummering)

Omdat we voor de BTW een productveld hebben aangemaakt, wordt de btw netjes opgeteld bij het totaalbedrag.

Door deze velden in de notificatiemail naar de besteller te gebruiken kunnen we net BTW factuur samenstellen.

Wil je ook een bestelformulier op je website maken en heb je daarbij hulp nodig. Neem dancontact met me op. Ik help je graag.

Soms loop je tegen een probleem aan wat je niet direct kunt thuisbrengen. Zo moest ik in een bestaande WordPress multisite een nieuwe subsite aanmaken. Dit moest een kloon zijn van een al bestaande subsite. Geen punt. Maar wat ik ook probeerde. De kloonplugin weigerde de nieuwe subsite aan te maken. De naam werd geweigerd. Nu was de subsite al een keer aangemaakt, maar ook weer verwijderd. Kennelijk kun je dus niet weer een subsite aanmaken met dezelfde naam, dacht ik en ging in de database op zoek naar wellicht nog een residu van die eerste aanmaak van de subsite. Maar niets. Ook op internet kon ik er niets over vinden. Na een algemene zoektocht in de database viel het kwartje. Er was op de hoofdsite al een pagina met dezelfde naam als de subsite die ik wilde aanmaken. En dat werkt natuurlijk niet samen. De multisite was namelijk als met subdirectories geinstalleerd en nu kwam er een conflict. In de database de post-title en post-name even aangepast en toen kon ik de subsite met de gewenste naam wel aanmaken. Daarna kon ik ook de titel van de pagina weer aanpassen. De slug van die pagina echter niet. Die kreeg netjes een toevoeging.

Wil je dus in een WordPress multisite (met subdirectories) een nieuwe subsite aanmaken. Check dan even of er een conflict is met eventueel al bestaande pagina’s. Als de naam van de subsite nooit in beeld komt (omdat je bijvoorbeeld via domain-mapping daar een domeinnaam aan koppelt) kun je voor je subsites altijd overwegen om er een gecodeerde naam aan te geven. Dan heb je op de hoofdsite later ook geen conflicten met het aanmaken van een pagina die eventueel dezelfde naam zou moeten krijgen als een subsite, zoals hier bij mij nu het geval is.

Bovenstaande kreet hoor ik regelmatig. Als reseller host ik meerdere WordPress websites en de meeste klanten zorgen zelf voor de content op de website. Tekst én plaatjes. En vaak zijn die foto’s leuk, zo van de camera geüpload naar de website. Dat is om meerdere redenen niet echt handig. Ten eerste zijn de foto’s van de huidige camera’s zo groot dat een volledige foto nooit op je scherm past. Daarnaast zijn deze foto’s vaak meer dan 3mb groot en soms wel 7 of 8mb. Een hele serie foto’s neemt dus al gauw heel veel ruimte in beslag. En dat voor iets wat WordPress eigenlijk niet gebruikt, want normaal gesproken maakt WordPress van elke afbeelding die je upload een kopie in een aangepast formaat, zoals thumbnail (150x150px), medium (300x300px) of large (1024x1024px). De originele foto’s zijn handig om eventueel nog te gebruiken om een nieuw formaat aan te maken, maar verder zijn ze eigenlijk overbodige balast op de server.

Nu heb ik zelf twee plugins gevonden die heel handig zijn. De eerste is Resize Image After Upload. Bij deze plugin stel je in wat voor maximale maten de foto’s mogen hebben en WordPress verkleind de geüploade foto naar dat formaat. De originele foto wordt niet op de server gezet.

De tweede plugins is eigenlijk voor website waar al heel wat foto’s op staan die al heel veel ruimte innemen. Dit is de Bulk Resize Media. Deze plugin kan al geüploade images die groter zijn dan een maximaal formaat wat je instelt opsporen en vervolgens verkleinen tot het maximaal opgegeven formaat. Je kunt instellen welke afbeeldingen hij moet verkleinen. Je hebt daarbij de opties voor afbeeldingen die in een pagina of bericht staan, afbeeldingen die zo naar de Media bibliotheek zijn geüpload en afbeeldingen die gebruikt worden als header, achtergrond, logo ed. Je kunt ze allemaal resizen, maar je kunt ook afbeeldingen dus uitsluiten van bulkresize. Daarnaast kun je nadat de plugin afbeeldingen groter dan de afmetingen die je hebt ingesteld heeft gevonden, per afbeeldingen nog aangeven of hij wel of niet geresized mag worden.

Ik heb de laatste plugin nu op een aantal sites gedraaid en al heel wat ruimte op mijn server kunnen winnen.

Er komt een mailtje voor een supportvraag binnen: “Ik heb nieuwe tekst toegevoegd in mijn WordPress website en het ziet er niet uit. Er gebeuren allemaal rare dingen”. Ik ga op de site kijken en zie inderdaad vreemde witruimtes en rare uitlijning in het bericht staan. Als ik in de code ga kijken zie ik allemaal html codes op plekken waar ze niet zouden horen te staan. Zo heeft de website een “container” waarin zowel de content als de sidebar staat, maar de code voor deze container zie ik bij elke regel opnieuw terugkomen. Wat is hier toch gebeurd?

Als ik naar de tekst-editor ga in WordPress dan zie ik daar weer al die codes staan. Kennelijk is dat met het schrijven van de tekst gebeurd. Maar de klant geeft aan de tekst direct in de pagina te hebben getikt en niet vanuit Word of waar dan ook te hebben geplakt. IK kan in ieder geval alle code verwijderen via de teksteditor en ben toch benieuwd hoe de klant heeft gewerkt. Het blijkt dat hij vanaf de website een stuk tekst heeft gepakt en dat in eerste instantie in de editor heeft geplakt en daar alle tekst weer heeft weggehaald en toen is gaan tikken. Eén stukje code is kennelijk blijven staan, dat stukje met de container code, en door naar een nieuwe alinea te gaan met de entertoets heeft die code zich elke keer weer opnieuw gekopieerd. Elke alinea werd zo een container, met de daarbij behorende opmaak. En ja.. dan gaan dingen er vreemd uit zien.

Gelukkig is er een snelle oplossing.

• Controleer bij het plakken van tekst vanuit een ander programma, website of de voorkant van je eigen website, via de teksteditor of er vreemde code in staat. Code herken je omdat het tussen <> staat. De enige code die je er eigenlijk zou moeten zien is de code van de kopteksten, herkenbaar aan <h1>, <h2> en verder. Of wellicht van een tabel, als je die in de tekst hebt staan. Deze is herkenbaar aan <table> en allerlei code die daarna volgt tot </table>. Heb je geen tabel in de tekst gezet en vind je toch deze code, dan klopt dat niet. Of van een opsomming, herkenbaar aan oa <ul> en <li> voor een ongenummerde lijst.
• Verwijder alle code die er niet hoort, dus als je, zoals bij de eerste bullet staat, geen tabel in je tekst hebt staan en toch de tabel code ziet….. verwijderen. Dit alles kan ook via de snelle methodes:
  • Selecteer alle tekst en klik op het gummetje (knop 1) in de tweede knoppenbalk (heb je geen tweede knoppenbalk klik dan op knop 2)
  • Selecteer alle tekst, kopieer de tekst en plak hem vervolgens terug via knop 3, plakken als tekst. Deze knop kun je activeren. Alle tekst die vervolgens geplakt wordt, zal zonder code, als platte tekst geplakt worden.
• Controleer weer via de teksteditor of inderdaad alle code weg is.
• Eventueel de koppen weer opnieuw aanmaken.

En natuurlijk zorgen dat je dit soort problemen voorkomt, door tekst altijd via de “plakken als tekst” knop te plakken.

Blijft de opmaak vreemd en is alle rare code volgens jou uit de tekst verdwenen, dan kijk ik graag even met je mee. Je hoeft dan alleen maar even contact met mij op te nemen.

Voor een WordPress blog was ik op zoek naar een mogelijkheid om bepaalde berichtcategorieën af te schermen voor niet leden en andere categorieën alleen zichtbaar voor bepaalde leden. Ik vond de oplossing met de WordPress plugin Allow Categories. Ik kan hierin per categorie aangeven of de berichten wel of niet publiek zichtbaar zijn of anders welke gebruiker(s) berichten in een categorie mogen zien. Zo kun je dus berichten in een categorie alleen voor leden zichtbaar maken, en zelfs voor een selectie groepje leden.

Zomaar opeens is mijn contactformulier van Grafity Forms verdwenen. Heel vreemd. Het formulier is er nog in de backend en de short-code wordt niet getoond op de pagina. Er is gewoon geen formulier. Dat is even terugdenken en starten met de laatst geinstalleerde plugins maar weer verwijderen. Na een setje verwijderd te hebben is het formulier gelukkig weer terug. Een voor een de plugins weer activeren. Ik had al een beetje een vermoeden. Ik had vorige week een aantal plugins geinstalleerd om de site te optimaliseren en kennelijk werkt dat toch niet zoals zou moeten. De plugin Scripts to Footer blijkt de veroorzaker. Nog even in de settings gekeken en daar zit een optie om de jQuery in de header te laten. Dat aangevinkt en mijn formulier is er weer. Bewijst maar weer eens dat klakkeloos een goed blog volgen over optimalisatie van je website niet altijd het gewenste resultaat heeft.

Een berichtje van een klant. “Ik kan opeens mijn widgets niet meer bijwerken en ik krijg een foutmelding als ik een plaatje wil uploaden.” Dat is vreemd, er is niets aan de website gewijzigd. Tenminste, dat dacht ik. Opeens bedacht ik mij dat het enige wat gewijzigd was was de laatste update van WordPress. Normaal hebben die minor updates weinig of geen effect op WordPress acties zelf, zoals de widgets of media uploads. Dus moest het ergens anders in zitten. Een zoektocht op internet, met wat hulp uit de WordPress groep op Facebook bracht me bij BackWPup. Kennelijk gaat de combinatie met de nieuwste versie van WordPress niet goed. Het uitzetten van BackWPup heeft het gewenste effect. Alles werkt weer. Nu dus wachten op de nieuwe update van BackWPup. Gelukkig is het op de sites die ik onderhoud alleen voor een reserve backups en worden de backups ook met andere systemen gemaakt, zodat backups wel gegarandeerd zijn. Maar heb je dus BackWPup als backup plugin op je WordPress websites en moet je met de widgets werken of media uploaden. Zet hem dan even uit.

Ik loop er wel vaker tegenaan, en met mij wellicht meer…. je bent aan het schrijven en je hebt een beperkte ruimte – een klein blokje bijvoorbeeld –  waar de tekst in moet. Dan heb je de content al beperkt tot een aantal karakters, maar omdat de hele zin wat langere woorden heeft wordt het blok tekst toch hoger dan je had bedacht. Gelukkig zijn er verschillende manieren om de tekst netjes te laten afbreken. Een kleine zoektocht via Google levert twee leerzame links op:

https://www.only-it.nl/blog/12452-tekst-goed-afbreken-in-css-met-text-overflow
https://www.mijn-eigen-website.nl/woorden-afbreken.php