[gelöst] Inhalt von Blöcken in die Suche indizieren

Da Blöcke meist auf unterschiedlichen Seiten angezeigt werden sollen und oft auch dynamische Inhalte enthalten, wäre zunächst das Problem, wo soll eine erfolgreiche Suche denn den Finder hinführen? Das müsste man dem Such-Index irgendwie mitteilen, wenn man Blöcke indizieren möchte. Die Indizierung lässt sich dann relativ leicht programmieren. Ob es aber insbesondere aufgrund der Ziel-Problematik schon ein fertiges Modul gibt ist fraglich.
Anders herum ist es auf jeden Fall ein einfacherer Weg. Man nimmt einen "normalen" Inhalt (der indiziert wird und einen eigenen Anzeige-"Ort" hat) und lässt diesen in Blöcken anzeigen. Da gibt es auf jeden Fall Module für.

Hast Du dann noch auf Drupal 6 zurück gegriffen oder Dein Beitrag versehentlich mit Drupal 6 getaggt?

Wenn Inhalte von Blöcken indiziert werden sollen ist es am Einfachsten, Nodes in Blöcke zu packen.

Dafür gibt es diverse Möglichkeiten:
* [do:views Views]
* [do:nodeblock Node Blocks]
* [do:nodeinblock Node in Block]
* [do:nodeasblock Node As Block]

@Carsten Logemann

Ich hab schon vor über einem Jahr (vor Erscheinen der 7er Version) DP6 installiert, Allerdings auf Strato.
(Die Entscheidung kam noch zur HTML-Zeit) Allerdings hab ich die Verantwortlichen von der Kirche mehrfach um Providerwechsel
gebeten, aber die Angst vor einem Ausfall war zu groß, da konnte ich noch so sehr argumentieren :-(

Jetzt hat auch endlich mal Strato erkannt, dass die Leute nicht nur mit Hammer und Meißel - also mit HTML-Seiten
arbeiten wollen, sondern mit Content-Management-Systemen.
Meine Anfrage vor 1,5 Jahren betreff Drupal bei Strato wurde noch belächelt, so etwas hatte man damals noch nicht nötig
zu unterstützen. Mittlerweile sieht das (dank Kd.-Rückgang) wohl anders aus.
Die altbackene Geschäftsleitung von Strato hat im April mehr PHP-Cache spendiert, und somit habe ich meine
bereits angefangene 6er Version (die mangels Speicher ohne Grafiken auskommen musste) nun weiter ausgebaut,
mit Fotos etc., so dass ich nun endlich den alten HTML-Teil still legen konnte :-)

Tja, lange Geschichte, ich weiß. Ich bleibe aber nun solange bei der 6er Version (never change a running system) bis es
von einer Nachfolgeversion die Möglichkeit geben wird, die Inhalte alter Versionen 1:1 zu importerien, aber das wird wohl
vermutlich erst in mehreren Jahren passieren.

@stBorchert: Vielen Dank, dass werd ich mal probieren :-)

Ich weiß der Tipp erfordert tiefere Einarbeitung, aber mit Drush ist es relativ leicht von Drupal 6 auf Drupal 7 upzugraden selbstverständlich mit allen Inhalten. Das ist um so leichter je weniger Komplexität man in das System einbringt. Das heißt, ich würde das anstreben bevor Du da jetzt weiter ausbaust. Ich habe das gerade letzte Woche für ein Projekt aus genau diesem Grund mal wieder erfolgreich durchgezogen.

Ich hab für meine Freundin eine kleine Homepage mit DP7 erstellt und kenne die Vorzüge. (zumindest ein paar, ich mach das ganze nur nebenbei)
In Puncto Design wäre das evtl. noch mehr Spielraum, wobei das jetzige Design ausreichend ist.
Andererseits gibt es noch immer nicht alle 6er Module auf für DP7
(z.B. http://drupal.org/project/commentmail)
Im Augenblick sehe ich da eher den Faktor Arbeit (der auch so schon immens ist)
und da ich das Ganze ehrenamtlich in der Freizeit mache, denke ich dieses Jahr nicht mehr darüber nach.

Aber wer weiß, never say never ;-)

Sehr viele D6-Module braucht D7 nicht mehr, weil es anders gelöst ist, oder weil die Funktionalität bereits im Core integriert ist.

Deshalb wird es viele Module niemals in D7 geben (müssen).

Der Faktor Zeit ist natürlich zu beachten.

Eine Überholung der Website ist natürlich eine willkommenen Möglichkeit, auch die Technik auf den neuesten Stand zu bringen.

Allerdings ist es immer sinnvoll, wenn man ein Stück weit parallel fahren kann, um eventuelle Nebenwirkungen ohne Öffentlichkeit beobachten zu können.

Wenn du Zeit und Lust hast, schu dir mal Migrate an. Das kann dir viel Arbeit abnehmen.

Ein einfaches Modul wie Commentmail ist nicht wirklich komplex. Daß das noch nicht auf Drupal 7 portiert wurde zeigt eher, daß sich die Maintainer nicht mehr interessieren. Da aber insbesondere solche Wenn/Dann-Funktionen sehr leicht mit Rules realisiert werden können auch schon unter Drupal 6, halte ich diese Module komplett für überflüssig und würde auch keine Minute programmier-Leistung daran verschwenden. Da gibt dann aber auch ganz andere Module, die etwas komplizierter sind und für die man dann eine Art Migrationspfad zu einem neuen Drupal 7 Modul benötigen würde. Dieser ist aber oft auch schon vorhanden oder letztlich auch mit dem Migrate-Modul zu realisieren.
Auf jeden Fall würde ich bei jeder Entscheidung für eine neue Funktion in einem Drupal 6 System bei einem Modul berücksichtigen, wie denn die Drupal 7 Welt dort ausschaut. DAs mache seit dem Stabel Release von Drupal 7 immer. Es ist ja nicht so, daß ich schon alle Drupal 6 Websites auf 7 portiert habe, mit denen ich zu tun habe.

Ohne, dass ich im Forum gesucht habe, kann ich denn mit einer Datenbank paralel auch DP7 zur laufenden DP6 installieren?
Da ist doch die Gefahr des Datenbank-Chrash vorprogrammiert?

Ich hatte zu meiner HTML-Zeit ein Unterverzeichniss /drupal im Root angelegt, wo jetzt die ganze Seite liegt. Diese wird via Javascript weitergeleitet, so dass die Webseite immer "www.kirche-in-dornberg.de/drupal/...." anfängt.

Wenn ich direkt bei Strato jedoch das Startverzeichnis ändere, werden meine Bilder (alle via Img-Tag in Drupal integriert, um die Datenbank zu entlasten)
nicht mehr angezeigt, und dass wo ich bei allen Bildern absolute Pfade (und nicht relative Pfade wie ../ ) genommen habe.
Jedes Bild hat also den Pfad beginnend mit "http://www.kirche-in-dornberg.de/drupalbilder/..."

Es wäre für mich eine absolute Katastrophe, wenn meine ganze Datenbank crashen würde und ich ggf. komplett von vorne anfangen müsste, dass darf in keinem Fall passieren. (Ich glaub, dann würd ich das Ehrenamt schmeißen, so frustriert wäre ich!)

Aber ein zweite Datenbank wäre schon sinnvoll und eventuell ein subdomain.

Für den Anfang ist aber eine lokale Installation sinnvoll, die eh für Versuche vorhanden sein sollte.