Opgaven: En lang række list items skal udstyres med forklaringer i form af drop downs. HTML koden ser således ud.

<ul class="linklist">
  <li>
    <h4>Overskrift 1</h4>
    <a href="#" class="dropdown-trigger">Vis beskrivelse</a>
    <div id="beskrivelse-1">
      Beskrivende note der falder ned, når man klikker på linket "Vis beskrivelse".
    </div>
  </li>
  <li>
    <h4>Overskrift 2</h4>
    <a href="#" class="dropdown-trigger">Vis beskrivelse</a>
    <div id="beskrivelse-2">
      Beskrivende note der falder ned, når man klikker på linket "Vis beskrivelse".
    </div>
  </li>
</ul>

CSS koden ser således ud.

.linklist li {position:relative;width:270px;}
.linklist li div.hidden {display:none;} /* skjuler div'en, før den aktiveres med jQuery .slideDown() */
.linklist li div {
  background:#ddd;
  border:1px solid #ccc;
  left:0;
  padding:6px 12px 12px;
  position:absolute;
  top:20px;
  width:244px;
}

<div> elementet bør således placere sig ovenpå <li> elementerne. Det virker bare ikke i IE før version 8, fordi stakkeordenen er fejlbehæftet. Jeg prøvede at løse problemet ved at definere en lavere z-index på <li> elementerne, end på <div> elementerne, men det løste ikke problemet. De efterfølgende <li> elementer blev stadig vist ovenpå det aktive <div>element.

Efter en del søgning på nettet fandt jeg Vance Lucas’ jQuery-baserede løsning af problemet:

$(function() {
  var zIndexNumber = 1000;
  $('div').each(function() {
    $(this).css('zIndex', zIndexNumber);
    zIndexNumber -= 10;
  });
});

Ideen er, dynamisk at vende standard z-index stakkeordenen af HTML elementerne om. Således sikrer man, at elementer, der ligger højere i kildekoden også har en højere z-index orden på siden, hvilket burde løse renderingsproblemet i IE.

Det løste ikke umiddelbart mit problem. Jeg havde imidlertid andetsteds læst, at man skulle kunne løse problemet ved at give det relativt positionerede omgivende element en højere z-index orden, end det absolut positionerede element.

Det gav mig ideen til også at lave en Vance Lucas jQuery løsning på det relativt positionerede <li> element, men med en højere z-index orden. Altså:

$(function() {
  var LizIndexNumber = 1100;
  $('li').each(function() {
    $(this).css('zIndex', LizIndexNumber);
    LizIndexNumber -= 10;
  });
  var DivzIndexNumber = 1000;
  $('div').each(function() {
    $(this).css('zIndex', DivzIndexNumber);
    DivzIndexNumber -= 10;
  });
});

Og voila! Så virker det.

Den “rigtige” måde at kalde javascripts på i WordPress er med fuktionen wp_enqueue_script. Med denne funktion kan man kalde en række indbyggede javascript biblioteker, heriblandt jQuery, Scriptaculous og Prototype. For at kalde jQuery, skriver man således følgende i header.php:

<?php wp_enqueue_script('jquery'); ?>

Har man samtidig brug for diverse jQuery afhængige plugins, f.eks. Thickbox eller jQuery UI, kan man nøjes med at kalde disse, da jQuery så kaldes automatisk. I så fald kan man nøjes med følgende:

<?php wp_enqueue_script('thickbox'); ?>
<?php wp_enqueue_script('jquery-ui-core'); ?>

Har man brug for javascripts, der ikke er indbygget i WordPress, kan disse også kaldes med wp_enqueue_script. Hent koden, f.eks. jQuery Cycle, og placér den i en dertil indrettet mappe i dit theme. Kald det dernæst på følgende måde:

<?php wp_enqueue_script('jquery.cycle.all.pack','/wp-content/themes/dit-theme-navn/din-javascript-mappe/jquery.cycle.all.pack.js',array('jquery')); ?>

Se dokumentation til funktionen wp_enqueue_script her.

Foundation PHP: Creating a virtual host in Mac OS X 10.5 (Leopard)

Jeg bruger imidlertid ikke mac’ens indbyggede Apache server, men MAMP. Derfor kunne jeg ikke rigtig bruge ovenstående vejledning til opsætning af virtual hosts i Apache’s konfigurationsfil, httpd.conf. Det findes der også råd for. Her er en fin vejledning i opsætning af virtual hosts under MAMP:

Sawyer McFarland Media, Inc.: Setting Up Virtual Hosts for MAMP

Samme site har en fin indførsel i, hvordan man slipper for MAMP’s default porte 8888 og 8889 i sine lokale URL’er (Se artiklens figur 3).

Mange designere og udviklere vælger at bruge WordPress som CMS fordi det er så enkelt og relativt nemt at implementere og udvikle til. Én af WordPress’ store begrænsninger i rollen som CMS er imidlertid sidebar-metaforen. Som udgangspunkt er der i de fleste themes kun én eller to sidebars til rådighed sitewide, netop fordi WordPress er skabt som blogging værktøj. I en blog er det sjældent nødvendigt med flere.

Men har man brug for et decideret CMS, er der behov for relevant sekundært indhold på alle sider. Noget, der relaterer sig til sidens primære indhold og ikke bare en generel liste med kategorier, et arkiv og en blog roll.

Og så fik jeg den ide at man måske kunne opnå noget brugbart, hvis man kunne oprette en sidebar pr. emnekategori. Så ville det være muligt at målrette widget-indhold til de enkelte emner og dermed øge relevansen af sekundært indhold på indlæg og kategorisider. Efter en del eksperimenteren, lykkedes det mig at skrue nedenstående sammen.

Nedenstående kode skal stå i dit themes functions.php fil:

<?php
# Get sidebar names from db.
global $wpdb;
$my_widget_name = $wpdb->get_col("SELECT slug
FROM $wpdb->terms, $wpdb->term_taxonomy
WHERE $wpdb->terms.term_id=term_taxonomy_id
AND taxonomy='category' AND count!=0 ORDER BY name ASC");

# Register one sidebar per category name.
foreach($my_widget_name as $my_widget) {
  register_sidebar(array(
    'name' => 'Category: ' . $my_widget,
    'before_widget' => '<div id="%1$s" class="%2$s widget">',
    'after_widget' => '</div>',
    'before_title' => '<h3 class="widget-title">',
    'after_title' => '</h3>', ));
}
?>

Først opretter vi en forbindelse til databasen, henter kategorinavn og id fra alle kategorier, der ikke er tomme, samt sorterer kategorierne efter navn. Dernæst registrerer vi vores nye sidebars i WordPress med funktionen register_sidebar samt navngiver hver sidebar med det enkelte kategorinavn.

Indsæt de nye sidebars i dit themes sidebar.php fil:

<?php
# If this is a category archive page.
if (is_category()) {
	global $wp_query;
	$cat_obj = $wp_query->get_queried_object();
	$category_slug = $cat_obj->slug;
}
# If this is a post.
elseif (is_single()) {
	$category = get_the_category();
	$category_slug = $category[0]->category_nicename;
}
# The widget.
if ( !function_exists('dynamic_sidebar') || !dynamic_sidebar('category_' . $category_slug) ) : ?>
<div id="search" class="widget widget_search">
	<h3><?php _e('Search'); ?> <?php bloginfo('name'); ?></h3>
	<?php include (TEMPLATEPATH . '/searchform.php'); ?>
</div>
<?php endif; ?>

For at kalde den rigtige sidebar, skal vi have fat i det rigtige kategorinavn. Hvis siden er en kategori-side, kalder vi kategoriens navn. Men hvis siden er et indlæg, kalder vi navnet på den første kategori, siden er gemt i. Nu udskrives kategoriens sidebar, hvis du befinder dig på en kategori-side eller et indlæg.

Hvad så med ‘sider’?
Man kan lave noget tilsvarende med WordPress’ side-metafor. I stedet for at tage fat i kategorierne i databasekaldet, skal man så bare have fat i tilsvarende for ‘sider’. I så fald vil databasekaldet se ud som følger:

$page_sidebars = $wpdb->get_col("SELECT post_name
FROM $wpdb->posts WHERE post_type='page'
AND post_status='publish' AND post_parent='0'
ORDER BY menu_order ASC");

Bemærk!
Man skal være forsigtig med metoden, hvis man har mange kategorier og/eller sider, da WordPress laver et kald til databasen for hver sidebar, den skal loade i backend’en. Skal den lave for mange kald, får man time out og så fungerer metoden naturligvis ikke.

Hvad var blevet hacket?

Mine WordPress sites havde fået nye forsider og alle index og default filer havde fået tilføjet en iframe, der sendte evt. besøgende hen et sted, hvor de kunne få inficeret deres computer med malware eller virus.

Det så alt sammen meget automatgenereret ud, for det var det eneste, der var gjort. Ingenting i databaserne, så det har utvivlsomt været en robot. Det lignede det, som denne WordPress bruger har været ude for.

Jeg er usikker på, hvordan hackeren er kommet ind. Det kan være via remote file inclusion (RFI), men jeg har en grum mistanke om at mine ftp oplysninger er blevet opsnappet, eftersom hackeren er kommet godt omkring på alle mine sites.

Hvordan kan man opsnappe ftp oplysningerne?

Ofte vil det kunne gøres via inficering med vira eller malware på den forurettedes computer. Jeg har scannet mine maskiner for begge dele og tror ikke det er sket ad den vej. Men hos Gigahost bruger man kontonavn og kontokode til alt. Derfor står det også i wp-config.php, konfigurationsfilen til WordPress, så WordPress kan komme i kontakt med databasen. Har man først fået fat på brugernavn og kodeord herfra, har man således også brugernavn og kodeord til ftp og så er der fri adgang.

Hvad gør man for at rense et inficeret site?

Alle toplevel index.php filer var udskiftet med en index.htm fil og der var tilføjet iframes i bunden af index.php filerne i mine theme-mapper samt default og index filer i øvrige mapper. Jeg fjernede alle iframes, slettede WordPress helt og installerede forfra, for at være sikker på at de inficerede filer var helt væk.

rzaman.com har en udmærket opskrift på, hvordan man gør.

Dnxpert har et fint indlæg om, hvordan man også undersøger, om databasen er inficeret.

Også Smackdown har en glimrende artikel om emnet.

Hvordan kan man øge sikkerheden?

Brug .htaccess filer til at blokere adgangen til bestemte mapper og filer. Her er et par ressourcer, jeg har fundet brugbare:

• Remote File Inclusion (RFI) Attempts – Detecting, Tracking, and Mitigating or Stopping
  Forklarer begrebet RFI og anviser, hvordan man kan beskytte sig mod det med bl.a. .htaccess.
• htaccess for subdirectories
  Beskriver hvordan man kan begrænse adgangen til undermapper med .htaccess.
• WordPress Security Tips and Hacks
  Generelle tips til forbedring af sikkerheden i WordPress.

Sørg også for at begrænse rettighederne på dine filer og mapper. Jeg bemærkede, at man nemt overser wp-config.php i den henseende. Sæt manuelt rettighederne på denne fil til 600, så andre ikke kan læse den. Se udførlig artikel hos WordPress om hvordan man gør.

Installér sikkerhedsplugins i WordPress, f.eks.:

• AskApache Password Protect – der genererer .htaccess filer for dig.
• Login LockDown – der tjekker om der har været mange forgæves loginforsøg fra en given ip adresse, samt blokerer denne.
• AntiVirus – der tjekker dine theme-filer for infektion.
• WP Security Scan – der scanner din WordPress installation for sårbarheder og foreslår udbedringer.

Og endelig: Skift kodeord, skift kodeord, skift kodeord. The Blog Herald har gode tips til, hvordan man finder på et godt ét.

Har Gigahost et sikkerhedshul og bliver jeg hacket igen?

Gigahost har ikke nødvendigvis et sikkerhedshul, men det er da problematisk, at man skal bruge samme brugernavn og kodeord til alt. Og ja, eftersom jeg ikke helt ved, hvordan hackeren kommer ind, bliver jeg måske hacket igen. Men så kan det altså godt ske, jeg skifter webhotel og ser om det løser problemet.

Horsens kommunes bibliotekers website står placeret bag kommunens firewall. Det er jo glimrende, for så vidt sikringen af serveren. Det viser sig dog at give visse problemer ift. WordPress.

WordPress har nemlig brug for at lave en række HTTP kald til sig selv for at kunne udføre en række funktioner, bl.a. cron-jobs, pinging af andre sites, plugin updates og -installation, core upgrades m.m. Men disse HTTP kald kan ikke komme igennem firewall’en og står derfor og laver time out, hvilket får sitet til at hænge i op til adskillige minutter.

Løsningen er at disable WordPress eksterne HTTP kald. Det gøres i filen /wp-includes/http.php

Omkring linie 210 finder man følgende:

function request( $url, $args = array() ) {
  global $wp_version;

Dette ændres til:

function request( $url, $args = array() ) {
  return;
  global $wp_version;

Denne løsning bør dog nok være midlertidig, da problemet reelt ligger et andet sted, nemlig i opsætningen af firewall’en. Jeg har ikke meget erfaring med firewalls, så hvis du har en ide, der kan løse problemet rigtigt, uden at gå alt for meget på kompromis med sikkerheden, vil jeg meget gerne høre om det.

Via WordPress Trac

Slip for unødig grafik og HTML
Med javascript kan man imidlertid undgå både ekstra opmærkning og grafik. Dave Methvin har lavet et plugin til javascript-biblioteket jQuery, som kan netop dette. jQuery er et glimrende letvægts-javascript framework, der gør det nemt for designere med begrænset kodeerfaring at lave relativt avanceret funktionalitet i et website.

Fra grafik-pest til javascript-kolera?
Skal man så rode sin kode til med javascript i stedet for grafik og opmærkning, bare for at få runde hjørner? Som sagt kan jQuery bruges til rigtig mange ting. Har man i forvejen brug for noget af jQuery’s funktionalitet, er det oplagt at anvende til også at lave visse grafiske effekter og vil klart være at foretrække fremfor den ekstra opmærkning og grafik. Jeg vil helt sikkert gøre brug af dette plugin i fremtidige projekter.

Der er en demo af Round Corner plugin’et samt link til download af scriptet her.

Uddraget har som udgangspunkt en størrelse på 55 ord og det kan man ikke umiddelbart ændre på. Men 55 ord kan godt være 40 ord for meget, hvis uddraget ønskes vist på en bestemt måde. Jeg har gravet lidt i uddraget og fundet frem til en måde at begrænse det på.

The_excerpt() laver for lange uddrag
For at implementere uddraget i templaten bruges tag’et the_excerpt() (se dokumentation her). Dette tag er imidlertid ikke en streng, men en funktion og derfor kan man ikke umiddelbart splitte det ad med PHP. Jeg fandt dog ud af, at grundlaget for funktionen the_excerpt() er strengen get_the_excerpt() og denne streng kan godt splittes ad.

Vi har altså brug for en funktion, der kan splitte indholdet i strengen op i enkeltord, tælle antallet af enkeltord og dernæst sætte det ønskede antal ord sammen igen. Jeg nåede frem til følgende opskrift:

Opskriften på korte uddrag
Put nedenstående funktion ind i filen functions.php i dit theme:

<?php
function string_limit_words($string, $word_limit)
{
  $words = explode(' ', $string, ($word_limit + 1));
  if(count($words) > $word_limit)
  array_pop($words);
  return implode(' ', $words);
}
?>

Placér dernæst følgende kodestump i din template, der hvor du ønsker at få spyttet uddraget ud:

<?php
  $excerpt = get_the_excerpt();
  echo string_limit_words($excerpt,25);
?>

… hvor 25 er antallet af ønskede ord i uddraget. Du kan nu styre, hvor mange ord der skal vises i dit uddrag.

Løsningen er tillige publiceret i WordPress’ supportforum.

Jeg har dog savnet et par funktioner, men det findes der heldigvis plugins til.

Fjern uaktuelle indlæg
Et indlæg kan sættes til blive udgivet i fremtiden, emn jeg har også behov for, at det automatisk kan udløbe, dvs. blive slettet når det er uaktuelt.

Til det formål er plugin’et Post Expirator glimrende. Post Expirator kan automatisk enten slette indlæg eller ændre deres status fra ‘udgivet’ til ‘kladde’, således at de er skjult, på den dato hvor indlægget bliver uaktuelt.

Hent Post Expirator her

Omdirigér sider og indlæg
Det er ikke alle punkter i menuen, der nødvendigvis skal linke til en side. F.eks. kan man have behov for at linke til et indlæg eller en emnekategori. Omvendt kan der være brug for at linke direkte fra en indlægsoverskrift til en side.

Page Links To er et plugin, der gør netop dette muligt. I administrationen af det enkelte indlæg eller den enkelte side giver plugin’et mulighed for at indtaste den URL, man ønsker, der i stedet skal linkes til.

Hent Page Links To her

Skjul bestemte sider fra menuen
Det kan nogle gang være nødvendigt at skjule bestemte sider fra en menu. Skal man f.eks. bruge en bekræftelsesside til formularer bør den ikke nødvendigvis fremgå af menuen.

Det kan man gøre med plugin’et Exclude Pages. Plugin’et skjuler ganske enkelte nærmere bestemte sider fra sidenavigationen.

Hent Exclude Pages her