AC 0.9.4 searchable nicht änderbar bei FEU Beschränkungen

Klenkes · 30. Januar 2013 16:43

Ich stelle gerade mit Erschrecken fest, dass ich bei Einsatz von AdvancedContent 0.9.4 auf Seiten, die FEU Beschränkungen haben, ich die Einstellung für Searchable und Cachable nicht ändern kann.

Bug oder Feature?
Wobei beides echt schlecht für mich wäre...

CMSMS 1.11.4
AC 0.9.4
FEU 1.21.2

NaN · 30. Januar 2013 16:47

Eigentlich feature.
Seiten, die nicht öffentlich sind, sollten nicht durchsuchbar und auch nicht zwischenspeicherbar sein. Ersteres, damit die Inhalte nicht über die Suche gefunden werden, wenn man nicht eingeloggt ist und Letzteres, damit das mit dem Login auch funktioniert.

Klenkes · 30. Januar 2013 17:01

Das habe ich befürchtet!
Ich filtere aber die geschützten Seiten im Resulttemplate aus, falls man nicht eingeloggt ist. Das funktioniert gut.

Es wird aber seltsamer...
Die Seiten sind trotzdem durchsuchbar!

Nach einem Reindex kann ich die öffentlichen Seiten sehen, und die Geschützten nicht.
Speichere ich eine geschützte Seite einmal neu ab, ist sie in den Suchergebnissen aber drin.
Das sollte dann so aber auch nicht sein.

NaN · 30. Januar 2013 18:15

Hm, verwendest Du die SVN oder die Beta Version?
Mir ist da gerade ein Fehler aufgefallen.
Die Funktion Cachable() gibt bei AC nichts zurück.
Hab ich gerade im SVN behoben.

Was das durchsuchbar angeht ... so wie ich das sehe ist das ein Fehler im Suchmodul bzw. im Inhaltsobjekt (also im Core). Denn laut Code müssten auch alle Seiten des normalen Inhaltstypen immer durchsuchbar sein, egal ob die Checkbox gesetzt ist oder nicht.

Im Suchmodul wird nämlich so geprüft:

Hier klicken, um den Code zum Kopieren zu markieren

$searchable = 1;
if( $content->HasProperty('searchable') )
{
	$searchable = $content->GetPropertyValue('searchable');
}

Das Problem ist zum Einen die Funktion HasProperty().
Diese wird nämlich immer false zurückgeben, da sie nicht die Attribute sondern die Eigenschaften eines Inhalts prüft. Das sind zwei verschiedene Sachen und diese werden auch mit verschiedenen Variablen gehandelt. Eigenschaften sind Inhaltsblöcke. Attribute sind die Dinger in den Optionen - wozu auch "searchable" gehört. D.h. $searchable wird immer 1 sein.

Zum anderen ist das Problem die Funktion GetPropertyValue().
Diese gibt Eigenschaften zurück, keine Attribute.
Auf diese Weise, wie es im Suchmodul geschieht, kann man nie wirklich ermitteln, ob eine Seite nun durchsuchbar ist oder nicht.

Man kann es ehrlich gesagt überhaupt nicht, weil die Variable, die die Attribute enthält, im Inhaltsobjekt private und die Methode mit der man die Existenz eines Attributs prüfen kann (is_known_property()) protected ist. Man kann "von außen" überhaupt nicht prüfen, ob eine Seite durchsuchbar ist, oder nicht. Searchable ist somit nutzlos.

Klenkes · 30. Januar 2013 22:35

NaN schrieb:

Hm, verwendest Du die SVN oder die Beta Version?
Mir ist da gerade ein Fehler aufgefallen.
Die Funktion Cachable() gibt bei AC nichts zurück.
Hab ich gerade im SVN behoben.

Das war die 0.9.4 BETA.
Dann mach' ich wohl besser mit der SVN weiter.

Vielen Dank für deine ausführliche Erklärung. Das Meiste ist wohl etwas oberhalb meines Verständnishorizontes, was zweifach schade ist, weil wenn es nicht so wäre, würde ich ein verdammtes(sorry) Suchmodul selbst bauen.

<lamentier>
Dieses SEARCH ist das vernachlässigste Modul im ganzen Paket, heutzutage aber doch das Wichtigste, wo jeder Besucher einer Website erwartet, schnell seine Infos zielsicher zu finden. Den Such- und Ergebnisstandard setzt wie immer Google. Doch die Qualität und Flexibilität, die uns SEARCH liefert ist eher suboptimal.
</lamentier>

In meinem Fall ist es schade, weil das Projekt nur 6 öffentliche Seiten hat, aber etwa 20 textlastige, interne Seiten für 25 Studenten. Suchfunktion benötigt! Mit etwas Smarty und der Toolbox lassen sich die Suchergebnisse in der Resulttemplate prima nach öffentlich und privat filtern.
Das heisst dann wohl, dass ich nach jedem Reindex alle Seiten neu speichern muss, damit sie in den Suchergebnissen auftauchen.

Ob nun SEARCH oder Core Bug... ich glaube nicht, dass es viel Sinn macht wenn ich einen Bugreport absetze. Die längste Halbwertszeit meiner Bugreports waren bisher 45 Minuten bis zur kommentarlosen Löschung.

Cherry · 31. Januar 2013 11:13

Klenkes schrieb:

Ob nun SEARCH oder Core Bug... ich glaube nicht, dass es viel Sinn macht wenn ich einen Bugreport absetze. Die längste Halbwertszeit meiner Bugreports waren bisher 45 Minuten bis zur kommentarlosen Löschung.

gut zu wissen, daß es nicht nur mir so geht.

Andynium · 01. Februar 2013 12:53

Klenkes schrieb:

<lamentier>
Dieses SEARCH ist das vernachlässigste Modul im ganzen Paket, heutzutage aber doch das Wichtigste, wo jeder Besucher einer Website erwartet, schnell seine Infos zielsicher zu finden. Den Such- und Ergebnisstandard setzt wie immer Google. Doch die Qualität und Flexibilität, die uns SEARCH liefert ist eher suboptimal.
</lamentier>

Um deinen Frust zu mindern, hat jemand ein Modul geschrieben, mit dem via Search auch PDF & Co durchsucht werden können wink

http://dev.cmsmadesimple.org/projects/documentsearch

Forum für CMS/made simple

#1 30. Januar 2013 16:43

AC 0.9.4 searchable nicht änderbar bei FEU Beschränkungen

#2 30. Januar 2013 16:47

Re: AC 0.9.4 searchable nicht änderbar bei FEU Beschränkungen

#3 30. Januar 2013 17:01

Re: AC 0.9.4 searchable nicht änderbar bei FEU Beschränkungen

#4 30. Januar 2013 18:15

Re: AC 0.9.4 searchable nicht änderbar bei FEU Beschränkungen

#5 30. Januar 2013 22:35

Re: AC 0.9.4 searchable nicht änderbar bei FEU Beschränkungen

#6 31. Januar 2013 11:13

Re: AC 0.9.4 searchable nicht änderbar bei FEU Beschränkungen

#7 01. Februar 2013 12:53

Re: AC 0.9.4 searchable nicht änderbar bei FEU Beschränkungen

Fußzeile des Forums