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