Service-Themen

Warum es sinnvoll ist, seine Webseite auf SSL umzustellen, hatten wir in unserem letzten Blogbeitrag beschrieben.

Wie das bei einer Drupal-Webseite geht, erklären wir im Folgenden.

Als erstes besorgt man sich ein SSL-Zertifikat für zu sichernde Domain und installiert dieses auf dem Webhosting-Account auf dem die Webseite läuft. Wie das geht ist von Provider zu Provider verschieden, so dass wir hier nicht näher darauf eingehen. Sobald das Zertifikat installiert ist, können wir die Drupal-Konfiguration anpassen.

Zunächst ändern wir die Datei settings.php im Unterordner ../sites/default/. Hier tragen wir am Ende der Datei die Zeile

 $_SERVER['HTTPS'] = 'on';

ein.

Falls auch ein Wert für $base_url gesetzt wurde, so stellen wir diesen auf https um. Das sieht dann beispielsweise so aus:

 $base_url = "https://www.example.com" // NO trailing slash!

Jetzt speichern wir die settings.php ab. Bitte nicht vergessen den Schreibschutz wieder zu setzen!

Jetzt müssen wir noch die .htaccess anpassen. Hier ergänzen wir nach dem Eintrag

 RewriteEngine on

diese beiden Zeilen:

 RewriteCond %{HTTP_HOST} !^meine-domain\.de$ [NC,OR] RewriteCond %{HTTPS} =off RewriteRule ^(.*)$ https://meine-domain.de/$1 [R=301,L]

Im folgenden Abschnitt entfernen wir die Kommentarzeichen der Rewrite-Regel:

 RewriteRule ^ - [E=protossl] RewriteCond %{HTTPS} on RewriteRule ^ - [E=protossl:s]

Zum Abschluss speichern wir die .htacces noch ab und unsere Webseite läuft ab sofort SSL-gesichert. Außerdem werden Aufrufe der Seite mit dem ungesicherten http auf https umgeschrieben.

Piwik umstellen

Wer zum Tracken seiner Seitenbesucher Piwik benutzt, muss noch eine Änderung im Piwik-Modul vornehmen: In den Modul-Einstellungen muss im Feld "Piwik HTTPS URL" die URL zur Piwik-Installation mit https eingetragen werden. Falls diese auf einer anderen Domain läuft, als unsere Drupal-Webseite muss auch auf dieser ein SSL-Zertifikat installiert werden!

Anschließend läuft das Tracking der Webseite mit Piwik wie gewohnt weiter.

Für Unternehmen gibt es mehrere Gründe, warum sie ihre Webseiten verschlüsselt ausliefern sollten. Werden sensible Daten wie z.B. Passwörter oder Bankdaten auf der Seite abgefragt, sollte eine Verschlüsselung bei der Übertragung selbstverständlich sein.

Darüber hinaus liefert Google weitere Argumente für die Nutzung von SSL-Verschlüsselung: So sollen Webseiten mit aktiver Verschlüsselung (erkennbar an dem "https" in der URL) im Ranking bevorzugt behandelt werden. Auch wenn der Faktor HTTPS zur Zeit wohl nur sehr gering im Rankingalgorithmus gewichtet ist, sollte man ihn beachten. Zumal nicht auszuschließen ist, dass er künftig an Gewicht zunimmt.

Einen weiterern Grund für Verschlüsselung liefert der Chrome-Browser. Ab Januar 2017 wird Chrome Nutzer davor warnen, wenn eine Webseite ein Passwort oder Kreditkarteninformationen über eine unverschlüsselte Website übertragen soll. Verfügbar ist diese Funktion ab der Chrome-Version 56. Dabei handelt nach Angaben von Google nur um einen ersten Schritt. Später soll der Browser auch an anderen Stellen vor unverschlüsselten Webseiten warnen.

Die jährlichen Kosten für ein SSL-Zertifikat sind überschauber. Let’s Encrypt bietet ein einfaches Domain-Validation-Zertifikat sogar kostenlos an. Aber auch kommerzielle Zertifikate bekommt bereits für unter 40€ im Jahr.

Ab sofort steht für alle Webhosting-Accounts auch die PHP-Version 7 zur Verfügung.

Hierbei handelt es sich um eine neue Hauptversion,die viele Neuerungen und einige Leistungssteigerungen mitbringt. So verringern sich die Zugriffszeiten zum Teil deutlich. Darüber hinaus wird 64-Bit ab sofort konsequent unterstützt. Außerdem haben die Entwickler Probleme der vorherigen Version behoben.

Vor einer Umstellung auf die neue PHP-Version empfiehlt es sich unbedingt zu prüfen, ob die eingesetzte CMS-Software bereits mit dieser Version zusammenarbeitet. Andernfalls kann es zu Störungen oder dem Ausfall Ihrer Webseite kommen. Gerne beraten wir Sie ob eine Umstellung für Sie machbar ist.

Selbstverständlich stehen die älteren Versionen von PHP auch weiterhin zur Verfügung. Derzeit kann zwischen den Versionen PHP4, 5.2, 5.3, 5.4, 5.5, 5.6 und 7 gewählt werden.

Gut acht Jahre nach dem Erscheinen von Drupal 6 hat dieses nun mit der Freigabe der stabilen Version von Drupal 8 sein "End-of-Life" erreicht. Nachdem wir mit mehreren unserer Kunden darüber diskutiert haben, was dies für ihre Webseiten bedeutet, möchten hier einen Überblick über die aktuelle Situation und mögliche Optionen geben.

Das neue Drupal 8

Mit dem aktuellen Erscheinen von Drupal 8 endet der offizielle Support für Drupal 6. Das bedeutet, dass

  • es keine neuen Updates des Drupal-Core mehr geben wird,

  • das Drupal Sicherheitsteam keinen Support mehr leisten und keine Sicherheitsupdates mehr veröffentlichen wird,

  • Drittmodule für Drupal 6 offiziell nicht länger unterstützt, upgedated oder dokumentiert werden.

Man ist also bei einer Drupal 6-Seite darauf angewiesen, dass man noch Unterstützung in der Community findet.

Für alle, die derzeit Drupal 6 einsetzen,bedeutet dies, dass es unbedingt erforderlich ist, sich Gedanken über die Zukunft der Webseite zu machen. Dabei stellen sich vor allem folgende Fragen:

  • Reicht es aus, die Sicherheit der Seite, durch zusätzliche Maßnahmen zu verbessern?

  • Ist ein Upgrade auf eine neuere Drupal-Version erforderlich?

  • Welches ist die bessere Wahl bei einem Upgrade, Drupal7 oder Drupal 8?

Viele Faktoren spielen bei der Beantwortung dieser Fragen eine Rolle. Besitzt die Webseite komplexe Funktionen, die ggf. durch speziell programmierte, eigene Module realisiert wurden? Wieviele Module müssen upgegradet werden? Ist es schwierig oder eher einfach, das verwendete Theme upzugraden oder muss ein neues verwendet werden, damit die Seite beispielsweise für Mobilgeräte optimiert wird?

In den meisten Fällen empfiehlt es sich, zunächst einmal einen Schritt zurück zu gehen und die bestehende Drupal-Webseite zu bewerten: Erfüllt sie noch alle Anforderungen, die man aktuell an seine Seite stellen würde? Nicht selten ist ein einfaches Upgrade nicht ausreichend und ein umfangreicheres Redesign empfehlenswert. Falls dieses ohnehin schon angedacht wurde, ist es kostengünstiger, dieses mit dem Upgrade zu verbinden.

Soll ich meine Webseite auf Drupal 7 oder Drupal 8 upgraden?

Auch wenn das neue Drupal 8 mit vielen neuen Funktionen glänzt, die bisher nicht oder nur durch Dritt-Module realisierbar waren, ist in vielen Fällen immer noch Drupal 7 das System der Wahl.

Zum einen handelt es sich um eine ausgereifte Software, für die es viele Dritt-Module als Erweiterungen gibt, mit denen man sehr viele Anforderungen realisieren kann, ohne eigenen Programmcode schreiben zu müssen. So kurze Zeit nach dem Erscheinen der neuen Drupal-Version stehen viele dieser Module noch gar nicht für Drupal 8 zur Verfügung. Erfahrungsgemäß kann es noch weitere 6 bis 12 Monate dauern, bis sich diese Situation entscheidend verbessert hat.

Zum anderen kann man damit rechnen, dass Drupal 7 noch weitere 4 Jahre oder (wahrscheinlich) länger supportet wird.

Ausschlaggebend für die Entscheidung, ob ein Upgrade auf Drupal 7 oder Drupal 8 erfolgen sollte, ist die Bewertung der Situation bei den eingesetzten Dritt-Modulen. Dabei sollte auch die Struktur der Inhalte analysiert werden. Häufig bietet es sich an, bei einem Upgrade die Inhaltestruktur zu vereinfachen. Dies kann auch zu einer Vereinfachung der redaktionellen Arbeiten führen.

Was ist, wenn ich keine Ressourcen für ein Upgrade meiner Drupal-Webseite habe?

Eine Drupal 6-Webseite ist in der Regel mindestens 5 Jahre alt. Es drohen mit dem Wegfall des Supportes Sicherheitslücken. Diese sind umso wahrscheinlicher, je offener die Seite für Besucher ist. Handelt es sich um eine Community-Seite mit zahlreichen, nicht näher verifizierten und damit weniger vertrauenswürdigen Usern, oder bietet die Seite die Möglichkeit Kommentare oder User-Content einzustellen, so sind die Risiken erheblich höher, als wenn nur eine handvoll bekannter Benutzer Zugang zum Backend hat. Hier sollte zumindest geprüft werden, ob man z.B. das Login-Formular stärker absichern kann oder potenziell sicherheitsrelevante Funktionen (wie Kommentare) ganz abschaltet.

Zu weiteren Schwierigkeiten kann es mit der Hosting-Umgebung bei verschiedenen Anbietern kommen. In diesem Fall kann zumindest vorübergehend Abhilfe durch die Wahl spezieller Hosting-Accounts oder einen Anbieterwechsel geschaffen werden.

Durch diese Maßnahmen läßt unter Umständen Zeit gewinnen, bis ein Budget für ein Upgrade zur Verfügung steht.

Gelingt dies nicht, sollte man die Zukunft seiner Seite nicht aus den Augen verlieren und notfalls ein Downgrading der Webseite zu einer statischen Seite oder einen Wechsel des CMS in Betracht ziehen.

Macht ein Upgrade meiner Drupal 7 Webseite auf Drupal 8 Sinn?

Da Drupal 7 noch auf Jahre hinaus supportet wird und viele neue Funktionen für Drupal 8 auf die Version 7 zurück portiert werden, ist derzeit ein Wechsel auf Drupal 8 nicht empfehlenswert. Eine Ausnahme kann sich ergeben, wenn ohnehin ein umfassender Relaunch der Seite angedacht ist. Dann sollte man die Option eines Upgrades zumindest prüfen, da das Upgrade die Lebensdauer der Seite erheblich verlängert und die Kosten u.U. geringer sind, als wenn später ein eigenständiges Upgrade erfolgt.

Womit sollte ich eine neue Webseite aufbauen?

Wenn eine völlig neue Seite geplant ist, sollte Drupal 8 gewählt werden, sofern die Anforderungen mit dieser Version und den derzeit verfügbaren Dritt-Modulen realisierbar ist. Ist dies nicht der Fall und sind die fehlenden Funktionen kritisch, empfiehlt sich in der Regel der Einsatz von Drupal 7. Zwar lassen sich fehlende Funktionen durch eigenen Programmcode nachrüsten. Die Kosten hierfür sind aber um ein Vielfaches höher, als wenn vorhandene Module zum Einsatz kommen, die nur konfiguriert werden müssen. Die längere Lebensdauer einer Drupal 8 Installation muss dabei natürlich mit einkalkuliert werden.

Fazit

Wer derzeit noch eine Webseite mit Drupal 6 betreibt sollte unbedingt die Zukunft seiner Seite planen. Momentan ist der Handlungsbedarf aber noch nicht dringend. Dies wird sich jedoch im Laufe der Zeit ändern, da die Anzahl der Drupal 6 Seiten im Einsatz ebenso abnehmen wird wie die Bereitschaft der Community, für dieses System oder die dazugehörigen Dritt-Module noch Support zu leisten.

Mit dem heutigen Tag stellt Microsoft den Support für die Internet Explorer-Versionen 8, 9 und 10 ein. Künftig gibt es Sicherheitsupdates nur noch für die Version 11. Wir empfehlen daher allen unseren Kunden, die den Internet Explorer nutzen, zu überprüfen, welche Version sie im Einsatz haben und umgehend auf die aktuelle Version 11 upzugraden. Weitere Informationen hierzu findet man auf der Webseite von Microsoft unter https://www.microsoft.com/de-de/WindowsForBusiness/End-of-IE-support

Ab sofort können viele weitere interessante Top-Level-Domains (TLDs) bestellt werden. Hier eine kleine Auswahl der neuen Domains. Hier finden Sie die vollständige Liste aller derzeit registrierbaren Domains.

  • .download
  • .win
  • .online
  • .tech
  • .news
  • .co
  • .plus
  • .one
  • .style
  • .casino
  • .ngo
  • .design
  • .money
  • .science
  • .nrw
  • .coach

Ab sofort steht für alle Webhosting-Accounts auch die neueste PHP-Version 5.6 zur Verfügung. Neben den üblichen Bugfixes und Verbesserungen gibt es eine Reihe wichtiger Sicherheitsupdates.

Zusätzlich ist ab sofort die User-Cache-Extension APCu für PHP 5.5 und PHP 5.6 erhältlich. Vor einer Umstellung auf die neue PHP-Version empfiehlt es sich unbedingt zu prüfen, ob die eingesetzte CMS-Software bereits mit dieser Version zusammenarbeitet.

Andernfalls kann es zu Störungen oder dem Ausfall Ihrer Webseite kommen. Gerne beraten wir Sie ob eine Umstellung machbar ist.

Selbstverständlich stehen die älteren Versionen von PHP auch weiterhin zur Verfügung. Derzeit kann zwischen den Versionen PHP4, 5.2, 5.3, 5.4, 5.5 und 5.6 gewählt werden.

Als ich dieser Tage auf Google das Ranking für eine Kundenwebseite überprüft habe (einfach mal die Suchbegriffe eingeben, unter denen die Kundschaft gefunden werden möchte und dann schauen, ob und wo man sie findet), sprang mir einer dieser Suchergebnis-Zombies entgegen:


Herzlich Willkommen bei xyz


www.xyz.de


Und dann noch ein nichtssagender Text, den man auf der Webseite gar nicht wiederfindet.


Ich musste in mich hinein kichern ...


Ja, ich weiß, es klingt hart, aber "Herzlich Willkommen" will niemand lesen. Weder die Suchmaschine, noch die Kundschaft.


Regelverstöße en masse


Man macht oft den Fehler, nach dem eigenen Namen oder sogar der Domain zu googlen und siehe da: Steht auf Seite 1 bei Google ganz oben und sieht klasse aus! Äh, ja. Aber machen Sie sich mal die Mühe, nach ihrer Dienstleistung/ihrem Angebot zu suchen. Und? Finden Sie sich? Wie oft müssen Sie das verfeinern, um endlich auf Seite 1 zu landen – wenn überhaupt?


Regel Nr. 1 beim Vergeben von Seitentiteln oder Überschriften: Rechtschreibung beachten! Es heißt immer noch "herzlich willkommen". Das mag kleinlich klingen, ist aber wichtig. Dass wir nach x Rechtschreibreformen in Deutschland leider alle nicht mehr so richtig sattelfest sind bei der Rechtschreibung, ist eine traurige Tatsache.  Aber "willkommen" in Verbindung mit "herzlich" hat man schon immer klein geschrieben. Und wird es wohl auch weiterhin tun.


Regel Nr. 2: Besonders Seitentitel, die innerhalb von <head> <title> stehen, haben es in sich. Die werden nämlich von Google gerne als die große blaue Überschrift genommen ... Was bieten wir denn genau an außer einem warmen Willkommen (das man in diesem Fall groß schreibt, weil es im Satz als Substantiv verwendet wird! ;-))? Wenn ich bei Google die Suchergebnisse mit den Augen durchscanne, klicke ich mit Sicherheit auf solche, die mir schon gleich möglichst genau vermitteln, was die Webseite und meine Suche miteinander zu tun haben.


Noch mehr Regelverstöße? Darüber können wir im Rahmen einer Suchmaschinenoptimierung gerne reden. ;-)


Dürfen wir mal prahlen?


Auch wenn unsere Seite momentan dringend auf eine optische Überarbeitung und mobile Benutzbarkeit wartet, unser Suchergebnis liest sich 1 A:


webtotum - Rüdiger und Thau GbR - Webauftritte nach Maß


www.webtotum.de/


webtotum Webdesign und Webhosting. Maßgeschneiderte Weblösungen. Spezialisten für Drupal, Joomla und Wordpress.


Gesehen? Wir bringen den Firmennamen unter, unseren Claim und eine kurze Beschreibung unseres Angebots. Ab hier mag sich der Suchende entscheiden, ob das für ihn interessant ist. Differenziertere Suchen ergeben noch viel schönere Ergebnisse.


Okkultes Geheimwissen


Wie um alles in der Welt haben wir das bloß geschafft? Als erstes haben wir tatsächlich unseren <head> sorgfältig gepflegt. Ab und an tut eine Kopfwäsche ja gut.


Außerdem mag Google uns, weil wir mehr oder wenig regelmäßig Content bieten, also Inhalte. Blogbeiträge, die wir – zugegebenermaßen schamlos –  dazu nutzen, unsere Keywords auszuschlachten.


Das Zauberwort lautet schon lange "Inhalte" und auch seit Anbeginn der Suchmaschinenoptimierung "Technik". Suchmaschinen arbeiten inzwischen sehr viel differenzierter als noch vor 5 Jahren. Sie werten nicht mehr stur feste Elemente aus, sondern arbeiten inhaltlich. Schon immer mochten sie es, wenn man sie dabei nicht durch schlechte Programmierung stört. Also gehört auch ein ordentlich strukturierter Quellcode einer Webseite zur guten Suchmaschinenoptimierung.


Seit einigen Wochen achtet Google auch auf die geräteübergreifende Erreichbarkeit. Es liebt also Seiten, die auch auf Smartphones und Tablets noch bedienbar sind, mehr als die alten Lappen mit ihrer Optimierung für 1024 x 768 Pixel Bildschirmauflösung. Trotzdem wird eine mobil optimierte Seite ohne nennenswerte Inhalte im Google Ranking nicht nach oben rutschen. Hier greift wieder das Zauberwort!

Die Core-Suchfunktion von Drupal ist nicht gerade eine der Stärken dieses ansonsten gelungenen CMS. Und so gibt es zahlreiche Module, um diese wichtige Funktion aufzupeppen. Wer die Suchfunktion jedoch grundsätzlich verbessern will, sollte sich Apache Solr anschauen. Mittlerweile ist die Installation auf dem eigenen Server nicht mehr so schwierig und es stehen mehrere Drupal-Module zur Verfügung, um einen Apache Solr Server in Drupal zu integrierem und diesem die Indizierung der Inhalte anzuvertrauen.

Wie das geht, zeigen wir in diesem Beitrag am Beispiel von Apache Solr 4.10..4 und dem Drupal-Modul Apache Solr Search.

Voraussetzung ist, dass man einen SSH-Zugang zu seinem Server hat.

Schritt 1: Zunächst loggt man sich per SSH auf seinem Server ein und lädt die neueste Version 4 von Solr herunter (es gibt auch eine Version 5, aber die haben wir nicht getestet, daher basiert diese Anleitung auf der Version 4) mit

wget http://artfiles.org/apache.org/lucene/solr/4.10.4/solr-4.10.4.tgz

Anschließend entpackt man dieses Tar-File

mit

tar -xvzf solr-4.10.4-src.tgz

Hinweis: Das Verzeichnis, in das Solr entpackt wurde, sollte aus Sicherheitsgründen außerhalb des Document-Root-Verzeichnisses des Webservers liegen und damit natürlich auch außerhalb des Drupal-Verzeichnisses.

Unser Solr liegt jetzt im Verzeichnis ~/solr-4.10.4

Das überflüssige tar-Archiv kann man nun löschen:

rm solr-4.10.4-src.tgz

Schritt 2: Jetzt installiert man das Drupal-Modul Apache Solr Search entweder per Drush oder über das Admin-Backend von Drupal und aktiviert es wie gewohnt.

Schritt 3: Als nächstes müssen einige Konfigurationsdateien von Solr durch die im Drupal-Modul mitgelieferten ersetzt werden. Wir wollen mit dem im Solr-Paket mitgelieferten Beispiel arbeiten. Dieses befindet sich im Verzeichnis ~/solr-4.10.4/example. Im Unterverzeichnis ~/solr-4.10.4/example/solr/collection1/conf benennen wir zunächst drei Dateien um:

<br />
mv protwords.txt protwords.bak<br />
mv schema.xml schema.bakr ja fast noch zu kühl&nbsp;<br />
mv solrconfig.xml solrconfig.bak

Jetzt müssen  wir die Dateien protwords.txt, schema.xml und solrconfig.xml aus dem Modulverzeichnis hierher kopieren. Für die Version 4 von Solr benötigen wir die Dateien aus dem Verzeichnis ~/www/sites/all/modules/apachesolr/solr-conf/solr-4.x (~/www ist in diesem Beispiel das Root-Verzeichnis unseres Webservers in dem unser Drupal liegt)

[code
]cd ~/www/sites/all/modules/apachesolr/solr-conf/solr-4.x
cp protwords.txt ~/solr-4.10.4/example/solr/collection1/conf
cp schema.xml ~/solr-4.10.4/example/solr/collection1/conf
cp solrconfig.sml ~/solr-4.10.4/example/solr/collection1/conf[/code]

Anschließend prüfen wir noch, ob alle für den Start notwendigen Dateien in unserem Beispiel vorhanden sind. Dazu wechseln wir zu

cd ~/solr-4.10.4/example/solr/collection1/conf

Dort sollten folgende Dateien liegen:

solrconfig.xml
schema.xml
elevate.xml
mapping-ISOLatin1Accent.txt
protwords.txt
stopwords.txt
synonyms.txt

(und natürlich unsere drei .bak-Dateien). Wenn alles da ist wechseln wir in das Verzeichnis ~/solr-4.10.4/example

Schritt 4: Nun können wir Solr starten. Dazu geben wir auf der Kommandozeile

java -jar start.jar

ein. Es wird eine längere Liste von Statusmeldungen ausgegeben, die am Ende so aussehen sollte:

3915 [main] INFO&nbsp; org.apache.solr.servlet.SolrDispatchFilter&nbsp; â SolrDispatchFilter.init() done<br />
3934 [main] INFO&nbsp; org.eclipse.jetty.server.AbstractConnector&nbsp; â Started SocketConnector@0.0.0.0:8983<br />
3947 [searcherExecutor-6-thread-1] INFO&nbsp; org.apache.solr.core.SolrCore&nbsp; â [collection1] webapp=null path=null params={start=0&amp;event=firstSearcher&amp;q=solr+rocks&amp;distrib=false&amp;rows=10} hits=0 status=0 QTime=34<br />
3948 [searcherExecutor-6-thread-1] INFO&nbsp; org.apache.solr.core.SolrCore&nbsp; â QuerySenderListener done.<br />
3948 [searcherExecutor-6-thread-1] INFO&nbsp; org.apache.solr.handler.component.SpellCheckComponent&nbsp; â Loading spell index for spellchecker: default<br />
3952 [searcherExecutor-6-thread-1] INFO&nbsp; org.apache.solr.core.SolrCore&nbsp; â [collection1] Registered new searcher Searcher@6b340157[collection1] main{StandardDirectoryReader(segments_5:12:nrt _3(4.10.4):C56)}

Hinweis:  Für Testzwecke genügt es, wenn man Apache über die SSH-Konsole startet. Für den späteren Betrieb sollte man unbedingt einen automatischen Start einrichten.

Schritt 5: Abschließend konfigurieren wir noch das Drupal Solr Search Modul, das wir in Schritt 2 installiert und aktiviert haben. Dazu gehen wir auf "Konfiguration >> Suche und Metadaten >> Apache solr search >> Einstellungen" und tragen dort die URL unseres eben gestarteten Solr-Servers ein. Da sich dieser in unserer Testumgebung auf dem gleichen virtuellen Server befindet, lautet die URL localhost:8983/solr (8983 ist der Standardport von Apache Solr).

Einstellungen des Apache Solr search Moduls von Drupal 7

Nach dem Eintragen der URL (die übrigen Einstellungen lassen wir unverändert) klicken wir einmal auf "Test connection". Wenn alles funktioniert, meldet Drupal uns jetzt "Your site has contacted the Apache Solr server."

Bevor die neue Suche funktioniert, muss der gesamte Content der Website einmal neu indiziert werden. Am einfachsten ist es, wenn man dies dem Cron-Job überlässt. Wer aber nicht so lange warten will, kann die Neuindizierung aber auch über "Konfiguration >> Suche und Metadaten >> Apache solr search >> Default Index" anstoßen. Dort klickt man einfach auf "Index queued content". Diese Seite bietet außerdem ausführliche Informationen über den Stand der Indizierung des Contents. Zusätzlich kann man dort einstellen, welche Inhaltstypen indiziert werden sollen. Noch ein Hinweis: Standardmäßig ist die Auto-Commit Funktion mit 2 Minuten Verzögerung eingeschaltet. Es dauert also etwas bis die Inhalte nach dem Cron-Lauf tatsächlich in Apache Solr verfügbar sind.

Als nächstes kann man mit den diversen Funktionen des Moduls experimentieren, z.B. mit der Facet Search oder Autokorrektur, die alternative Suchbegriffe vorschlägt (vergleichbar der "stattdessen suchen nach"-Funktion von Google). Oder man probiert die verschiedenen Zusatzmodule aus. Hier empfiehlt sich z.B. Apache Solr autocomplete, das während der Eingabe bereits Suchvorschläge generiert, ähnlich wie man es von Google kennt.

Viel Erfolg beim Ausprobieren!

Persönlich mag ich Webseiten, die aus Flashinhalten bestehen ja gar nicht. Alleine schon, weil es sich bei Flash um eine proprietäre Technik der Firma Adobe handelt. Ich gebe aber zu, dass es durchaus Fälle gab, wo der Einsatz von Flash Sinn machte - wenn es auch in den allermeisten Fällen eher überflüssig ist. Mit dem Aufkommen von HTML5 sollte es künftig noch weniger Gründe für den Einsatz dieser proprietären Technik geben. Vor allem, weil es mehr und mehr Geräte gibt, die damit nichts anfangen können - z.B. iOS- und Android-Devices (ab Android 4.1). Geht man mit diesen Geräten auf Flash-Webseiten sieht man oft nichts oder zumindest nicht viel. Da ist es nur folgerichtig, wenn Google künftig in seinen Suchergebnissen einen Hinweis bringt, dass die gefundene Webseite auf dem eingesetzten Gerät mit Flash läuft und möglicherweise nicht funktioniert. Ein Grund mehr, den Einsatz von Flash (aber auch anderen proprietären Techniken wie Silverlight) kritisch zu überdenken und sich Gedanken um Alternativen zu machen, die auf möglichst allen Geräten laufen.

Hier der vollständige Blogbeitrag (in Englisch) auf Googles Webmaster Central Blog.