Schlagwort-Archive: PHP

Git – Bereits eingecheckte Dateien ignorieren

Wenn man eine Datei, die schon mal eingecheckt wurde, ignorieren will, geht das nicht ohne weiteres per .gitignore, denn .gitignore wirkt nur auf neue Dateien.

Daher müsste man die Datei(en) aus dem Repo löschen, was mit git rm –cached myfile.log geht. Die Datei bleibt in Working-Dir erhalten. Allerdings wird die Datei dann in einem anderen Working-Dir gelöscht, wenn man dort ein git pull macht! Daher ist das u.U. keine so gute Lösung.

Lokal kann man die Datei mit

git update-index --skip-worktree myfile.log

ignorieren. Das wird aber nicht in das Upstream-Repo übertragen; Das ist eine rein lokale Angelegenheit und muss ggf. in den anderen Workdirs ebenso gemacht werden.

Bei vielen zu ignorierenden Dateien kann man

git update-index --skip-worktree temp/myfile*

oder ggf.

git update-index --skip-worktree temp/myfile{1..7}.log 

verwenden. git update-index funktioniert übrigens nicht bei Dateien, die mit einem Punkt (.) beginnen!

Siehe auch die Diskussionen und Kommentare in

Eigene 404-Error-Page bei 1&1

Will man dem Besucher bei einer nicht gefundenen Seite nicht die vom Hoster vorgegebene Error-Page sondern eine Eigene präsentieren, so geht das normalerweise ganz einfach mit der folgenden Zeile in der .htaccess-Datei:

ErrorDocument 404 /error404.html

Bei dem Hoster 1&1 funktioniert das zwar auch, aber nur für statische Seiten. Dynamische Seiten mit PHP werden bei dieser Direktive ignoriert. Aber auch hier gibt es eine Möglichkeit: Das Rewrite-Modul vom Apache.

Um alle Seitenaufrufe, die nicht gefunden werden, auf eine eigene Fehlerseite umzuleiten fügt man in seine .htaccess-Datei diese Zeilen ein (an Stelle der o.g. Direktive):

RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule (.*) /error404.html

Zur Erklärung: Alle Seitenaufrufe, deren REQUEST_FILENAME weder als Datei noch als Verzeichnis gefunden werden, werden auf die Seite error404.html im Wurzelverzeichnis (Document-Root) umgeleitet.

Bei mir ist dies dann häufig ein PHP-Script, welches mir die Vermisste URL nebst dem Referer zu mailt.

Artikel von Beta-Blogger nach WordPress umziehen

So, ich habe es geschafft, alle Artikel des alten Blog-Systems Beta-Blogger zu exportieren und diese in WordPress wieder zu importieren. Da ich keine direkte Übertragungsmöglichkeit gefunden habe, habe ich den Weg über CSV gewählt. Es gibt ein halbwegs brauchbares CSV-Import-Plugin und die Artikel aus dem alten Blog ließen sich mit dem folgenden PHP-Script als CSV exportieren:

<?php
require 'bb_core.php';

/* see http://de.php.net/manual/de/function.htmlentities.php#90111 */
function htmlButTags($str) {
  // Take all the html entities
  $caracteres = get_html_translation_table(HTML_ENTITIES);
  // Find out the "tags" entities
  $remover = get_html_translation_table(HTML_SPECIALCHARS);
  // Spit out the tags entities from the original table
  $caracteres = array_diff($caracteres, $remover);
  // Translate the string....
  $str = strtr($str, $caracteres);
  // And that's it!
  // oo now amps
  $str = preg_replace("/&(?![A-Za-z]{0,4}w{2,3};|#[0-9]{2,3};)/","&amp;" , $str);
  return $str;
}

$entries = $blog->get_items('entry', NULL, 1000) or print $lang->no_entries;

print("wp_title|wp_post_date|wp_category|wp_content|field1|field2|field3
");
foreach ($entries as $entry) {
  // Tags: Leerzeichen in "" ersetzen und " entfernen
  $tags =  preg_replace('/"(w+) (w+)"/', '$1=$2', $entry->tags);
  // Tags durch Kommata trennen
  $tags = str_replace(" ", ", ", $tags);
  // oben ersetzte Leerzeichen zurück wandeln
  $tags = str_replace("=", " ", $tags);
  $title = htmlButTags($entry->title);
  $date = strftime("%Y-%m-%d %T", $entry->date);
  $body = preg_replace('/
/', '&#x000A', htmlButTags($entry->body));
  $body = preg_replace('/src=["']media2/', 'src="/wp/wp-content/uploads/2009/09', $body);
  // Pipes müssen escaped werden
  $body = preg_replace('/|/', '|', $body);
  $body2 = preg_replace('/
/', '
', htmlspecialchars($entry->body));
  $teaser = htmlButTags($entry->topic);
  $category = htmlspecialchars($entry->category);

  print("$title|$date|$category|$body|$tags|$teaser|
");

}

?>

Damit die Leerzeichen, die beim Export mit ‚&#x000A‘ escaped wurden, beim Import entsprechend wieder hergestellt werden, musste ich das CSV-Import-Plugin noch geringfügig anpassen und eine Zeile einfügen:

$post_content = str_replace('&#x000A', "
", $post_content);

(Das komplette, angepasste Plugin gibt es hier.)

Leider kann das Import-Plugin keine Tags importieren. Ich habe diese daher im ersten Benutzerfeld abgelegt, so dass sie dann beim Editieren des Artikels per Cut & Paste in das Tag-Feld übertragen werden können. Das ist sicherlich nicht der Hit und bedeutet, dass man jeden Artikel anfassen muss. Aber bei 34 Artikeln ist das noch machbar.