OpenOffice Calc cellen samenvoegen met nieuwe lijnen

Voor het importeren van een aantal berichten naar WordPress moest ik een aantal cellen in een Excel document samenvoegen naar 1 cel. De waarden van deze cellen moest onder elkaar komen te staan binnen 1 cel. Om dit te realiseren heb ik gebruik gemaakt van OpenOffice Calc, de gratis opensource variant van Microsoft Excel.

Na een zoektocht op Google naar “openoffice calc concatenate new line” was de oplossing snel gevonden. Veel van deze oplossingen zijn echter beschreven in het Engels, waardoor ze niet direct werken in een Nederlandse OpenOffice installatie. De functienamen moeten namelijk ook vertaald worden naar het Nederlands. Het soms nog een hele uitdaging om de juiste Nederlandse functie naam te vinden.

Op het OpenOffice.org forum was de volgende functie te vinden:

=CONCATENATE(C37;CHAR(13);CHAR(10);C38)

Deze is als volgt te gebruiken in een Nederlandse OpenOffice installatie:

=TEKST.SAMENVOEGEN(A1;TEKEN(13);TEKEN(10);B1;TEKEN(13);TEKEN(10);C1)

TEKEN(13) staat in dit geval voor een Carriage Return (CR), ook wel beter bekend als “\r”. De TEKEN(10) staat voor een Line Feed (LF), ook wel beter bekend als “\n”. De combinatie “\r\n” (CRLF) wordt op Windows omgevingen gebruikt om aan te geven dat er op een nieuwe regel gestart moet worden.

WordPress zoeken sorteren op relevantie en datum

De standaard zoekfunctie van WordPress is erg eenvoudig en beperkt. De zoekresultaten zijn standaard gesorteerd op datum. Het is niet mogelijk om deze te sorteren op bijvoorbeeld relevantie. Daarnaast is het ook niet mogelijk om fancy operators te gebruiken in je zoekopdracht zoals we gewend zijn bij andere zoekmachines. Gelukkig zijn er allerlei plugins die de zoekfunctie van WordPress uitbreid.

Ik wilde op een WordPress website de bezoekers de mogelijkheid geven om te sorteren op relevantie of op datum. Om dit mogelijk te maken heb ik ik de Relevanssi plugin van Mikko Saari (twitter: @msaari) geïnstalleerd en de volgende code toegevoegd aan de search.php template.

<?php 

$url = add_query_arg('s', get_search_query(), home_url('/'));

printf(
	__('ordered by %s | %s', 'text_domain') ,
	sprintf('<a href="%s">%s</a>',
		add_query_arg('orderby', 'relevance', $url) ,
		__('relevance', 'text_domain')
	) ,
	sprintf('<a href="%s">%s</a>',
		add_query_arg('orderby', 'post_date', $url) ,
		__('date', 'text_domain')
	)
);

?>

WordPress berichten inclusief bijlagen verwijderen

In mijn vorige blog kon je lezen hoe je WordPress berichten kunt verwijderen die geen gekoppelde media (attachments) hebben. In dit bericht laat ik een code snippet zien waarmee je berichten inclusief gekoppelde bijlagen kunt verwijderen. Als je een bericht binnen de WordPress beheerpaneel verwijderd blijven de gekoppelde bijlagen staan. Als je ook de gekoppelde bestanden wilt verwijderen kun je gebruik maken van de volgende code:

$query = new \WP_Query();
$query->query(array(
	'post_type' => 'project' ,
	'tax_query' => array(
		array(
			'taxonomy' => 'phase' ,
			'field' => 'slug' ,
			'terms' => 'test'
		)
	) ,
	'posts_per_page' => -1
));

while($query->have_posts()) {
	$query->the_post();

	$postId = get_the_ID();

	echo $postId, ' - ', get_the_title(), '<br />';

	$attachmentsQuery = new \WP_Query();
	$attachmentsQuery->query(array(
		'post_type' => 'attachment' ,
		'post_status' => 'inherit' ,
		'post_parent' => $postId
	));

	while($attachmentsQuery->have_posts()) {
		$attachmentsQuery->the_post();

		$attachmentId = get_the_ID();

		echo '- ', $attachmentId, ' - ', get_the_title(), '<br />'; 

		$result = wp_delete_attachment($attachmentId, true);
	}

	$result = wp_delete_post($postId, true);
}

Je kunt uiteraard de WP_Query->query() parameters helemaal naar wens aanpassen.

Verwijder WordPress berichten zonder bijlagen

Bij Pronamic zetten we regelmatig websites om naar WordPress. We maken hierbij gebruik van verschillende importeer technieken. Helaas gaat er bij het importeren ook wel eens iets fout. Zo gebeurd het soms dat de bijlagen bij een bericht niet goed worden overgenomen. We moeten dan alle berichten zonder gekoppelde bijlagen verwijderen. Binnen het beheerpaneel van WordPress is dit niet eenvoudig te realiseren. Daarom hebben we een simpel scriptje ontwikkeld waarmee we deze berichten kunnen verwijderen.

$query = new WP_Query();
$query->query(array(
	'post_type' => 'post' ,
	'posts_per_page' => -1
));

while($query->have_posts()) {
	$query->the_post();

	$id = get_the_ID();

	$attachmentsQuery = new \WP_Query();
	$attachmentsQuery->query(array(
		'post_type' => 'attachment' ,
		'post_status' => 'inherit' ,
		'post_parent' => $id ,
		'posts_per_page' => -1
	));

	if($attachmentsQuery->post_count == 0) {
		wp_delete_post($id, true);
	}
}

Twinfield usability en API

Sinds een jaar gebruiken we bij Pronamic het online boekhoudsysteem Twinfield. Met dit pakket zou je eenvoudig online je administratie moeten kunnen beheren. In dit bericht zet ik daar mijn vraagtekens bij, is Twinfield wel zo eenvoudig en gebruiksvriendelijk?

Ik moet hierbij vermelden dat ik erg weinig doe met Twinfield. Ik gebruik Twinfield voornamelijk voor het opvragen van facturen en het controleren van betalingen. Toch zie ik enorm veel verbeterpunten bij deze eenvoudige handelingen. In dit bericht kort een aantal verbeterpunten.

Inloggen

Om in Twinfield in te loggen moet je naar de pagina https://login.twinfield.com/ surfen. Ik ken deze URL in principe uit mijn hoofd, maar ik type hem zelden met ‘https’ ervoor. Als je echter naar http://login.twinfield.com/ surft krijg je de melding: “De wachttijd voor de verbinding is verstreken“. Zou het zo lastig zijn om http://login.twinfield.com/ netjes door te linken naar https://login.twinfield.com/?

Zodra je uiteindelijk het inlogformulier voor je hebt begint de voglende uitdaging. Je moet een gebruikersnaam, wachtwoord en een omgeving invoeren. De gebruikersnaam en wachtwoord zijn erg gebruikelijk, maar waar dient ‘omgeving’ voor? Het zal vast een doel hebben binnen Twinfield, maar ik vind het een onnodig extra veld.

Deze problemen zijn in principe eenvoudig te verhelpen door de login URL en de logingegevens op te slaan binnen je webbrowser. De ontwikkelaars van Twinfield zouden dit echter ook kunnen vereenvoudigen. Met de kreet “Snel starten en overal toegankelijk” op hun website zou je dat wel mogen verwachten, want snel Twinfield starten is mij nog niet gelukt ;) .

Navigeren

Als ik vervolgens ben ingelogd en een factuur wil bekijken klik ik in het hoofdmenu op het item “Facturatie”. Ik krijg zodra ik met mijn muis over dit item ga keurig een ‘pointer’ cursor te zien. Door de ‘pointer’ cursor krijg ik het idee dat dit item linkt naar een pagina “Facturatie”, maar dit blijkt niet zo te zijn.

Zodra ik op dit item klik opent er niet een nieuwe pagina, maar sluit het zojuist automatische geopende submenu. Dit terwijl het submenu de enige manier is om naar een pagina te navigeren is.

Als je veel met Twinfield werkt zul je wel snel gewend zijn aan het feit dat hoofdmenu items niet bruikbaar zijn. Voor de gebruikers die minder regelmatig met Twinfield werken is dat toch minder gebruiksvriendelijk.

Bladeren

Waar ik me nog het meeste over verbaas is dat je binnen Twinfield niet direct vanuit het hoofdmenu lijsten met gegevens kunt opvragen. Vanuit veel webapplicaties ben ik gewend dat zodra je op een hoofd menu item klikt je direct door gegevens heen kunt bladeren. Zo kun je in WordPress in het hoofdmenu klikken op “Berichten” en krijg je direct de meest recente berichten te zien:

Waarom kan ik binnen Twinfield niet via het hoofdmenu een overzicht met crediteuren, debiteuren, facturen, bankafschriften, etc. tevoorschijn toveren? Data opvragen binnen Twinfield moet blijkbaar beslist via allerlei onhandige zoekformulieren. Zo moet ik voor het bekijken van de laatst verzonden facturen naar “Opvragen” onder het menu item “Facturatie” gaan en vervolgens het volgende formulier invullen:

Als ze nou eens onder het hoofdmenu item “Facturatie” meteen de meest recente facturen weergeven zou me dat enorm veel tijd besparen. Hetzelfde geldt ook voor allerlei andere objecten zoals crediteuren en debiteuren. Eenvoudig een overzicht naar voren halen en daardoor heen bladeren zit er bij Twinfield naar mijn idee niet in.

Permalinks

Permalinks zijn denk ik de basis van elke goede webapplicatie. Alle data binnen een webapplicatie moet naar mijn idee bereikbaar zijn onder een unieke permanente link. Gelukkig beseffen veel ontwikkelaars wereldwijd dit en is data steeds vaker terug te vinden onder een unieke permanente link.

Bij Pronamic werken we met allerlei webapplicaties. Je kunt daarbij denken aan de webapplicaties van 37signals (Basecamp, Highrise, etc.) en het Pronamic intranet met alle klant- en projectdata. Alle data binnen deze webapplicaties zijn via een unieke URL op te vragen. Ik merk dat we deze URL’s intern steeds vaker gebruiken, zo linken we in e-mails, chats en andere applicaties naar gerelateerde data.

Helaas is data binnen Twinfield nog lang niet altijd goed onder een unieke permanente link beschikbaar. Dit terwijl ik juist regelmatig naar administratieve data in Twinfield wil linken. Zo zou ik bij vragen over data binnen Twinfield een collega kunnen mailen met een link naar de betreffende data.

Conclusie

Ik denk dat Twinfield qua usability nog flink aan de weg moeten werken. Administratief gezien zullen bepaalde dingen vast en zeker handig opgezet zijn. Voor iemand die echt eenvoudig en snel zijn administratie wil doen lijkt Twinfield mij minder handig. Ik denk dat voor mensen zoals mij hippen en moderne webapplicaties zoals MoneyBird veel fijner werken.

Gelukkig heeft Twinfield ook een API beschikbaar gesteld. Het is dus mogelijk om Twinfield data via een eigen applicatie op te vragen en gebruiksvriendelijker weer te geven. Ik heb op Google Code: https://code.google.com/p/twinfield/ wat meer informatie over deze API gepubliceerd. Naast dat heb ik ook een aantal experimentele PHP 5.3+ classes ontwikkeld waarmee bepaalde Twinfield data is op te vragen.

Dummy code

<?php

namespace Pronamic\Twinfield;

$twinfieldClient = new TwinfieldClient();

// Inloggen
$result = $twinfieldClient->logon($username, $password, $organisation);

// Kantoren opvragen
$offices = $twinfieldClient->getOffices();

// Zoeken
$finder = $twinfieldClient->getFinder();

$search = new Search();
$search->setType(Search::TYPE_DIMENSION);
$search->setPattern('*');
$search->setField(Search::FIELD_ALL_CODE_OR_NAME);
$search->setFirstRow(1);
$search->setMaxRows(Search::ROWS_ALL);

?>

Ik wil dit te zijner tijd verder gaan ontwikkelen en het opvragen van bepaalde data in Twinfield vereenvoudigen. Wellicht zijn er vervolgens ook mogelijkheden om andere PHP applicaties te koppelen aan Twinfield. Zo is er volgens mij veel interesse in een stabiele Magento Twinfield koppeling.

Valide HTML, SEO en code / tekst verhouding

Onlangs twitterde ik over de YouTube video “Is HTML validation necessary for ranking?” uit het Google Webmaster Help kanaal. Uit deze video blijkt dat Google eigenlijk helemaal niet naar de correctheid van HTML kijkt.

Collega Martijn Duker reageerde hier op met de volgende tweet:

@remcotolsma Validatie is direct niet van invloed., maar indirect weer wel, schone code is vaak kortere code = snellere laadtijd. #SEO #W3C

Ik denk dat Martijn daarmee de spijker op de kop slaat. Het werken volgens de W3C standaarden kan indirect heel veel invloed hebben op je positie bij zoekmachines. Door volgens de HTML standaarden te werken is je content in veel gevallen beter gestructureerd. Daarnaast is je code vaak ‘schoner’ en daardoor sneller.

Concullega Harmen Visser van TRES internet tweette vervolgens dat er bij schonere code er in verhouding meer content is en dat je juist daarmee goed scoort. In de zoekmachine optimalisatie wereld noemen ze dit ook wel de “Code to Text Ratio”. De “Code to Text Ratio” geeft de verhouding tussen content en code (HTML, CSS, JavaScript, etc.) aan.

@MDuker @remcotolsma Bij schonere code is er in verhouding meer content. Juist dat scoort goed bij Google.

@remcotolsma @mduker Google beoordeelt een pagina oa obv de verhouding content vs. code. Hoe minder code hoe beter de score. #SEO

Het leek mij persoonlijk heel erg onwaarschijnlijk dat juist hierdoor websites hoger scoren. Het aantal HTML elementen die gebruikt worden zouden naar mijn idee namelijk niet invloed moeten hebben op de indxering van een webpagina. Het goed structureren van content kan in sommige gevallen immers zelfs zorgen voor meer code.

Naar aanleiding van de tweet van Harmen ben ik hier even wat dieper ingedoken. Allereerst heb ik de Google Webmaster Help kanaal op YouTube eens doorzocht. Helaas kon daar ik geen video’s vinden over dit onderwerp. Eén video die hier misschien een beetje aan gerelateerd is gaat over witruimte in een webpagina.

Uit deze video blijkt dat extra witruimte eigenlijk geen invloed heeft op je positie bij Google. Kan ik daaruit concluderen dat minder of meer code ook geen invloed heeft?

Op de Wemaster Tools Help Forum van Google zijn gelukkig wel een aantal berichten te vinden gerelateerd aan de “Code to Text Ratio“. In de meeste berichten wordt duidelijk gemaakt dat de code / content verhouding nauwelijks of geen invloed heeft op je positie bij
Google. Eén persoon die stelt zichzelf de volgende vragen:

  • Heb je een tool gezien in de Google Webmaster hulppgromma’s voor de “Code to Text Ratio”?
  • Heb je hier ooit een bericht, waarschuwing en/of melding over gezien in de Google Webmaster hulppgromma’s?
  • Denk je echt dat een pagina met een eenvoudig ontwerp en minimale structuur hoger scoort dan een grotere ingewikkelde pagina met meer code?
  • Is het niet waarschijnlijker dat Google geen of weinig aandacht besteeds aan zulke dingen?

Ik denk dat dit de mensen wel aan het denken zet: de “Code to Text Ratio” daar hecht Google geen waarde aan. Dat een goede “Code to Text Ratio” juist hoog scoort bij Google is naar mijn idee in ieder geval onjuist. Ik ben echter erg benieuwd naar jullie mening over dit onderwerp.

Extra informatie

CentOS tijd instellen / synchroniseren

Tijd op een server is erg belangrijk, het is heel vervelend als de tijd van een server onjuist is. Ik had onlangs wel te maken met een Linux machine waarop de tijd verkeerd stond. Dit is gelukkig eenvoudig op te lossen door de tijd te synchroniseren met een NTP server.

Om binnen CentOS te controleren of de tijd goed is ingesteld kun je de volgende commando uitvoeren:

[ ~]# date
Fri Mar 18 21:50:43 CET 2011

Hier staat CET voor de tijdzone “Central European Time”, dit is de tijdzone voor de wintertijd. In de zomertijd zal CEST zijn, wat staat voor “Central European Summer Time. Mocht de tijd bij jou niet correct staan dan kun je hier voor NTP installeren. Dit kun je doen door de volgende commando uit te voeren:

[ ~]# yum install ntp

Als het goed is wordt nu NTP geïnstalleerd of krijg je de melding “Nothing to do” als dit pakket al op je machine staan. Vervolgens kun je het volgende commando uitvoeren om de tijd te synchroniseren:

[ ~]# ntpdate pool.ntp.org

Als je de melding krijgt dat de NTP socket al in gebruik is dan is er waarschijnlijk al een NTP proces (daemon) actief. Deze kun je uitschakelen door het volgende commando uit te voeren:

[ ~]# /etc/init.d/ntpd stop

Als het goed moet je vervolgens wel de ntpdate commando kunnen uitvoeren.

[ ~]# ntpdate pool.ntp.org
18 Mar 22:05:57 ntpdate[24291]: adjust time server 204.62.14.98 offset -0.010934 sec

Vervolgens kun je de NTP deamon weer starten door het volgende commando
uit te voeren:

[ ~]# /etc/init.d/ntpd start

Als ik het goed begrepen heb worden processen binnen CentOS niet automatisch gestart. Als je het NTP proces automatisch wilt laten starten dan dien je het volgende commando uit te voeren:

[ ~]# chkconfig ntpd on

Het kan overigens ook zijn dat de tijdzone niet correct staat ingesteld op je machine. Voor het instellen van de tijdzone moet je een symlink maken naar een zoneinfo bestand. Voor de Nederlandse tijdzone zal dat er zo moeten uitzien:

/etc/localtime -> /usr/share/zoneinfo/Europe/Amsterdam

Je kunt deze symlink aanmaken door het voglende commando uit
te voeren:

[ ~]# ln -sf /usr/share/zoneinfo/Europe/Amsterdam /etc/localtime

Zang verwijderen uit MP3 liedje

Voor de 50e verjaardag van mijn vader hebben we een liedje geschreven op
de melodie van een bestaand liedje. Helaas konden we van dit liedje niet
een karaoke versie vinden. Gelukkig zijn er allerlei programma’s die de
zang uit een liedje kunnen verwijderen.

Voor het verwijderen van de zang heb ik gebruik gemaakt van de
“Vocal Remover” Winamp plugin van Brian Andrews. Zodra je deze plugin activeert kun je procentueel aangeven hoeveel zang er verwijderd moet worden. Voor de beste resultaten zul je hier een beetje mee moeten spelen.

Zodra je plugin heb gedownload en geïnstalleerd kun je de plugin activeren:
“Opties » Voorkeuren…” (sneltoets Ctrl + P) en vervolgens naar
“Plugin-ins » DSP/Effect” en klikken op “AnalogX Vocal Remover [dsp_vr.dll]“.

De plugin werkt helaas niet voor alle liedjes even goed, maar voor een
gratis plugin is het zeker niet verkeerd. Zodra je de plugin goed hebt
afgesteld kun je er voor kiezen het aangepaste liedje op te slaan in een WAV
bestand. Hiervoor ga je naar: “Opties » Voorkeuren…” (sneltoets Ctrl + P)
en vervolgens naar “Plugin-ins » Uitvoer” klikken op “Nullsoft Disk Write v2.14 [out_disk.dll]” en het liedje afspalen.

WordPress media bestanden met rare tekens

Onlangs hebben we een nieuwe WordPress website gelanceerd bij Pronamic. De opdrachtgever heeft deze website netjes gevuld op de ontwikkel- en testomgeving van Pronamic. Vervolgens hebben we deze verplaatst naar de productieomgeving. Hierbij liepen we echter tegen een probleem aan. Veel geüploade bestanden hadden in de bestandsnaam rare tekens, zoals copyright (©) tekens. Op de ontwikkel- en testomgeving leverde dit geen problemen op, maar helaas op de productieomgeving wel.

Aangezien het om een flink aantal bestanden ging was het handmatig aanpassen of opnieuw uploaden niet een optie. Ik kon helaas ook geen geschikte WordPress plugin vinden die dit probleem kon verhelpen. Om die reden heb ik zelf maar even een oplossing ontwikkeld. Allereerst heb ik een MySQL query bedacht die alles © tekens vervangt met een gewone c teken.

UPDATE wp_postmeta SET meta_value = REPLACE(meta_value, '©', 'c') WHERE meta_key = '_wp_attached_file';
UPDATE wp_postmeta SET meta_value = REPLACE(meta_value, '©', 'c') WHERE meta_key = '_wp_attachment_metadata';
UPDATE wp_posts SET guid = REPLACE(guid, '©', 'c') WHERE post_type = 'attachment';

Vervolgens moesten de bestanden in de WordPress uploads mag ook gewijzigd worden. Hiervoor heb ik eenvoudig PHP script geschreven en uitgevoerd in de uploads map:

<?php

$rdi = new RecursiveDirectoryIterator('./');
$rii = new RecursiveIteratorIterator($rdi);

foreach($rii as $file) {
	$name = $file->getPathname();

	$copyrightPosition = strpos($name, '©');

	if($copyrightPosition !== false) {
		$newName = str_replace('©', 'c', $name);

		$renamed = rename($name, $newName);

		echo $name, ' = ', $newName, ' = ', ($renamed ? 'renamed' : 'failed'), '<br />';
	}
}

Uiteindelijk heb ik voor de zekerheid alle afbeelding en bijbehorende thumbnails opnieuw laten generen met de Regenerate Thumbnails plugin. Mocht je ook ooit een dergelijke probleem hebben dan hoop ik dat je met bovenstaande code fragmenten dit snel kunt oplossen. Eventueel kan Pronamic ook een plugin voor je ontwikkelen die geautomatiseerd je probleem kan verhelpen. Mocht je nog vragen, opmerkingen en/of tips hebben laat dan gerust een reactie achter.

Magento factuurdatum toevoegen aan PDF

Bij Pronamic krijgen we regelmatig de vraag om de factuurdatum toe te voegen aan de Magento factuur PDF. Volgens de belastingdienst moet de factuurdatum immers verplicht op de factuur staan. Op internet zijn gelukkig genoeg pagina’s te vinden waarop wordt uitgelegd hoe je dit voor elkaar kunt krijgen.

Als je de factuurdatum achter het factuurnummer wilt plaatsen in de PDF kun je daarvoor de volgende code gebruiken.

$page->drawText(Mage::helper('sales')->__('Invoice Date') . ': ' . Mage::helper('core')->formatDate($invoice->getCreatedAt(), 'full', false), 285, 780, 'UTF-8');

Deze regel kun je toevoegen aan het bestand ‘app/code/local/Mage/Sales/Model/Order/Pdf’ onder de regel:

$page->drawText(Mage::helper('sales')->__('Invoice # ') . $invoice->getIncrementId(), 35, 780, 'UTF-8');

De datum kan in verschillende formaten worden weergegeven in de PDF. Hier voor wordt gebruik gemaakt van de ‘formatDate’ functie. Binnen de 2e parameter kun je opgeven in welk formaat de datum weergegeven moet worden. Je kunt hiervoor kiezen uit de volgende PHP class constanten uit de Mage_Core_Model_Locale class:

  • Mage_Core_Model_Locale::FORMAT_TYPE_FULL = ‘full’
  • Mage_Core_Model_Locale::FORMAT_TYPE_LONG = ‘long’
  • Mage_Core_Model_Locale::FORMAT_TYPE_MEDIUM = ‘medium’
  • Mage_Core_Model_Locale::FORMAT_TYPE_SHORT = ‘short’

Als je werkt met de Nederlandse Magento dan kun je de volgende output verwachten:

  • ‘full’ = maandag 31 januari 2011
  • ‘long’ = 31 januari 2011
  • ‘medium’ = 31 jan. 2011
  • ‘short’ = 31-01-11

Met de 3e parameter kun je overigens opgeven of je de tijd ook wilt weergeven. Als je hier false opgeeft zal de tijd niet worden weergeven, bij true wel.