Buggy code blokken

Een hele tijd terug heb ik me al eens bezig gehouden met een manier om de formattering die WordPress toepast, aan te passen en naar mijn eigen hand te zetten. Destijds had ik daar een plugin voor die perfect deed wat ik wou, maar die heb ik toen na een aantal jaren weer uitgezet omdat ik met een schone lei wou beginnen.

In de afgelopen dagen is het regelmatig voorgekomen dat bepaalde regels in code blokken niet goed vertaalt worden. Oplossing dat tussen de pre tag staat met een html encoder vertalen en dan die output gebruiken. Maar omdat voor elk bericht te doen waar ik code nodig heb, vind ik wat omslachtig.

Andere oplossing is om mijn oude Steno plugin weer van stal te halen. Heb een korte test gedaan en voor de code blokjes werkt het perfect! Maar helaas wordt dan gelijk alle andere formattering ook ongedaan gemaakt, zoals bijv. de lijstjes die met ul en li gemaakt worden.

Nu kan ik heel veel tijd gaan besteden om zelf iets te maken, maar ik kwam een andere plugin tegen die eigenlijk precies doet wat ik wil. Wel moet ik in alle bestaande berichten de pre tag omzetten naar code, maar dat is met een simpele sql opdracht op te lossen. De spaties voor en na het woordje code moeten natuurlijk weg, die staan er omdat anders de tag afgesloten wordt.

update wp_posts set post_content = replace(post_content, '[ code ]','<pre>');
update wp_posts set post_content = replace(post_content, '[ /code ]','</pre>');

Voordat ik alles ga aanpassen, eerst maar eens bedenken wat ik wil.

Eigen thema

Het is rustig geweest hier afgelopen jaren, maar ben nu weer een beetje met WordPress aan het spelen. Ben wel altijd bijgebleven met updates en heb al die tijd met een standaard thema gewerkt.

Vroeger had ik wel een eigen thema gemaakt, door een bestaand thema flink aan te passen. Op zich kan dat, maar dat is met updates altijd wat extra werk om te zorgen dat alles goed gewijzigd wordt.

Nu maar op de juiste manier gedaan door een child-theme te maken.

Als eerste stap een nieuwe directory twentytwelve-child gemaakt in wp-content/themes. In die nieuwe directory een style.css gemaakt met verwijzing naar het parent theme:

/*
Theme Name: Blank Twenty Twelve Child theme
Theme URI: http://yoursite/yourtheme
Description: A child theme of 2012 default WordPress theme.
Author: Your name
Author url: Your site
Version: 1.0
Tags: black, blue, white, fixed-width, custom-header, theme-options
Template: twentytwelve
*/
@import url('../twentytwelve/style.css');

Tot slot nog functions.php gemaakt, deze heb ik nu nog niet nodig, maar in toekomst mogelijk wel:

<?php
// Add your own functions below this line

Deze vervolgens geactiveerd. Hiermee heb ik een goed uitgangspunt om het uiterlijk van deze site langzaam aan naar mijn smaak te zetten.

Crash

Het kan zomaar ineens gebeuren, een harddisk die overlijdt. Het komt altijd ongelegen en ondanks alle goede voornemens waren mijn backups niet al te recent meer (ongeveer 3 maanden oud). Dondermiddag begonnen de problemen met de harddisk en donderdagavond hield alles er opeens mee op.

Inmiddels weer op het punt dat ik in ieder geval weer mijn belangrijkste website in de lucht kan brengen. Weliswaar met de stand van begin februari, maar dat is niet anders.

Komende dagen dus druk met weer alles op te zetten en in te regelen.

Nieuw domein

Het stond al een tijdje op mijn te doen lijstje, maar had er nooit tijd voor gemaakt. Vandaag maar eens het blog verhuisd naar een nieuw domein, http:///www.zomaarr.nl.

Overzetten ging vrij simpel:

  • verplaatsen documentroot naar nieuwe directory
  • aanpassen apache configuratie voor 301 redirect van http://www.zomaarroland.nl naar http://www.zomaarr.nl
  • aanpassen apache configuratie voor zomaarr.nl, extra rewriterules
  • aanpassen van WordPress uri en Site address in de database

Aangezien er verder niets wijzigt, ben ik nu klaar. Nu maar zien of met de zoekmachines alles goed gaat.

Memory limit in WordPress (2)

Eerder schreef ik al dat sommige onderdelen in WordPress zo waren ingesteld dat ze 256mb geheugen claimden. Toevallig zag ik vandaag dat er paar weken terug een mooie patch aan het ticket is toegevoegd die grote kans maakt om in een volgende release te worden toegevoegd.

Zojuist de patch maar eens doorgevoerd, zodat ik eindelijk van die vele foutmeldingen af ben.

Code blokje in comments

Het stond al een hele tijd op mijn lijstje om ooit nog eens op te lossen en nooit was ik er aan toegekomen. Om code in de berichten weer te geven maak ik gebruik van een plugin die alles binnen de pre-tags letterlijk omzet en niet interpreteert als zijnde code. Dat werkt perfect, alleen nog niet in de comments.

Om dat op te lossen heb ik in de plugin de volgende regel toegevoegd:

add_filter('comment_text','fixcode','1');

Met deze regel geef ik aan, dat het filter in de functie fixcode op de comment_text wordt toegepast.

Overal zoeken

Al een hele tijd geleden heb ik de zoekfunctie van WordPress verplaatst naar de archiefpagina. Omdat ik het eigenlijk niet handig vind om eerst een aparte pagina te openen voordat ik kan zoeken, heb ik besloten om de zoekfunctie te verplaatsen naar het navigatieblokje net onder de header.

Binnen de list die het menu maakt, heb ik de volgende regel toegevoegd:


Vervolgens in de css nog even aangeven dat de class search moet floaten, en klaar ben ik.

Memory limit in WordPress

In de php.log zag ik de volgende foutmelding voorbij komen:

Oct 20 18:33:54 echo suhosin[28058]: ALERT - script tried to increase memory_limit to 268435456 bytes which is above the allowed value (attacker '82.75.246.231', file '/var/www/blog/wp-admin/admin.php', line 96)

Er wordt dus geprobeerd om de memory limit op 256mb te zetten. Aangezien in de php.ini de limit is ingesteld op 128mb komt er dus een alert. Ga nog even bedenken wat ik hiermee ga doen, of verlagen of gewoon laten staan. Het is weliswaar alleen een alert en de setting wordt niet actief, maar vanuit beheersoogpunt is elke foutmelding er een te veel.

Toevoeging 21-01-2011
Heb even het bijbehorende bug ticket erbij gezocht, maar het lijkt er niet op dat het snel gefixed gaat worden 🙁 .

Nette url’s

Voor mijn gallery pagina heb ik in het verleden al eens gestoeid om de url’s die aangeboden worden om te zetten in een query string die via php weer uitgelezen kan worden. In Apache is het zo dat dat met een eenvoudige rewrite rule kan, alleen wordt dan de originele url ook aangepast.

Nu ik bezig ben met het overstappen naar Lighttpd, ben ik aan het uitzoeken of (en vooral hoe) alles dat ik gebruik in Lighttpd geconfigureerd moet worden. Na een half uurtje puzzelen kwam ik tot het volgende:

$HTTP["host"] == "www.domein.nl" {
 magnet.attract-physical-path-to = ( "/etc/lighttpd/gallery.lua" )
}

En de gallery.lua bevat weer:

attr = lighty.stat(lighty.env["physical.path"])
if (not attr) then
   path = "/gallery.php"
   uri = string.sub(lighty.env["request.uri"],10)
   lighty.env["uri.query"] = "g=" .. uri
   lighty.env["uri.path"] = path
   lighty.env["request.uri"] = path .. "?" .. lighty.env["uri.query"]
   lighty.env["physical.rel-path"] = path
   lighty.env["physical.path"] = lighty.env["physical.doc-root"] .. path
end

En het leuke is nu, de originele url blijft in tact!

WordPress 2.9

Al weer enige tijd geleden is versie 2.9 van WordPress uitgekomen. De lijst met nieuwigheden is aardig groot. Er zitten zo geen dingen bij die ik echt gebruik, maar om bij te blijven toch maar geupgrade. En de beta van 2.9.1 is er ook al, dus de kans is groot dat de definitieve 2.9.1 binnenkort ook verschijnt.