Et lille eksempel:

Smæk dette link ind i head sektionen i dit HTML dokument.

<link href='http://fonts.googleapis.com/css?family=Lobster' rel='stylesheet' type='text/css'>

Så er du klar til at bruge Lobster i din css som enhver anden font.

Det skulle efter sigende fungere helt tilbage til IE6. Skulle man endelig være negativ, kunne man sige at udvalget af skrifttyper stadig er ret begrænset, men mon ikke, der med tiden bliver lavet om på det?

Via Nettuts.

Du skal stå for opsnitning i HTML over implementering i CMS til undervisning af kunden eller redaktionelt arbejde med tekster og billeder. Du skal samarbejde med Midt Marketings webdesignere om at finde den bedste løsning til kunden i forhold til pris, brugervenlighed og høj teknisk kvalitet.

Er du lidt af en pixel-pusher, har udpræget kvalitetssans og sætter en ære i at levere løsninger i høj kvalitet? Er du en haj til HTML, CSS, Javascript og kender jQuery ud og ind?

Sådan et job kan du få i Herning. Er du interesseret?
Se hele jobbeskrivelsen her.

Det har egentlig ikke noget med WordPress at gøre, men derimod indstillingerne i php.ini. Det er imidlertid ikke alle webhoteller, der tillader sine brugere at ændre i php.ini. Hos Gigahost kan man ændre visse indstillinger, men det slår af en eller anden grund ikke helt igennem i WordPress.

Jeg har imidlertid fået følgende løsning til at fungere:

1. Opret en ny php.ini fil med følgende indhold:

post_max_size = 20M
upload_max_filesize = 20M
max_execution_time = 900

2. Upload filen til wp-admin mappen.

Og voila! Nu kan man uploade filer op til 20 mb.

Via Likoma.com

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.

Løsningen skal findes i hosts filen på gæste OS’et (den virtuelle Windows). Hosts filen ligger her:

c:\windows\system32\drivers\etc\hosts

Her tilføjes en linie for hver virtuelle host, man har sat op i MAMP’s Apache config fil:

10.0.2.2 sitenavn.tld

Hvor IP-adressen bruges som DNS-resolver af VirtualBox til at identificere værtscomputeren, og sitenavn.tld er navnet på det site/virtuelle host, man har sat op i Apache.

Jeg fandt løsningen i VirtualBox’ forum.

Det er muligvis banalt for netværksfolk, men jeg har efterhånden fået løst en del problemer via hosts filen på både mac, win og linux. Hosts-filen er klart et mere centralt stykke værktøj, end jeg forstod for bare få år siden.

Se evt. også hvordan man opsætter “Virtual hosts på mac under MAMP“.

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.

Web fonts and standards – Jeffrey Zeldman Presents The Daily Report

26. august
As far back as 1998, CSS2 provided a way to link to real fonts from your style sheet. Nice round up on how to implement fonts with @font-face.

Fonts available for @font-face embedding – Webfonts.info

26. august
Nice collection of fonts for the web.

PDF doc search II – Meta

26. august
I edited includes/SpecialSearch.php to make the saved PDFs searchable. This contribution is limited to a small amount of PDFs. When creating the PDFs don´t use compress text and images in e.g. acrobat distiller.