Suchindex erstellen bei Multidomain-Installation

[Ignatz]

Hallo,

ich habe ein Contao-Installation (3.5.6) mit drei Domains. Die Haupt-Domain ist mit einem Zertifikat gesichert (https). Wenn ich in der Systemwartung den Suchindex lösche und anschließend neu aufbaue, stoppt der Crawler, sobald er an der ersten URL der zweiten Domain ankommt. D. h. eigentlich stoppt er nicht, das Kreisel dreht weiter, aber er tut nix mehr.

Unter den URLs der beiden anderen Domains kommen noch weitere, die zur Haupt-Domain gehören. Auch diese werden nicht mehr gecrawlt. Mir bleibt nur, den Vorgang abzubrechen.

Für die Haupt-Domain habe ich den Haken bei „HTTPS in Sitemaps“ gesetzt, bei den anderen natürlich nicht.

Wo klemmt es hier? Ist das ein Bug?

Grüße,
Ignatz

[The_Unknown]

Das gleiche Problem habe ich auch. Es gibt dabei folgendes Problem:

XMLHttpRequest cannot load https://www.xyz.org/login/lost-password. Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'https://www.xyz.de' is therefore not allowed access.

Ich habe einige Header versucht. Unter anderem header("X-Frame-Options: SAMEORIGIN"); und header('Access-Control-Allow-Origin: *'); in der initconfig.php. Hat alles nix gebracht

[SpeGal]

Gibt es hierfür noch keine Lösung? Ich habe dasselbe Problem!

[Ignatz]

Hallo SpeGal,

es scheint bisher keine Lösung zu geben. Auch nachdem beim Update auf 3.5.10 „diverse Probleme“ an der Suchindizierung behoben wurden, bleibt das Problem bestehen. Es betrifft wohl zu wenige.

Gruß,
Ignatz

[SpeGal]

Ich habe bereits die 3.5.12 und es geht nicht

Allerdings habe ich auch versucht das in der Online-Demo nachzustellen, ohne Erfolg. Dort indiziert er immer alles, egal ob mit oder ohne https und egal wie die Domain heißt ...
Aber dort sind auch längst nicht so viele und volle Seiten wie bei uns drin.

Hoffentlich gibts da bald ein Update. Gibt es dafür schon ein Ticket in Github?

[Ignatz]

Ich habe kein Ticket aufgemacht. Bin mir auch nicht sicher, ob er nicht unter der Haube doch alle Seiten indiziert. Denn der Suchindex wächst von anfänglich über 5.000 Einträgen nach einiger Zeit (Stunden? Tagen?) auf über 16.000 Einträge an.

[SpeGal]

Er indiziert die Seiten leider nicht automatisch weiter. Das habe ich überprüft. Allerdings ist es in Contao ja generell so, dass bei Seitenbenutzung der Suchindex erweitert wird. Also erst wenn jemand nochmal die Seiten im Frontend aufruft, die nicht gecrawled worden sind, werden diese dann nach und nach in den Index aufgenommen. Aber eben nur, falls da auch jemand drauf geht ...

Ich habe jetzt mal vorübergehend alle Seiten der anderen Domains als "nicht in Suchindex aufnehmen" markiert. Nun indiziert er die komplette erste Domain.
Da ich das nicht in der Demo nachstellen kann, weiß ich auch nicht, was ich in einem Github-Ticket schreiben könnte. Ich weiß ja nicht, ob es nun an https, Multidomain, Seitenanzahl oder sonst was liegt.

[Spooky]

Siehe http://stackoverflow.com/a/18607750/374996

Die Lösung ist also:

1. In der .htaccess folgendes eintragen:

   <IfModule mod_headers.c>
       Header set Access-Control-Allow-Origin: *
   </IfModule>

   (statt * kann man auch die Domain inkl. http angeben, von der man den Suchindex neu aufbaut)
2. Ein eigenes be_rebuild_index Template erzeugen und ändern, sodass "X-Requested-With" aus dem Header des Requests gelöscht wird. zB:

   <script>
     window.addEvent('domready', function() {
       var urls = $$('.page_url'),
           complete = 0;
       urls.each(function(el) {
         if (el.getAttribute('data-url')) {
           var request = new Request({
             'url': el.getAttribute('data-url'),
             onSuccess: function() {
               el.addClass('tl_green');
             },
             onFailure: function(xhr) {
               el.addClass('tl_red');
               el.set('text', el.get('text') + ' - ' + xhr.status );
             },
             onComplete: function() {
               complete++;
               if (complete == urls.length) {
                 $('index_loading').setStyle('display', 'none');
                 $('index_complete').setStyle('display', 'block');
               }
             }
           });
           delete request.headers['X-Requested-With'];
           request.send();
         }
       });
     });
   </script> 

   Der Code basiert auf https://gist.github.com/fritzmg/81acff5ed269f3281ee1

[SpeGal]

Hmm, das ist mir zu kompliziert

Warum wird das nicht einfach in ein Bugfix rein gemacht? Das ist doch eigentlich nicht "mein Problem" sondern sollte im Core gelöst werden, oder?

[Spooky]

Hmm, das ist mir zu kompliziert

Was genau? .htaccess und Template Änderungen gehören doch zur täglichen Arbeit mit Contao (oder im Website Development generell).

Warum wird das nicht einfach in ein Bugfix rein gemacht? Das ist doch eigentlich nicht "mein Problem" sondern sollte im Core gelöst werden, oder?

Nicht unbedingt. So etwas wie

<IfModule mod_headers.c>
    Header set Access-Control-Allow-Origin: *
</IfModule>

muss man auf eigene Gefahr machen, denn damit erlaubst du AJAX requests von egal welcher Domain. Aber du kannst ja gern dafür ein Ticket auf GitHub erzeugen: https://github.com/contao/core/issues

[lucina]

Hmm, das ist mir zu kompliziert

Warum wird das nicht einfach in ein Bugfix rein gemacht? Das ist doch eigentlich nicht "mein Problem" sondern sollte im Core gelöst werden, oder?

Ich finde nicht dass es im Core 'gefixt' gehört. Auch die bei Installation mitgelieferte .htaccess.default ist nicht mehr als eine Empfehlung für häufige Szenarien, was alleine schon an den vielen Kommentaren ersichtlich sein sollte (und an den enthaltenen Varianten).

Obendrein finde ich das Szenario, eine Seite verschlüsselt, eine andere unverschlüsselt auszuliefern eher unüblich.

TIPP: einfach einen Bot über die Seiten laufen lassen, dann wird der Index in jedem Fall aufgebaut.

[Spooky]

Ich finde nicht dass es im Core 'gefixt' gehört. Auch die bei Installation mitgelieferte .htaccess.default ist nicht mehr als eine Empfehlung für häufige Szenarien, was alleine schon an den vielen Kommentaren ersichtlich sein sollte (und an den enthaltenen Varianten).

Es erfordert aber auch eine Änderung im Code von Contao, nicht nur eine Änderung der Serverkonfiguration.

Obendrein finde ich das Szenario, eine Seite verschlüsselt, eine andere unverschlüsselt auszuliefern eher unüblich.

Mit der SSL Verschlüsselung hat das Problem nichts zu tun. Der Indexer in der Systemwartung ist einfach nicht für Multidomain Installationen ausgelegt.

TIPP: einfach einen Bot über die Seiten laufen lassen, dann wird der Index in jedem Fall aufgebaut.

Dann sind aber geschützte Seiten eine weitere Hürde (aber natürlich nicht unmöglich), wenn man die Indexieren möchte.

[Ignatz]

Ich habe jetzt Spookys Lösung versucht. Das ändert aber leider garnichts. Will heißen, es wird nur die https-Domain indiziert, die beiden anderen nicht.

Wenn ich es nicht umbenenne wird doch das geänderte Template automatisch verwendet, oder muss ich das irgendwo explizit angeben?

[Spooky]

Ich habe jetzt Spookys Lösung versucht. Das ändert aber leider garnichts. Will heißen, es wird nur die https-Domain indiziert, die beiden anderen nicht.

Dann liegt es bei dir an etwas anderem. Da du "es wird nur die https-Domain indiziert" erwähnst - kann es sein, dass du dich per HTTPS in das Backend einloggst und nicht alle deine Website Roots SSL verwenden? Siehe dazu https://community.contao.org/de/show...-Contao-3-5-12
Du musst im Website Root einstellen, dass SSL verwendet werden soll, andernfalls kannst du den Suchindex nicht aufbauen lassen, wenn du dich in das Backend per SSL eingelogged hast.

[Ignatz]

Ja, im Grunde ist es so. Ich logge mich per HTTPS ein, die „Hauptdomain“ ist durch HTTPS geschützt und das ist im Website-Root auch angehakt. Die beiden anderen Domains sind nicht durch HTTPS geschützt.

Wenn ich mich im Backend über eine der anderen Domains einlogge, werden auch wieder nur deren Seiten indiziert.

[Spooky]

Ja, im Grunde ist es so. Ich logge mich per HTTPS ein, die „Hauptdomain“ ist durch HTTPS geschützt und das ist im Website-Root auch angehakt. Die beiden anderen Domains sind nicht durch HTTPS geschützt

Wie gesagt, du kannst keine Requests auf http:// machen lassen, wenn du dich per https:// im Backend eingelogged hast - dein Browser lässt das nicht zu. Du musst entweder in jedem Website Root, den du indizieren möchtest, einstellen, dass SSL benutzt werden soll, oder dich per http:// im Backend einloggen.

Und unabhängig davon brauchst du zum indizieren von mehreren Domains oben erwähnte Anpassungen.

[Spooky]

Ich muss hier eine Korrektur meines Posts machen. Eigentlich braucht man nur entweder 1.) oder 2.), nicht beides.

Das Problem ist, dass das Setzen des Headers 1.) über die .htaccess nur dann funktioniert, wenn PHP nicht über (Fast)CGI ausgeführt wird. Andernfalls hat das keine Auswirkung und man müsste es stattdessen direkt in der vhost Konfiguration machen. Siehe dazu zB http://serverfault.com/a/383063/143519

Hat man keinen Zugriff zur vhost Konfiguration, dann bleiben einem nur zwei Optionen:

• Entweder man ändert das be_rebuild_index Template entsprechend dem Punkt 2.)
• Oder man sendet diesen Header bei einem Contao Seitenaufruf selbst über PHP. Dazu müsste man sich eine Extension programmieren, die den Header bspw. im modifyFrontendPage Hook setzt.

[Spooky]

Hier im Anhang eine Mini Extension, die den folgenden Header für alle Contao Seiten setzt:

Access-Control-Allow-Origin: *

Man sollte diesen Wert aber auf die Domain ändern, über die man sich üblicherweise in das Contao Backend einloggt.

// siehe folgenden Post

[Spooky]

Der Access-Control-Allow-Origin Header alleine reicht nicht, man muss auch

Access-Control-Allow-Headers: X-Requested-With

setzen lassen. Hat man nicht die Möglichkeit dies über die .htaccess oder der vhost Konfiguration zu machen, kann man stattdessen diese Extension verwenden: fritzmg/contao-multidomain-rebuild-index

[lucina]

.htaccess

<IfModule mod_headers.c>
  Header add Access-Control-Allow-Origin "*"
  Header add Access-Control-Allow-Headers "origin, x-requested-with, content-type"
  Header add Access-Control-Allow-Methods "PUT, GET, POST, DELETE, OPTIONS"
</IfModule>

[Spooky]

Wie gesagt, wenn PHP Über FastCGI ausgeführt wird, kannst du über eine .htaccess nicht mehr die Header des von PHP generierten Responses ändern. Zumindest in den meisten Fällen.

[Spooky]

In zukünftigen Contao Versionen (3.5.x+) wird übrigens keine Anpassung mehr notwendig sein: https://github.com/contao/core/pull/8597

[PaddySD]

Mag ja sein, aber wer macht denn heutzutage noch eine Seite ohne https? Dank Let's encrypt sollte das ja nun wirklich zu jeder Page dazu gehören, und Aufwand isses auch keiner. Dann hat man das hier dargestellte Problem überhaupt nicht..

Ich mache das mittlerweilen automatisch bei jeder Installation / Update für Kunden dazu.

[Spooky]

Mag ja sein, aber wer macht denn heutzutage noch eine Seite ohne https?

Hier geht es nicht nur um HTTPS sondern auch um Multidomain Installationen. Da geht das auch nicht so ohne weiteres (siehe diesen Thread).