SEO URLs lassen sich nicht erstellen

sonic · 3. Mai 2018 um 16:44

Ggf. könnte man auch - beim Hoster - anfragen, ob es einen Datenbank-Log gibt.
Möglich, dass es beim - ? wieviele sind es denn ? - Count über die Artikel zu einen “Fehler” / “Timeout” in der Datenbank kommt.
Das wäre dann nämlich u.U. kein PHP-Fehler, und der Controller gibt “verwirrt” etwas falsches zurück. Müsste man sich mal das Model dazu angucken.
Die Lust zu Letzterem ist mir aber für heute abhanden gekommen

Gruß - SONIC

enerSpace · 3. Mai 2018 um 16:54

Hallo @sonic‍,

in einem Forum versuchen Menschen anderen Menschen zu helfen. Nicht jede Antwort passt da und auch nicht jeder Lösungsansatz hilft da weiter. Uns aber dabei zu diskeditieren und anzugreifen obwohl wir versuchen zu helfen, hilft dem TE ganz sicher nicht weiter.

Antworten müssen auch nicht sofort zu einer Lösung führen und müssen auch nicht immer korrekt sein. Eine konstruktive geführte Diskussion, wenn Sie denn stattfindet, reicht meistens auch aus um dem TE weiter zu helfen! Dabei zählt nicht als erster die Lösung zu präsentieren sondern dabei mitgewirkt zu haben!

Du kannst aber gern wieder zurück kommen, wenn du tatsächlich interesse hast, dem TE weiter zu helfen.

VG

enerSpace Webhosting
Tel.: +49 511 - 219 568 76 | Web: https://www.enerspace.de

SLS · 3. Mai 2018 um 16:57

Moin,

die Chrome Konsole spuckt folgenden Fehler aus:

In der Error_log sind keine Einträge vorhanden.

Danke

sonic · 3. Mai 2018 um 17:31

*Tschuldigung* - manchmal findet die Suche nach der Ursache eines Problem nicht werbewirksam im Vordergrund statt, sondern bei der Suche im Code im Hintergrund.
Hab auch noch keine “Lösung” - aber der Aufruf geht nach (Zeile 72):
shopware/Seo.php at 5.4 · shopware/shopware · GitHub
Ist die Datei Seo.php im Verzeichnis “/engine/Shopware/Plugins/Default/Core/RebuildIndex/Controllers/” vorhanden?

Da hätten wir wieder ein Limit
Noch einmal die Frage: Wieviele Artikel sind im Shop?

SLS · 3. Mai 2018 um 17:40

Die Datei ist vorhanden und der Abschnitt sieht genau so aus.

Es sind 1565 Artikel im Shop. Viele mit Varianten. Inkl Varianten 21309.

Danke

sonic · 3. Mai 2018 um 18:32

Ich sag es mal so: Es könnte tatsächlich sein, dass enerSpace nicht Unrecht hat mit „zu schwach“.
Ich hadere noch mit dieser Aussage, weil ich nicht verstehe, warum ein Timeout (ggf. Datenbank!) letztlich zu einer 404 Meldung führt.
Die Artikel sind es nicht, aber die Varianten, und die sind letztlich auch nur Artikel in der Datenbank.

Hier wird gezählt
shopware/SeoIndex.php at 5.4 · shopware/shopware · GitHub
Die Joins über 21309 Artikel sind schon eine Nummer - Shopware aast schon mal gerne mit Resourcen.

Wenn möglich, optimiere mal - ! nach einem Backup ! - die Tabelle s_articles mit dem Datenbank-Tool Deiner Wahl. Wobei Web-basierte Tools dann auch wieder ein Laufzeitproblem bekommen könnten. Wenn die Datenbank für einen externen Zugriff temporär freigegeben werden kann, wäre unter Windows HeidiSQL meine Empfehlung

Was mich wirklich noch stört, ist der der 404…
Kommt der 404 sofort/zeitnah, wenn Du den Shop auswählst, oder erst nach 30 Sekunden? Letzteres würde für Timeout / „zu schwach“ sprechen, ersteres für ein anderes Problem.

Bei manchen Hostern kann man die Scriptlaufzeit in gewissen Grenzen in der .htaccess hochsetzen.

Moritz_Naczenski · 3. Mai 2018 um 18:37

Vielleicht mal noch in den Grundeinstellungen > Shopeinstellungen > Shops prüfen, ob der Hauptshop ggf. inaktiv ist.

SLS · 3. Mai 2018 um 18:54

Die Datenbank habe ich komplett optimiert.

Die SeoIndex.php sieht genau so aus.

Der Engine Ordner wurde auch schonmal komplett ersetzt durch ein neues download.

Der Shop ist aktiv.

Hat alles nichts geholfen.

enerSpace · 3. Mai 2018 um 19:42

Hallo @SLS‍,

danke nochmal für die Infos per PM. Mir fallen noch die folgenden Möglichkeiten ein, die wir ausprobieren könnten. Kurz vorweg, ich habe in einer Testumgebung ein wenig rum experimentiert und konnte höchstens einen 500er Fehler provozieren, der wiederrum gut protokolliert wurde. Alles kein Problem mit 35k Testartikeln unter Einhaltung der Mindestanforderungen:

Eventuell liegt es an einem Plugin? Hast du einmal alle Plugins deaktiviert?
Welche Shopware Version wird aktuell eingesetzt?
Hast du eine aktive Service Subscription von Shopware? Falls Ja, könnte Shopware dir weiter helfen.
Eventuell eine fehlerhafte Datenbank
Abwegig aber auch möglich, dass der Apache2 Server fehlerhaft eingestellt ist. An die Logdateien kommt man aber regulär nicht ran.

Würde es dir weiter helfen, wenn ich dir eine kostenlose Testumgebung zur Verfügung stelle? Dort könntest du wenigstens ausschließen dass es am Hosting liegt.

VG

enerSpace Webhosting
Tel.: +49 511 - 219 568 76 | Web: https://www.enerspace.de

sonic · 3. Mai 2018 um 21:48

Etwas zum drüber schlafen:
Was haben wir:
1) Tests mit 35k Testartikel ergeben Laufzeiten, die weit weg von 30 Sekunden sind
2) der Aufruf von backend/Seo/getCount liefert einen 404

Wie kann es zum 404 kommen?

Der Apache findet etwas nicht - also eine Datei. Das ist aber nicht der Fall, da mit ‘backend’ durch Rewrite schon der Kernel von Shopware gestartet wurde!
2) Tritt ein Script / PHP-Fehler im Kernel / Symfony auf, wird der Apache keinen 404 werfen, eher was um 500 und einen Error-Log schreiben.
der Kernel sucht den Controller “Seo”. Er findet den Controller nicht => 404
der Kernel findet den Controller, aber nicht die Action “getCount” => 404
Da der Call einen [Shopware-Kernel] 404 ausgibt, dürfte eher weniger ein echter PHP-Fehler vorliegen, somit ist auch eher weniger ein Error-Log zu erwarten.
Eigentlich kommen nur 3) oder 4) in Frage - beide geben im IDEALFALL eine Exception im Shopware-Log aus
/Seo/ ist ein Core-Plugin nach alter Plugin-Struktur.
Gehe ich den Programablauf durch, kann es fast nur am Seo-Plugin von Shopware liegen. Die Dateien scheinen OK zu sein - somal ja auch “engine” ‘erneut hochgeladen’ wurde.
Bleiben nur noch Probleme in der Datenbank (Shop / Plugin-Config)
a) ein Plugin, welches den Seo-Controller aushebelt (naja…)
b) das Plugin ist im Sytem deaktiviert (falscher, fehlerhafter Datenbankeintrag)
c) die Config zum Plugin ist fehlerhaft
d) die Registrierung (Controller) vom Plugin fehlt, ist defekt, etc…

Vielleicht ist die Richtung richtig - wie man a) bis d) ermittelt, müsste wohl einer von SW erklären können.

So - Schluß für heute - N8

Moritz_Naczenski · 4. Mai 2018 um 06:10

github.com

shopware/shopware/blob/5.4/engine/Shopware/Plugins/Default/Frontend/Seo/Bootstrap.php#L53


        'Enlight_Controller_Action_PostDispatch',
        'onPostDispatch'
    );

    return true;
}

/**
 * Returns capabilities so the plugin is default not installable and hidden in the plugin manager
 */
public function getCapabilities()
{
    return [
        'install' => false,
        'enable' => false,
        'update' => true,
    ];
}

/**
 * Optimize Sourcecode / Apply SEO rules

Dort einfach install und enable auf “true” setzen und mal schauen im Plugin-Manager ob das Plugin installiert und aktiv ist.

SLS · 7. Mai 2018 um 06:03

Hallo,

Ich habe deinen Schritt mal ausgeführt. Das Seo Plugin ist Installiert und Aktiv.

Ich habe in die Datenbank in die Tabelle „s_core_rewrite_urls“ gesehen. Dort sind 9751 Datensätze. Ist das nicht ein bisschen viel für 1564 Artikel?

Vielen Dank.

enerSpace · 7. Mai 2018 um 23:22

Hallo @SLS‍,

theoretisch nein. In der Tabelle werden alle URLs abgespeichert, auch deren Beziehungen zu einander. Je nachdem wie oft du z.B. etwas umbenannt hast, je größer wird die Tabelle.

Bist du dir allerdings 100% Sicher, das ältere Beziehungen nicht mehr gebraucht werden, zum Beispiel eine Weiterleitung von “Datenschutz” auf “Datenschutzerklärung” (Umbenannt), kannst du diese Tabelle aber auch leeren.

Hat denn der Hinweis von [@Moritz Naczenski](http://forum.shopware.com/profile/14574/Moritz Naczenski “Moritz Naczenski”)‍ weiter geholfen? Falls nicht, hast du die anderen Möglichkeiten in betracht gezogen oder versucht?

VG

enerSpace Webhosting
Tel.: +49 511 - 219 568 76 | Web: https://www.enerspace.de

kulli · 8. Mai 2018 um 04:13

@enerSpace schrieb:

Hallo @SLS‍,

theoretisch nein. In der Tabelle werden alle URLs abgespeichert, auch deren Beziehungen zu einander. Je nachdem wie oft du z.B. etwas umbenannt hast, je größer wird die Tabelle.

Bist du dir allerdings 100% Sicher, das ältere Beziehungen nicht mehr gebraucht werden, zum Beispiel eine Weiterleitung von „Datenschutz“ auf „Datenschutzerklärung“ (Umbenannt), kannst du diese Tabelle aber auch leeren.

Das sollte man niemals in einer Live-umgebung machen; lieber vorher Testsystem aufsetzen. Oder mindestens mal auf die Erstellung Datensicherung hinweisen. Vor allem nicht die ganze Tabelle leeren. Sondern Schritt für Schritt durchgehen. Zielführend ist das allerdings nicht.

Nach dem Lesen der Beiträge komme ich da wieder auf meinen ursprünglichen Post zurück " Sieht schwer nach überfordertem Server-platz aus ".

Das ganze errinnert mich auch stark an einen schlecht konfigurierten Server was die Cache angeht: Ist Opcache installiert ?

Vitago_GmbH · 8. Mai 2018 um 09:52

Ich würde das ganze mal auf einen stärkeren Server testen, die paar Euro mehr wirst du dir doch hoffentlich leisten können.

enerSpace · 8. Mai 2018 um 13:05

Hallo @kulli‍,

ich denke, dass wir in diesem Thread bereits lange den Punkt überschritten haben, dem TE den Hinweis zu liefern, dass er Backups machen soll und die Änderungen in einem Testsystem durchführen sollte. Grundsätzlich muss man auch nicht darauf hinweisen, da jeder selbst dafür verantwortlich ist. Hier geht es ja mittlerweile konkret ums Debuggen, um den Fehler zu finden. Grundsätzlich habe ich aber dem TE nur erklärt wieso so viele Einträge in dieser Tabelle vorkommen können und das er sich 100%** **sicher sein muss, bevor er dort etwas löscht.

Ob dieser Schritt zielführend ist, bezweifle ich ebenso. Aber testen kann man ja alles, was dabei helfen könnte, den Fehler zu finden. Das leeren der Tabelle könnte auch deine Theorie bestätigen, denn wo was gelöscht wird, entsteht neuer Platz

Was hat der Cache mit einem 404 error zu tun? Im Übrigen, wurde hier bereits jegliche Konfiguration getestet, um den gleichen Fehler zu provozieren, nur ohne Erfolg! Auch ohne Opcache.

VG

enerSpace Webhosting
Tel.: +49 511 - 219 568 76 | Web: https://www.enerspace.de

SLS · 8. Mai 2018 um 19:13

Hallo,

Ich habe gerade ein Testsystem mit Demo Daten Installiert --> Es lief

Ich habe dann meine Datenbank Strucktur und Daten importiert --> Es lief nicht mehr.

Ich habe dann den Inhalt der Tabelle „s_core_rewrite_urls“ gelöscht --> Es lief immer noch nicht.

Was mit beim Importieren der Daten aufgefallen ist, ist dass es noch einige Tabellen und Spalten von Plugins gab, welche mal installiert waren.

VG

Moritz_Naczenski · 8. Mai 2018 um 19:38

Hauptkategorie des Shops vielleicht inaktiv?

SLS · 8. Mai 2018 um 21:07

Hallo [@Moritz Naczenski](http://forum.shopware.com/profile/14574/Moritz Naczenski „Moritz Naczenski“)‍,

Es sind alle Kategorien Aktiv.

SLS · 14. August 2018 um 07:33

Hallo,

so ich bin mal wieder dazu gekommen etwas am Shop zu machen.

Ich habe eine Installation auf einem lokalen Server gemacht. Dort habe ich die Struktur der Datenbank hinein kopiert und es läuft alles noch.

Dann habe ich die Daten der article Tabellen dazu kopiert und die Daten der Tabelle s_core_rewrite_urls. Es lief dann auch noch.

Alls ich dann die restlichen Daten kopiert habe ging es nicht mehr.

Wie vorher schon geschirben, bleibt das Feld um den Vorgang zu starten ausgegraut.

Hat jemand eine Idee an welchen Daten aus welcher Tabelle es liegen kann oder muss ich nun die Daten von jeder Tabelle einzeln kopieren und gucken wann es nicht mehr funktioniert?

Vielen Dank.

Thema		Antworten	Aufrufe
SEO URLs werden nicht erstellt Allgemein	2	326	7. Dezember 2017
SEO URLs lassen sich nicht mehr generieren Shopware 3.5 administration	13	3084	13. Juli 2014
SEO-Url ändert sich nicht Shopware 3.5 administration	3	474	10. September 2016
SEO URLs werden nicht erstellt. Shopware 3.5 programming	0	2272	20. Oktober 2014
SEO URLS teilweise fehlerhaft Programmierung	5	661	29. Mai 2018

SEO URLs lassen sich nicht erstellen

Verwandte Themen