Die beste URL-Struktur. Permalinks in WordPress

22.02.2009 in: Links, Sprache, Suchmaschinen, Webdesign und WordPress • 23 Kommentare
Letzte Änderung: 01.10.2010, 18:51 Uhr.

Die meisten Content-Management-Systeme (CMS) erlauben angepaßte URLs, oft auch Permalinks genannt. Die Adresse einer Einzelseite lautet dann beispielsweise http://example.com/2008/hallo-welt/ statt http://example.com/?entry=686876654. Das ist gut, denn Fragezeichen und kryptische Ziffernfolgen haben in einer festen Adresse nichts zu suchen.

Hier möchte ich nun die Gründe für meine Konstruktion der Permalinks diskutieren. Ich orientiere mich am Blog-System WordPress; die Hinweise gelten aber überwiegend auch für andere Systeme und rein statische Seiten.

Faustregel: Eine gute Adresse kann ich ohne Buchstabieren am Telefon weitergeben.

Bedingungen

Suchmaschinen berücksichtigen die einzelnen Bestandteile einer URL, wenn sie mit einem Suchwort übereinstimmen – Google allerdings nur bis zum achten Trennzeichen.
Jemand verschickt die URL vielleicht per E-Mail, oder er schreibt sie ins Usenet. Hier bricht sie oft um, wenn sie sehr lang ist. Mehr als 72 Zeichen führen fast sicher zum Umbruch. Dann klickt ein Leser auf das erste Bruchstück und landet auf einer Fehlerseite. Autsch!
Der erste Blick auf eine URL sollte dem Leser schon etwas sagen: Wer hat wo und wann worüber geschrieben?
Wenn jemand die URL schrittweise bis zum nächsten / kürzt (englisch: URL butchering), also von http://example.com/2008/hallo-welt/ nach http://example.com/2008/ geht, dann sollte er immer einen neuen und sinnvollen Inhalt finden. Keine Tagesarchive mit nur einem Eintrag also und erst recht keine Fehlerseite.
Und schließlich sollte die Struktur das eigene CMS nicht ausbremsen. WordPress beispielsweise wird langsam, wenn die Basis mit %category%, %tag%, %author% oder %postname% beginnt.

Lösung

Die beste Linkstruktur sieht für mich so aus:

Domainname ohne www. Das gibt uns hinten ein Suchwort mehr bei Google; außerdem ist die Subdomain www fast immer technisch überflüssig.
Im Webserver Apache kann man den Domainnamen per .htaccess und mod_rewrite sicherstellen:
```
# Host sichern
# toscho.de anpassen!
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP_HOST} !^toscho\.de$
RewriteRule ^(.*)$ http://toscho.de/$1 [L,R=301]
</IfModule>
```
Wer WordPress bei Strato hostet, braucht hierfür einen Hack, der deren kaputte Konfiguration umgeht.
Die Basis der Artikel sei aussagekräftig aber kurz. Ich benutze nur das Jahr, damit man den Link zeitlich zuordnen kann.
In WordPress: /%year%/%postname%/.
Ein Blog mit mehreren Autoren kann und sollte noch den jeweiligen Autor angeben.
In WordPress: /%year%/%author%/%postname%/.
Mehr Details zum Datum sind nur bei sehr oft aktualisierten Webseiten nötig oder bei Artikeln mit einem engen zeitlichen Kontext.
Sinnvoll gekürzte URLs für Einzelseiten: Für den Artikel »Safari in CSS und Javascript ansprechen« habe ich beispielsweise die URL-Form safari-css-javascript benutzt.
Keine »Datei-Endungen«. Eine URL ist eine Adresse; sie bildet kein Datei-System ab. Zudem verlängert ein angehängtes .html oder gar .php die URL ohne Not.
Ein Slash / als Endung. Ein Artikel kann einen Anhang haben, der unter http://example.com/2008/hallo-welt/anhang/ erreichbar ist. Spätestens dann muß sowieso http://example.com/2008/hallo-welt/ existieren.

Das Ergebnis kann man jetzt in der Adresszeile des Browsers begutachten.
Lesetip: Christoph Schneegans: Kanonische Adressen

23 Kommentare

Monika am 22.02.2009 · 18:10
In den URLs sind ja auch Keyords drin, ganz automatisch, weil es sprechende URLs sind, wozu sollte es also sinnvoll sein, auf eine Jahreszahl zu optimieren?

als Kategoriebasis tät ich daher ein zum Grundthema passendes Keywort vorschlagen - oder ein Wort, dass man *branden* mag

lg
Thomas Scholz am 22.02.2009 · 19:33
Die Jahreszahl hilft demjenigen, der die URL sieht, bei der zeitlichen Einordnung, beispielsweise bei der Auflistung der Suchergebnisse bei Google.
Wenn jemand nach einer Einführung in PHP sucht, so bevorzugt er sicher jüngere Texte, weil dann vermutlich auch aktuelle Möglichkeiten der Sprache behandelt werden. Ich möchte hierbei nicht unbedingt von »optimieren« reden, eher von »informieren«.

Die »Kategorie-Basis«, die WordPress den Übersichten einzelner Kategorien voranstellt, habe ich im Beitrag noch nicht angesprochen, denn sie wird beim einzelnen Beitrag normalerweise nicht sichtbar. Da kann man für Blogs mit eng umrissenem Thema natürlich ein wichtiges Suchwort hineinpacken, wenn es wie ein wichtiges Glied zwischen Kategorie und Hauptseite funktioniert.
Monika am 22.02.2009 · 23:08
hallo Thomas, ob optimieren oder informieren - ich glaube es gibt keine *beste* URL Struktur für alle, Du hast Recht,wenn es um zeitliche Zuordnungen geht - CSS Tutorials sind seit einigen Jahren nicht wirklich neu zu machen, bringe ich einen Artikel über den goldenen Schnitt ist der -hoffentlich - morgen auch noch zeitnah *neu*.

ich kenne persönlich nur Studien worauf die Menschen in den Serps lieber klicken - und welche und wieviele Teile einer URL für Google noch *lesbar* sind.

in meinem Bekanntenkreis der - mehr oder weniger- das Inernet nutzt, merkt sich keiner eine URL, außer eventuell den Domainnamen und den geben sie in das Google Suchfeld ein ..

;)

lg
Technikpedia am 05.03.2009 · 16:52
Ich nutze in einigen Blogs Die Category/Post-Struktur. Also keine Jahres-, Monats-, oder Tageszahlen in der URL, sondern nur den Domainnamen, den Kategorienamen und den letztendlichen Post-Namen. Damit habe ich bisher die besten Erfahrungen gemacht. Wie es zum Beispiel bei dir ist, also mit der Jahreszahl in der URL, das würde für mich keinen Sinn ergeben, bzw. für Suchmaschinen auch nicht.
Thomas Scholz am 05.03.2009 · 17:17
Kategorien als Linkbasis werden dir bei WordPress schwer auf die Füße fallen, wenn du viele Beiträge hast.

Bei mir sind auch viele Beiträge in mehreren Kategorien – da kann und will ich nicht eine auswählen und durch ihre Position in der URL übermäßig stark gewichten.

Bei solchen Details kommt es eben sehr auf die spezifischen Bedingungen (z.B. Software), Inhalte und Ziele an.

Wichtig finde ich nur: Man sollte einen guten Grund für die Wahl der URL haben und nicht einfach blind nachbauen, was andere machen.
Andreas Borutta am 27.04.2009 · 21:46
Mich interessieren Deine Motive für die Bild-URLs.
Beispiel:
http://toscho.de/wp-content/uploads/2009/01/google-gefahr.png
auf
http://toscho.de/2009/alles-verseucht/

Verwendest Du
http://toscho.de/2009/alles-verseucht/google-gefahr.png
weil Du Dir die Option offenhalten möchtest, das Bild auf verschiedenen Seiten zu verwenden und Dir dann eine "neutrale" URL-Struktur lieber ist?
Als menschlicher Leser des Bild-URLs (z.B. bei der Weitergabe in einer Mail) empfinde ich die Teile "wp-content" und "uploads" als redundant/unverständlich.

Wo suche ich noch nach Inspiration und Argumenten im Bereich URL-Struktur?
Beim Thema "Subdomain versus Unterverzeichnis".
Zum Beispiel für das Anbieten des Webinhaltes in einem alternativen Format (PDF):
http://pdf.example.tld versus http://example.tld/pdf/

Oder beim Anbieten des gleichen Inhaltes in einer anderen Sprache:
http://en.example.tld versus http://example.tld/en/

Apropos PDF-URL:
Ich möchte auf die Debatte
http://xhtmlforum.de/51066-url-darstellung-post430745.html#post430338
hinweisen, an der ja auch Du, Thomas, beteiligt warst.

Der Name, der dem Nutzer beim Speichern eines PDF vorgeschlagen wird, sollte alle wesentlichen Informationen enthalten.
Wenn der kanonische Link lautet:
http://pdf.toscho.de/2009/beste-url-struktur/
Dann könnte
toscho-2009-beste-url-struktur.pdf
ein sinnvoller Name sein.
Aus Pfadbestandteilen werden sozusagen Dateinamensbestandteile.

Gruß, Andreas

PS: Freut mich, dass Du meine Anregung "Auf Wunsch Benachrichtigung beim Eintreffen von neuen Kommentaren, in Diskussionen, wo man beteiligt war." aufgegriffen hast.
Thomas Scholz am 27.04.2009 · 23:48
Die URLs der »echten« Dateien, die also nicht aus Datenbankinhalten zusammengesetzt werden, ist vor allem den Interna meines CMS (WordPress) geschuldet. Das kann man zwar bei der Installation besser einstellen, aber das habe ich verpaßt. Und im Nachhinein möchte ich das nicht mehr ändern, weil es recht aufwendig ist.

Ich würde solchen Dateien aber keinen Platz unterhalb eines Artikels geben – aus eben dem von dir genannten Grund: Wenn ich die Datei mal in einem anderen Zusammenhang benutze, paßt die URL entweder nicht, oder ich habe zwei Adressen für eine Ressource.

Am besten dürfte dafür eine Subdomain sein. Erstens erhöht das die mögliche Zahl paralleler HTTP-Request im Browser, zweitens wird dann aus der URL schon der zu erwartende Typ ersichtlich, und drittens ließe sich das einfacher verwalten. Die Subdomain img.toscho.de existiert schon; mal sehen, wie ich damit weiter verfahre …

Das Fallbeispiel der PDF-Dateien finde ich sehr schwierig: Einerseits möchte man sich nicht allzu sehr an ein bestimmtes CMS binden, andererseits die Kontrolle über die Metadaten zentral verwalten. Hinzu kommen diverse Browserbugs beim Umgang mit HTTP-Headern, wie man in den Anmerkungen zur PHP-Funktion header() exemplarisch lesen kann. Ich entscheide so etwas lieber projektbezogen. Und wenn ich mit einer schlechteren URL andere Vorteile erzielen kann, nehme ich sogar die in Kauf.
Andreas Borutta am 22.06.2009 · 08:55
Zum Thema "URL-Butchering":

Nutzer sollen sinnvollen Inhalt beim "Schlachten" erhalten. Das sehe ich wie Du.

Betrachten wir diejenigen Verzeichnisse für die kein anderer Inhalt existiert, außer einer Liste der im Verzeichnis enthaltenen Dateien/Unterverzeichnisse.

Machst ihr Euch dann die Mühe für jedes solcher Verzeichnisse eine Seite zu erstellen, oder erlaubt ihr für diese Verzeichnisse einfach das automatische Erzeugen einer Index-Seite durch den Apache-Server?

Falls Euch Apache-Index-Seiten zu unvollkommen sind:
lasst ihr die Datei-Listen für solche Seiten per PHP erzeugen?
Das würde mich interessieren.

Selber habe ich mal mit den Apache-Direktiven zur Erzeugnung einer Index-Seite herumgespielt.
Denn, wie ich gerade feststellte gibt es da durchaus einige nette Möglichkeiten, Einfluß zu nehmen.
```
# Verzeichnis-Index-Ausgabe erlauben
# http://httpd.apache.org/docs/2.2/de/mod/mod_autoindex.html#indexoptions
Options +Indexes
	# Sonderoptionen aktivieren - Hauptschalter
	IndexOptions FancyIndexing
	# Spalte "LastModified" "Icon" "Description" wird unterdrueckt
	IndexOptions SuppressLastModified SuppressDescription SuppressIcon 
	# Markup als table statt pre
	IndexOptions HTMLTable
	# Passende Sortierung, sobald Namen Nummern enthalten
	IndexOptions VersionSort
	# XHTML statt HTML
	IndexOptions XHTML
	# Noetige Breite für die Spalte Name
	IndexOptions NameWidth=*
	# Stylesheet einbinden
	IndexStyleSheet "/css/apache.css" 
```
~~Ansehbar auf: http://neu.simon-barber.com/music-musik/~~

Ich fände es praktisch von der ".htaccess" im Rootverzeichnis aus sämtliche Direktiven zu verwalten um nicht in den jeweiligen Unterverzeichnissen separate ".htaccess" warten zu müssen.

Es gibt die Direktive "Directory". Damit können Direktiven für ein explizites Verzeichnis angegeben werden.
Leider nicht für mehrere Verzeichnisse.

Gibt es da einen Weg, wie man Direktiven auf eine Liste von mehreren Verzeichnissen wirken lassen kann?

Gerne würde ich die Größenangaben in ein besseres Format bringen: "0,0 MB"
Also Dezimalzahl mit einer führenden Null vor dem Komma, mit einer Stelle hinter dem Komma, gerundet, Einheit "MB".

Aber dazu habe ich keine Apache-Direktiven gefunden.

Dann möchte ich den Bogen nochmal zum Kernthema "URL-Struktur" schlagen.
Ihr seht am Beispiel, dass der Name des Verzeichnisses zwei Wörter enthält: "music-musik".
Glücklich bin ich mit dieser Lösung für die zweisprachige Website (die sich in der Entwurfsphase befindet) meines Freundes Simon nicht.

Aber sowohl Audiofiles als auch Noten ("/score-noten/") gibt es nicht in verschiedenen Varianten für die beiden Sprachen.

Wie geht ihr in solchen Fällen vor?
Thomas Scholz am 22.06.2009 · 13:34
@Andreas Borutta: Auf URL-Butchering kann eine Seite ganz unterschiedlich reagieren. Wenn man hier in einer Themenseite steht, beispielsweise auf /thema/links/, und dann hochklettert, sollte man eigentlich auf /thema/ landen.

Das wäre aber schwachsinnig, denn alle Themen werden auch auf der Übersichtsseite aufgelistet, wo man sogar noch eine Menge zusätzlicher Informtionen bekommt. Also leite ich solche Anfragen auf eben diese Übersicht um:
```
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_URI} ^/thema/$
RewriteRule ^(.*)$ http://toscho.de/uebersicht/ [L,R=301]
```
Das erfüllt denselben Zweck, und es erspart mir Duplicate Content.

Echte Verzeichnisauflistungen kann man oft tatsächlich dem Apachen überlassen. Meine Subdomain für Bilder habe ich so organisiert. Ich bin recht zufrieden damit.

Die wesentlichen Direktiven:
```
Options +Indexes +Includes
IndexOptions +FancyIndexing Charset=UTF-8 DescriptionWidth=* 
IndexOptions +IconsAreLinks +IconHeight=16 +IgnoreCase +ScanHTMLTitles
IndexOptions +SuppressRules +XHTML +SuppressHTMLPreamble +HTMLTable +FoldersFirst
IndexIgnore .htaccess *.css *.shtml index.* favicon.ico robots.txt
AddType text/html .shtml
HeaderName /header.shtml
ReadmeName /readme.shtml
AddIcon /icon/type/folder.png ^^DIRECTORY^^
AddIconByType (img,/icon/type/img-generic-16.png) image/*
# Beschreibungen der Dateien und Verzeichnisse
AddDescription "Datei- bzw. MIME-Typen." type
# Als letzte Description ein Leerzeichen, damit
# die Tabelle besser aussieht.
AddDescription " " *
```
Die nächste Stufe wäre ein PHP-Script – glob() hilft dabei sehr.

Deine Fragen zu mehreren Verzeichnissen oder zum Dezimaltrenner kann ich nicht beantworten; so gut kenne ich mich leider nicht aus.

»music-musik« sieht wirklich etwas unglücklich aus. Ich bliebe hier bei der englischen Bezeichnung. Die versteht jeder, und das Ergebnis riecht nicht so sehr nach Suchmaschinenspamming. Zudem gibt der Apache sämtliche anderen Daten (Größe, Überschrift) ja auch nur in Englisch aus. Das Konsistenzgebot zeigt also sehr in diese Richtung.

Was mir dabei aber auffällt: Ich kann dieser Auflistung nicht entnehmen, welche Datei welchen Inhalt hat. Deshalb sollten entweder die Dateien besser benannt werden, oder du hilfst mit einer Beschreibung nach. Sicher möchtest du nicht, daß sich jeder bei der Suche nach einem Stück erstmal alle Dateien komplett herunterlädt. Das wird teuer.
Und wenn du doch den vollständigen Download erlauben willst, dann biete ein ZIP-Archiv an. Das wird bei MP3-Datein nicht viel Volumen sparen, aber es ist handlicher und erspart viele HTTP-Requests.

Du solltest übrigens eine robots.txt in diese Subdomain legen und das Indizieren verbieten, damit du später nicht eine Menge Duplikate in den Suchmaschinen hast. Also so:
```
User-agent: *
Disallow: /
```
Thomas Scholz am 22.06.2009 · 17:54
@Andreas Borutta: Zu den Noten: Lege doch in das Verzeichnis eine README. Die wird automatisch angehängt, und du kannst darin auf die sprachlich angepaßten Übersichten verlinken.

Wenn du die Metadaten der MP3-Dateien ausgeben willst, mußt du entweder ein Script benutzen – das sollte sein Ergebnis irgendwo speichern, damit es nicht bei jedem Aufruf loslegt – oder die Tabelle von Hand anlegen. Der Apache kann gerade einmal den Inhalt des Elements title aus einer HTML-Datei holen.

Letztlich geht es um Zugänglichkeit von MP3s auf Webseiten. Also um Arten der Einbettung, um Fallbacks, um Bedienelemente, um Tastaturbedienung, etc. etc.

Sieh dir bitte unbedingt mal die Musikbox in Opera Unite an! Der Player funktioniert gut, obwohl er sehr einfach ist. Zumindest wird ein laufendes Stück unterbrochen, wenn man ein anderes anklickt. Die Unite-Services sind einfache ZIP-Dateien, in denen du vom HTML- und Javascript-Code bestimmt wertvolle Inspiration erhältst.

Übrigends ist sogar das Taggen selbst noch ein offenes Thema bei ernster Musik. Einen guten Standard an dem ich mich orientieren kann, habe ich noch nicht gefunden.

Dazu habe ich noch einen Artikel in der Warteschleife … ich bin ein »Extremtagger«. ☻

Um mal den Bogen wieder zur URLs zurückzuschlagen: In foobar2000 kann man sich anhand der Metadaten eigene Hierarchien erstellen, beipielsweise %composer%/%conductor%/%date% – so kann man sich über parallele Strukturen zu einem Titel durchhangeln oder daraus eine Playlist erstellen. Das würde ich gerne mal in einem Webprojekt umsetzen. Die meisten CMS bieten das bisher nur über eine Ebene an, also Kategorie oder Schlagwort oder Datum etc.
Eine Oberfläche, in der der Leser diese und viele weitere Kriterien frei kombinieren kann, stelle ich mir als interessante Herausforderung vor.
Andreas Borutta am 22.06.2009 · 17:20
[Weiterleitung]

Volle Zustimmung. Zuerst sollte geprüft werden, ob nicht eine bereits existierende Seite, am besten als Ziel eines URL-Butchering geeignet ist.
Bei den Noten habe ich das erwogen, denn sie werden bereits in einer großen Übersichtstabelle aufgeführt.
Aber zum Einen ist das jeweils keine sprachlich neutrale Seite und zum Anderen ist eine solche schlanke Index-Seite als zusätzliches Angebot vielleicht für Blinde leichter zugänglich sei als nur eine fette Tabelle.

Aber abgesehen von den Überlegungen zu diesem konkreten Fall: Dein Grundgedanke ist absolut sinnvoll.

[Direktiven "HeaderName" und "ReadmeName"]

Gute Anregung.

[PHP: glob]

Kommt auf die ToDo.

[Verzeichnisname mehrsprachig]

Bei "music-musik" stimme ich Dir zu: da versteht jeder das englischsprachige Wort. Bei "score-noten" sieht es schon anders aus.

Aber: Mir widerstrebt es grundsätzlich, die Konsistenz im Merkmal "Sprache der im URL sichtbaren Bezeichner" zu brechen.
Übrigends findet das auch schon durch die Verwendung der Schlüsselwörter "work" bzw. "score" innerhalb der Dateinamen von Audio-Dateien und Noten statt.

Ja, auch die englischsprachigen Bezeichner wie "Size" in den Apache Index-Seiten sind mir ein Dorn im Auge.

[robots.txt]

Danke für den Hinweis. Hab' ich sofort nachgeholt.

[Fehlende Beschreibung]

Die genauen Merkmale zu einer Komposition (und damit indirekt auch zu einer Audio-Datei findet der Leser in der Übersichtstabelle.
Dennoch wirft Dein Einwand eine allgemeine Frage zu Beschreibungen von Audio-Dateien auf, die ausführlich mit MP3-Tags versehen sind?
Es wäre prima, wenn man sie einem Betrachter der Audio-Links zugänglich
machen könnte.
Aber das ist ein großes Thema für mindestens einen separaten Artikel.
Letztlich geht es um Zugänglichkeit von MP3s auf Webseiten. Also um Arten der Einbettung, um Fallbacks, um Bedienelemente, um Tastaturbedienung, etc. etc.

Mit dem Thema bin ich noch lange nicht durch.

Im XHTML-Forum gab es dazu keine hinreichend weiterführenden Hinweise.

Wie Du in der Übersicht sehen kannst, ist der aktuell eingesetzte Flash-Player ein Kompromiss. Definitiv kein "endgültiger".

Übrigends ist sogar das Taggen selbst noch ein offenes Thema bei ernster Musik. Einen guten Standard an dem ich mich orientieren kann, habe ich noch nicht gefunden.

Noch zu taggende Merkmale sind z.B.
```
%…% "http://simon-barber.com" (Website des Künstlers) 
%…% "Neue Musik" (Typ der Musik)
%…% "2009" (Jahr der Aufführung) 
%…% "Kammermusik" (Gattung)
%…% "Berlin" (Aufführungsort)
%…% "fl.vib.pf.gtr" (Instrumentierung)
%…% "Rundfunkchor Berlin" (Chor)
%…% "Bamberger Symphoniker" (Orchester)	
```
[ZIP Archive]

Im Moment möchte mein Freund Simon nicht soweit gehen, dass er das geballte Herunterladen erleichtern möchte.
Wer wirklich so viel laden möchte, dass ihn das einzelne Abrufen nervt, der muss sich eben um geeignete Downloadhilfen kümmern.

Noch kniffelt Simon an einer passenden "Ansage" zum kniffligen Thema Bezahlung.
Andreas Borutta am 22.06.2009 · 21:00
[Beispiel für Readme]

So hatte ich Dich verstanden.
Aber wenn der Nutzer stattdessen gleich die englischsprachige Übersichtstabelle sieht, ist das doch von Vorteil, oder?
Und ein deutschsprachiger Nutzer hat zumindest keinen Nachteil gegenüber der Readme. Denn er findet auf der englischsprachigen Übersichtstabelle ja den Link zur deutschsprachigen Übersichtstabelle.

[Datenbank]

Meines Wissens nach, darf eine Datenbank aus einer einzigen Tabelle bestehen.
Eine gute Datenbank wird selbstverständlich normalisiert. Dabei wird typischerweise die ursprüngliche Tabelle Schritt für Schritt in mehrere Tabellen aufgesplittet und Beziehungen zwischen den Tabellen festgelegt.

[Unite]

Hhmm. Mir ist noch nicht klar, was Du mit "mir selber einrichten" meinst.
Es geht doch darum auf einer Website (für andere) einen Player einzubinden.
Andreas Borutta am 22.06.2009 · 20:18
@Thomas Scholz:

[Readme für Noten]

Welchen Mehrwert erhält ein Nutzer bei einer Readme-Seite gegenüber der schon existierenden Übersichtstabelle?
Ich vermute: keinen.

Auch in der Übersichtstabelle findet jemand, der die Sprache der Seite nicht spricht, den Link zur Version in anderer Sprache leicht (ich hoffe die Position rechts oben ist prominent genug und entspricht typischen Erwartungen).

[Metadaten für MP3s ausgeben]

Die Inhalte der Tags einer MP3-Datei kann man ja als einen Datensatz auffassen. Ein Verzeichnis mit mehreren MP3-Dateien kann man als "Datenbank" auffassen. Es würde mich reizen, diese MP3-Datenbank mit einer Datenbank des Werkes zu verknüpfen.
Dann könnte man aus beiden Datenbanken "alle nötigen HTML-Inhalte" generieren lassen.

Aber das sind (für mich noch) reine Gedankenexperimente. Ich bin mit Datenbanken vollkommen unerfahren. Aktuell sammele ich jedenfalls alle Attribute des Werkes des Komponisten. Dabei nehme ich beim "Storming" bewußt keine Attribute auf, die schon als MP3-Tag existieren.

Zurück zu Skripten, die MP3-Tags auslesen können.
Es gibt ein PHP-Paket "GetID3". Damit soll es gehen. Eine Beschäftigung damit steht auf meiner ToDo. Nützlich wäre für mich ein hübsches Tutorial mit Beispielen zu dessen Einsatz.
Ob mein Provider den Einsatz solcher Pakete überhaupt erlaubt müsste ich auch noch rausfinden.

[Extremtagger Toscho]

Ich freue mich auf Deinen Artikel :)

[Musikbox Opera Unite]

Denkst Du an eine bestimmte Seite, wo MP3s mit diesem Player eingebunden sind?

[foobar2000]

Den verwende ich auch. Ja, die Konfiguration ist nicht ohne.

Ich habe bisher geringe Ansprüche an die Funktionalität eines Players. Selber nutze ich foobar2000 vor allem, weil er mir ein äußerst puristisches Interface erlaubt.
Ich höre Musik fast immer an Alben orientiert.

Du kannst Dir sicher vorstellen, dass mir der aktuelle Zustand noch nicht puristisch genug ist ;)

* Titelleiste: per Wechselsschalter ein- und ausblenden
Noch besser: Vollbildmodus, also Titelleiste, Menüleiste und Statusbar per Wechselschalter ein- und ausblenden

* Bildschirmschoner: Nach einer festgelegten Zeit ohne Aktionen des Nutzers, soll FB automatisch in einen Vollbild-Cover-Modus schalten. Dieser wird durch eine beliebige Aktion per Tastatur/Maus beendet (wie ein Bildschirmschoner)

* Seekbar (Fortschrittsbalken): Ersetzen duch eine Visualisierung des Fortschritts durch die Hintergrundfarbe der Zeile mit dem aktuell laufenden Stück.

* Spaltenköpfe des Filters: ausblenden

* Suchfeld: Ersetzen durch "Search as you type" (wie bei Firefox)

Das Bedienelement "Lautstärke" musst Du Dir wegdenken. Ich verändere die Lautstärke per Tastatur. Irgendwann mal möchte ich auf den gesamten Musikbestand per Smartphone mit Touchscreen zugreifen. Aber ich war und bin ein schlechter Konsument. Diese Gadgets sind mir alle nicht ausgereift genug. Oder es fehlen zig Eigenschaften die mir wichtig wären. Das wird noch sehr lange so bleiben. Oder sich nie ändern, weil meine Wünsche von zu wenigen geteilt werden. Gut, dass meine Zufriedenheit nicht vom Besitz von Gadgets abhängt :)
Dann doch eher von einer guten URL-Struktur.

Was, dieser Bogenschlag überzeugt Euch nicht?! ;)
Thomas Scholz am 22.06.2009 · 21:19
@Andreas Borutta: Natürlich ist es besser, gleich eine ausführliche Übersicht anzubieten. Ich hatte dich so verstanden, daß beide Fälle möglich sind.

Technisch gesehen kann eine Datenbank durchaus nur eine Tabelle enthalten. Das ist aber selten sinnvoll. Eine allmähliche Umstellung ist fehleranfällig und umständlich; überdies läuft man Gefahr, zu spät umzustellen, also schon Daten einzutragen, die eigentlich in eine andere Tabelle gehören.

Unite: Lade dir einfach mal die aktuelle Betaversion herunter, und sieh es dir an. Die Musikbox ist schon an Bord. Ich meinte nicht, daß du mit ihr deine Version ersetzen sollst, sondern daß du aus ihrem Code etwas lernen kannst.
Thomas Scholz am 22.06.2009 · 20:40
@Andreas Borutta: Mit der Readme-Datei meine ich einfach ein Stück HTML-Text mit Links auf die »richtigen« Übersichtsseiten, keine Doppelung. Beispielsweise so:
```
<p>
  <a href="/overview/">Extended Overview</a> · 
  <a href="/ueberblick/">Erweiterte Übersicht</a>
</p>
```
Ein Verzeichnis mit mehreren MP3-Dateien kann man als "Datenbank" auffassen.

Nein, eigentlich nicht. Eine Datenbank bildet Beziehungen ab; das Verzeichnis entspricht bestenfalls einer Tabelle darin.

Opera Unite

Denkst Du an eine bestimmte Seite, wo MP3s mit diesem Player eingebunden sind?

Richte es dir selbst einfach mal ein. Aus naheliegenden Gründen möchte ich keine Musik öffentlich zugänglich machen. Du kannst aber deine eigene Unite-Box binnen 5 Minuten erstellen und diese dann ausprobieren.

Ich höre Musik fast immer an Alben orientiert.

Das mache ich auch manchmal, aber durch gezieltes Tagging habe ich mir auch eine Playlist erstellt, die italienischsprachige Opern des 17. Jahrhunderts enthält, die ich seit mindestens drei Monaten nicht mehr gehört habe.
Das rockt! ☻

Das Interface ist mir hierbei weitgehend schnuppe; der Player läuft fast immer im Hintergrund.
Thomas Scholz am 22.06.2009 · 23:04
@Andreas Borutta: »Datenkuddelmuddel« – sowas kann mir echt den Schlaf rauben! ☺

Ich benutze beim Taggen nur die Metadaten der jeweiligen Datei, die dann mit der internen Foobar-DB synchronisiert werden. Deren Binnenstruktur kenne ich nicht.

Bei Unites Interface kannst dur dir nicht nur den Code abgucken, sondern auch die großen Buttons. Die trifft man selbst auf einem Handy noch gut. In deiner aktuellen Version finde ich das ein bißchen zu schwierig.
Andreas Borutta am 22.06.2009 · 22:32
[Datenbank]

Vielleicht können wir uns darauf einigen, dass ein Verzeichnis mit sorgfältig und systematisch getaggten MP3s als eine Datenbank in ihrer noch nicht normalisierten Form aufgefasst werden kann.
Perfekt geeignet um, in undisziplinierten Händen, wunderbar inkonsistentes Datenkuddelmuddel zu erzeugen.

Nutzt Du als Extremtagger eine richtige Datenbank aus der heraus dann Deine MP3s getaggt werden?
Oder taggst Du (wie ich) einfach in Form einer einzigen riesigen Tabelle, wie es z.B. ein Werkzeug wie MP3Tag bereitstellt?

[Unite]

Hab' mich mal angemeldet. Das Interface des Media-Players gefällt mir gut: Screenshot [05.01.10: Toten Link entfernt, toscho]
Andreas Borutta am 23.06.2009 · 00:08
Hätte nicht gedacht, dass Du zum Taggen keine Hilfswerkzeuge einsetzt. Ich schätze die Erleichterung durch MP3Tag sehr.

Mit "Code abgucken" wird das bei meinen Programmierunkenntnissen nix.

Ja, um die Vergrößerung der Buttons komme ich wohl nicht herum. Ich wollte knausern mit der Zeilenhöhe, weil die Übersichtstabelle etwa 120 Zeilen enthalten wird.
Daniel Hecht am 09.02.2011 · 16:01
Ich habe große Probleme mit dem Tipp.Bekomme die ganze Zeit 500 Error angezeigt. Ist es irgendwie möglich in der url von WordPress die Hauptkategorie und danach die Unterkategorie anzuzeigen?
Thomas Scholz am 09.02.2011 · 16:09
@Daniel Hecht: Nein, das geht nicht. Die Ursache des 500ers findest du im Errorlog; das stellt normalerweise dein Webhoster bereit.
Sebastian Wagner am 09.09.2011 · 02:01
Ich habe mehrere Kategorien gewählt, will aber eine bestimmte in der Url als Basis haben. Bei der Suche nach einer Lösung komme ich immer wieder auf diesen Beitrag, aber leider wird dieses Thema hier nicht behandelt.

Also 2 Kategorien zm Beispiel Miesbach und Tegernsee. Die Artikel werden immer in mit beiden Kategorien veröffentlicht aber die Kategorie für die URL sucht sich WordPress automatisch aus. Wenn WordPress jetzt Kategorie 1 in die URL schreibt, kann man das doch sicher irgendwie ändern oder?
Thomas Scholz am 09.09.2011 · 02:36
WordPress nimmt die älteste Kategorie der Datenbank, glaube ich. Das ist unabhängig vom einzelnen Beitrag. Es gibt mindestens ein Plugin, das sich um diesen Mechanismus herum hackt. Allerdings sind Permalinks mit %category% enorm fehleranfällig, daran wird im Core laufen geschraubt. Wie vorwärtskompatibel so ein Plugin ist, sei mal dahingestellt.
Martin Sabel am 13.12.2011 · 13:17
Hallo toscho,

bei der Suchmaschinenoptimierung sollte man z.B. die Jahreszahlen/Time etc. nicht als mögliche Ordnerstrukturen verwenden - denn es hat ja keinen Sinn. Du willst ind er URL vor allem eines - Keywords und die kannst eben mit der %category% am besten machen. Ich konnte keine verlangsamung feststellen - ehrlich.

← PHP-Funktion Genitiv Browser frischt entflammt →

toscho.design

Die beste URL-Struktur. Permalinks in WordPress

Bedingungen

Lösung

23 Kommentare