Im Abschnitt Anpassung von Core-Klassen des Atlassian Confluence Frameworks wurde bereits aufgezeigt, in wieweit Confluence 2.10 Klassen im nachhinein angepasst werden können. Dieser Abschnitt soll sich nun aufbauend darauf mit der Lucene-Suche beschäftigen.
Anmerkung:
Die nachfolgenden Erweiterungen/Anpassungen werden nicht – sofern nicht explizit darauf hingewiesen wurde – in den Plugin-Projekten vorgenommen. Es ist unbedingt erforderlich, dass ein Projekt erstellt werden muss, welches kompiliert als jar direkt im WEB-INF/lib Ordner abgelegt wird, so dass Confluence die Klassen beim Start unmittelbar zur Verfügung stehen.
Vorgehen:
1. Die Sprache muss in den Lucene-Index gespeichert werden.
Damit Lucene beim Indizieren auch das zusätzliche Attribut aufnehmen kann, muss eine neue Klasse angelegt werden, die von der Klasse Extractor erbt. Die Methode addFields() muss dabei so umgeschrieben werden, dass das neue Attribut ausgelesen und als Feld unter einem festgelegten Attributschlüssel indiziert werden kann. Damit Confluence diesen Extractor auch ausführt, muss die Datei core-extractors.xml* angepasst werden. Dafür ist es erforderlich die folgenden Zeilen einzufügen.
<extractor name="..." key="..." priority="..."> <description>...</description> </extractor>
2. Nach der Sprache muss gesucht werden können.
Damit nach einem festgelegten Attributschlüssel gesucht werden, muss die SearchQuery Klasse erweitert werden. Die getKey() Methode, die den festgelegten Attributschlüssel für die Suche zurückgibt und die getParameters() Methode, die die Suchemenge zurückliefert, müssen dabei überschrieben werden.
Des Weiteren ist eine Klasse notwendig, die vom LuceneQueryMapper erbt. Die convertToLuceneQuery() Methode ist dabei die einzige Methode, die überschrieben werden muss. Sie enthält die Suchlogik für ein bestimmtes Kriterium. Welche Möglichkeiten Lucene an dieser Stelle bietet, lesen Sie bitte in der einschlägigen Literatur oder im Internet unter Lucence nach. Damit Confluence diesen Mapper verwendet, muss die lucene-search-mappers.xml* mit dem folgenden Eintrag ergänzt werden.
<lucene-query-mapper name="..." key="..." class="..." handles="..."> <description>...</description> </lucene-query-mapper>
Die Confluence Action-Klassen, wie die SearchSiteAction, verwenden die SearchQueryParameters Klasse, um die Suchkriterien zu transportieren. Es empfiehlt sich diese Klasse um das zusätzliche Attribut zu ergänzen. Im Falle der Sprachattributerweiterung wären das eine Instanzvariabel und die zugehörigen Setter und Getter.
Auf die Anpassung innerhalb der Plugin Actions wird hier allerdings nicht näher eingegangen werden, da sie recht manigfaltig ausfallen kann, trotzdem nicht allzu kompliziert sind.
Die SearchQueryParameters werden der Methode siteExtendedSearch der Klasse DefaultPredefinedSearchBuilder übergeben. Damit diese Methode weiterhin verwendet werden kann, muss die DefaultPredefinedSearchBuilder Klasse entsprechend erweitert werden. Im Body dieser Methode werden die einzelnen SearchQuerys einem Set hinzugefügt. Notwendig wäre zum Beispiel für das Sprachattribut der folgende Eintrag.
if ((searchQueryParams.getLanguages() != null) && !searchQueryParams.getLanguages().isEmpty()) {
scopedQuery.add(new LanguagesQuery(searchQueryParams.getLanguages()));
}
Nach diesen Änderung hat man bereits den Titel dieses Beitrags überstanden.
* Wie die core-extractors.xml und lucene-search-mappers.xml entsprechend verändert werden müssen, damit Confluence diese auch berücksichtigt, entnehmen Sie bitte von diesem Beitrag Anpassung von Core-Klassen des Atlassian Confluence Frameworks. Zu beachten wäre, dass dafür auch die pluginServiceContext.xml verändert werden muss.
Sollte man einmal zufällig die Windows Search auf einem Windows Server 2003 x64 installiert haben, wird man von folgender Fehlermeldung beglückt.
Ereignistyp: Fehler
Ereignisquelle: Windows Search Service
Ereigniskategorie: Gatherer
Ereigniskennung: 3083
…
Beschreibung:
Fehler beim Laden des Protokollhandlers Search.Mapi2Handler.1. Fehlerbeschreibung: Klasse nicht registriert
Um diesen Fehler aus der Ereignisanzeige zu verbannen sind folgende Schritte notwendig.




Im Mitteldeutschen Barcamp in Jena fand eine Session zum Thema SEO (Search Engine Optimization) statt. In dieser wurden Prinzipien diskutiert um ein gutes Ranking für eine Webseite insbesondere unter google zu erzielen. Ein paar Ideen möchte ich an dieser Stelle zusammenfassen.
1. Jede Seite, die durch eine Suche auffindbar sein soll, sollte nur einmal vorhanden sein. Wenn mehrere Einstieg URLs vorhanden sind, so sollten diese, am besten per Refer, auf die Hauptseite verweisen.
2. Jede Seite sollte unter einem permanenten Link erreichbar sein. Der Link sollte sich für die Webseite auch in Zukunft nicht mehr ändern sowie unabhängig seinvon irgendwelchen Sessionvariablen oder vorhergehenden Klickpfaden.
3. HTML Konformität ist für google nicht zwingend erforderlich. Jedoch hat die Beachtungein dieser den Vorteil, dass google die Seite vollständig parsen kann. Treten Fehler beim Parsen der Seite auf, so kann das dazu führen, dass nicht alle Links betrachtet werden, oder die Seite nicht in einem Suchergebnis erscheint, da der Content nicht analysiert wurden konnte.
4. Die Reihenfolge von Content innerhalb einer HTML Seite spielt eine untergeordnete Rolle. Scheitert das Parsen der HTML Seite in der Mitte oder Ende so können nur die Links und Texte, die bis dahin gescannt wurden, verarbeitet werden. Beinhaltet der Anfang eine für die Suche unwichtige Subnavigation, so ist dies eine unnötige Fehlerquelle. Es kann daher sinnvoller sein, den Content immer an den Anfang an einer Seite zu platzieren und stattdessen Navigation o. ä. ans Ende.
4. Das meta Tag description kann verwendet werden, um das Preview in dem Suchergebnis zu definieren. Beim nicht Verwenden des Tags versucht die Searchengine sich eine Description herauszusuchen. Die Vorhersagbarkeit des Ergebnisses stößt dabei gern an ihre Grenzen.
5. Für unwichtige Webseiten, die nicht in einem Suchergebnis erscheinen sollen, kann einem Link ein no-follow mitgegeben werden. Siehe dazu auch hier http://googleblog.blogspot.com/2005/01/preventing-comment-spam.html
6. Google abonniert RSS Feeds. D. h. erscheint eine neue Seite in einem RSS Feed, so scannt Google diese Seite nach neuen Suchbegriffen schneller als wenn es beim Scannen des Webs über diese neue Seite stolpern würde.
7. Während der Session tauchte die Frage auf, welche Bedeutung Headline Tags (h1, h2 usw.) haben, und welche Relevanz diese für die Suche haben. Die überraschende Antwort war, dass h2 oder h3 unter Umständen mehr Bedeutung haben als h1. Dies ist sicherlich abhängig von dem Aufbau der Gesamtseite. Der Hintergrund – sinnfrei wiedergeben – ist, dass h1 mitunter als Gesamtüberschrift angesehen wird, die für den konkreten Content der Seite nur eine untergeordnete Bedeutung hat.
8. Wo platziert man einen Link auf seine Seite, um in einem Suchranking von google weiter oben zu erscheinen? Die Antwort ist an sich ganz banal, man sucht sich die Seite(n) heraus, die für die Zielsuchbegriffe am höchsten gerankt sind, und platziert dort, irgendwie, einen Link. Das “irgendwie” ist dabei der Kreativität des Einzelnen überlassen.
Alle Angaben sind ohne Gewähr.
Releaseparty at Atlassian? Confluence 3.2 BETA and 3.1.2 with soms bugfixes were released yesterday. [...]
Tino Schmidt's Vortrag zu Enterprise Mashups auf der webciety, 4.3 Remix the Web http://bit.ly/d26rtA [...]
neuer Blogpost: February Cumulative Update (2010) http://bit.ly/cwxZGE [...]
Webinar am 16.03.: „Communote Enterprise Microblogging - Funktionen und Einsatzbereiche im Unternehmen“ http://bit.ly/96eexF [...]