Nach dem Update ist mein shop leider nicht mehr funktionsfähig. Das Update läuft durch sowohl über den Installer als auch über FTP. Anschließend kommt beim Shop selbt ein Error 500 und bei der Admin-Oberfläche die folgende Meldung (.json-Datei). Hat jemand eine Idee, was das sein könnte?
„An exception occurred while executing ‚SELECT app.name, app.version, app.template_load_priority\n FROM app\n INNER JOIN app_template ON app_template.app_id = app.id\n WHERE app.active = 1 AND app_template.active = 1‘:\n\nSQLSTATE[42S22]: Column not found: 1054 Unknown column ‚app.template_load_priority‘ in ‚field list‘“
Von welcher Shopware Version hast du dein Update durchgeführt?
Anscheinend fehlt die Spalte template_load_priority in der Tabelle app.
Könntest du in der Datenbank mal nachgucken?
Aktuelle Version war 6.4.10.1
In der Tabelle app habe ich tatsächlich keine Spalte template_load_priority
Ich probiere morgen mal das hinzuzufügen. Vielleicht könntest Du bei Dir mal nachschauen, was da bei Typ, Länge etc. stehen muss?
Ich vermute dann, dass die Migration/Update bei dir nicht erfolgreich durchgelaufen ist.
Die Spalte kam mit Shopware 6.4.12.0.
platform/Migration1652166447AppLoadPriority.php at trunk · shopware/platform · GitHub
Wie kann ich das korrigieren?
Schau mal, in L28 findest Du die SQL-Anweisung mit allen nötigen Daten 
Vielen Dank schon mal für Eure Hilfe,
Ich habe die Spalte template_load_priorityzur Tabelle app hinzugefügt. Typ INT. Was allerdings mit DEFAULT „0“ gemeint ist, konnte ich leider nicht nachvollziehen. Nun komme ich tatsächlich auch wieder ins Backend, aber beim Frontend kommt immer noch Fehler 500. Ich habe darum mal die .env auf dev gestellt. Nun sagt der Browser im Frontend ERR_TOO_MANY_REDIRECTS und im Backend wird eine ziemlich lange Liste von Fehlern angezeigt, von denen ich nur einen Bruchteil verstehe (die permissions für puplic.pem habe ich bereits geändert):
errors
0
code "0"
status "500"
title "Internal Server Error"
detail "User Notice: Key file \"file:///var/www/XXXXXX/htdocs/shopware/config/jwt/public.pem\" permissions are not correct, recommend changing to 600 or 660 instead of 644"
meta
trace
0
file "/var/www/XXXXXX/htdocs/shopware/var/cache/dev_h9a62f8652d035345be733b3cb6ebda57/Container65EGYVG/Shopware_Core_KernelDevDebugContainer.php"
line 22852
function "__construct"
class "League\\OAuth2\\Server\\CryptKey"
type "->"
1
file "/var/www/XXXXXX/htdocs/shopware/var/cache/dev_h9a62f8652d035345be733b3cb6ebda57/Container65EGYVG/Shopware_Core_KernelDevDebugContainer.php"
line 12026
function "getApiAuthenticationListenerService"
class "Container65EGYVG\\Shopware_Core_KernelDevDebugContainer"
type "->"
2
file "/var/www/XXXXXX/htdocs/shopware/vendor/symfony/event-dispatcher/EventDispatcher.php"
line 245
function "Container65EGYVG\\{closure}"
class "Container65EGYVG\\Shopware_Core_KernelDevDebugContainer"
type "->"
3
file "/var/www/XXXXXX/htdocs/shopware/vendor/symfony/event-dispatcher/EventDispatcher.php"
line 76
function "sortListeners"
class "Symfony\\Component\\EventDispatcher\\EventDispatcher"
type "->"
4
file "/var/www/XXXXXX/htdocs/shopware/vendor/shopware/core/Content/Flow/Dispatching/FlowDispatcher.php"
line 126
function "getListeners"
class "Symfony\\Component\\EventDispatcher\\EventDispatcher"
type "->"
5
file "/var/www/XXXXXX/htdocs/shopware/vendor/shopware/core/Framework/Webhook/WebhookDispatcher.php"
line 161
function "getListeners"
class "Shopware\\Core\\Content\\Flow\\Dispatching\\FlowDispatcher"
type "->"
6
file "/var/www/XXXXXX/htdocs/shopware/vendor/shopware/core/Framework/Event/BusinessEventDispatcher.php"
line 100
function "getListeners"
class "Shopware\\Core\\Framework\\Webhook\\WebhookDispatcher"
type "->"
7
file "/var/www/XXXXXX/htdocs/shopware/vendor/shopware/core/Framework/Event/NestedEventDispatcher.php"
line 69
function "getListeners"
class "Shopware\\Core\\Framework\\Event\\BusinessEventDispatcher"
type "->"
8
file "/var/www/XXXXXX/htdocs/shopware/vendor/symfony/event-dispatcher/Debug/TraceableEventDispatcher.php"
line 293
function "getListeners"
class "Shopware\\Core\\Framework\\Event\\NestedEventDispatcher"
type "->"
9
file "/var/www/XXXXXX/htdocs/shopware/vendor/symfony/event-dispatcher/Debug/TraceableEventDispatcher.php"
line 148
function "preProcess"
class "Symfony\\Component\\EventDispatcher\\Debug\\TraceableEventDispatcher"
type "->"
10
file "/var/www/XXXXXX/htdocs/shopware/vendor/symfony/http-kernel/HttpKernel.php"
line 139
function "dispatch"
class "Symfony\\Component\\EventDispatcher\\Debug\\TraceableEventDispatcher"
type "->"
11
file "/var/www/XXXXXX/htdocs/shopware/vendor/symfony/http-kernel/HttpKernel.php"
line 75
function "handleRaw"
class "Symfony\\Component\\HttpKernel\\HttpKernel"
type "->"
12
file "/var/www/XXXXXX/htdocs/shopware/vendor/symfony/http-kernel/Kernel.php"
line 202
function "handle"
class "Symfony\\Component\\HttpKernel\\HttpKernel"
type "->"
13
file "/var/www/XXXXXX/htdocs/shopware/vendor/symfony/http-kernel/HttpCache/SubRequestHandler.php"
line 86
function "handle"
class "Symfony\\Component\\HttpKernel\\Kernel"
type "->"
14
file "/var/www/XXXXXX/htdocs/shopware/vendor/symfony/http-kernel/HttpCache/HttpCache.php"
line 479
function "handle"
class "Symfony\\Component\\HttpKernel\\HttpCache\\SubRequestHandler"
type "::"
15
file "/var/www/XXXXXX/htdocs/shopware/vendor/symfony/http-kernel/HttpCache/HttpCache.php"
line 452
function "forward"
class "Symfony\\Component\\HttpKernel\\HttpCache\\HttpCache"
type "->"
16
file "/var/www/XXXXXX/htdocs/shopware/vendor/symfony/http-kernel/HttpCache/HttpCache.php"
line 346
function "fetch"
class "Symfony\\Component\\HttpKernel\\HttpCache\\HttpCache"
type "->"
17
file "/var/www/XXXXXX/htdocs/shopware/vendor/symfony/http-kernel/HttpCache/HttpCache.php"
line 224
function "lookup"
class "Symfony\\Component\\HttpKernel\\HttpCache\\HttpCache"
type "->"
18
file "/var/www/XXXXXX/htdocs/shopware/vendor/shopware/core/HttpKernel.php"
line 154
function "handle"
class "Symfony\\Component\\HttpKernel\\HttpCache\\HttpCache"
type "->"
19
file "/var/www/XXXXXX/htdocs/shopware/vendor/shopware/core/HttpKernel.php"
line 79
function "doHandle"
class "Shopware\\Core\\HttpKernel"
type "->"
20
file "/var/www/XXXXXX/htdocs/shopware/public/index.php"
line 85
function "handle"
class "Shopware\\Core\\HttpKernel"
type "->"
file "/var/www/XXXXXX/htdocs/shopware/vendor/league/oauth2-server/src/CryptKey.php"
line 80
Schon den Cache geleert?
Ja, Cache ist geleert.
Was mir noch auffällt, ist, dass kein PlugIn mehr angezeigt wird und ich auch keinen Zugriff auf den Store mehr habe, obwohl ich im Shopware Account angemeldet bin. Keine Ahnung, ob das mit dem ursprünglichen Problem zu tun hat…
Sind denn alle Plugins kompatibel mit der verwendeten Shopware Version?
Wahrscheinlich wird das Problem durch ein inkompatible s Plugin verursacht.
Über die Datenbank alle Plugins deaktivieren und nach und nach aktivieren.
Ich habe alle Plugins und Themes deaktiviert. Zusätzlich habe ich der Datenbank überprüft, ob alle Plugins deaktiviert sind. In der Tabelle Plugin war bei allen Plugins bei active eine 0.
Was mir eben noch aufgefallen ist: Ich habe auch keinen Zugriff mehr auf den Verkaufskanal über das Backend.
Tauchen Fehler im PHP Error Log oder Browser Entwickkungskonsole auf?
Man müsste sich alles angucken und ggf. beheben.
Die Fehler werden direkt angezeigt, wenn ich in der .env APP_ENV=prod einstelle und dann auf meinshop/admin# gehe. Die Entwicklungskonsole habe ich nicht geöffnet. Das scheint aber eine .json Datei zu sein ?!
Das passiert, wenn bei der Überprüfung der Plugins ein Fehler geworfen wird. Der Fehler wird meist in der Datei (XHR), die den Fehler wirft, klar formuliert. Falls du das Plugin findest und die composer.json zu composer.json.bac umbenennst, dann wird das Plugin ignoriert und die Anzeige funktioniert meist wieder.
Aber… deinen ganzen Fehlermeldungen nach… anscheinend ist etwas mit den Rechten falsch gelaufen. Rechte alle gesetzt, wie in der Fehlermeldung bemängelt?
Danke für den Hinweis. Das passiert auch, wenn die Plugins zuvor deaktiviert waren?
Bei den Fehlermeldungen sehe ich nur eine Rechteproblem - ganz oben. Das habe ich behoben. Den Rest verstehe ich allerdings auch nicht wirklich…
Ja, sobald eine composer.json auf dem Server liegt wird diese eingelesen, unabhängig des Status. Dabei kann es zu requirement-Fehlern kommen.
Ich hatte das Problem neulich beim DHL Plugin, dass sich nach dem Update hätte aktualisieren lassen. Da hat dann geholfen, dass ich aus dem Store das ZIP der aktuellsten Version auf den Server manuell kopiert hatte und danach war der composer-Fehler weg.
Heißt aber nicht, dass es bei der genauso ist. Daher schauen, was das XHR im Backend bei den Erweiterungen für einen Fehler wirft.
Ich finde 349 composer.json Dateien. Außerdem finde ich eine Datei namens XHR.js mit dem nachfolgenden Inhalt. Meintest Du die? Ich kann der Datei keine Fehlerangabe entnehmen. Oder bin ich jetzt komplett auf dem Holzweg?
define( [
"../core",
"../var/support",
"../ajax"
], function( jQuery, support ) {
"use strict";
jQuery.ajaxSettings.xhr = function() {
try {
return new window.XMLHttpRequest();
} catch ( e ) {}
};
var xhrSuccessStatus = {
// File protocol always yields status code 0, assume 200
0: 200,
// Support: IE <=9 only
// #1450: sometimes IE returns 1223 when it should be 204
1223: 204
},
xhrSupported = jQuery.ajaxSettings.xhr();
support.cors = !!xhrSupported && ( "withCredentials" in xhrSupported );
support.ajax = xhrSupported = !!xhrSupported;
jQuery.ajaxTransport( function( options ) {
var callback, errorCallback;
// Cross domain only allowed if supported through XMLHttpRequest
if ( support.cors || xhrSupported && !options.crossDomain ) {
return {
send: function( headers, complete ) {
var i,
xhr = options.xhr();
xhr.open(
options.type,
options.url,
options.async,
options.username,
options.password
);
// Apply custom fields if provided
if ( options.xhrFields ) {
for ( i in options.xhrFields ) {
xhr[ i ] = options.xhrFields[ i ];
}
}
// Override mime type if needed
if ( options.mimeType && xhr.overrideMimeType ) {
xhr.overrideMimeType( options.mimeType );
}
// X-Requested-With header
// For cross-domain requests, seeing as conditions for a preflight are
// akin to a jigsaw puzzle, we simply never set it to be sure.
// (it can always be set on a per-request basis or even using ajaxSetup)
// For same-domain requests, won't change header if already provided.
if ( !options.crossDomain && !headers[ "X-Requested-With" ] ) {
headers[ "X-Requested-With" ] = "XMLHttpRequest";
}
// Set headers
for ( i in headers ) {
xhr.setRequestHeader( i, headers[ i ] );
}
// Callback
callback = function( type ) {
return function() {
if ( callback ) {
callback = errorCallback = xhr.onload =
xhr.onerror = xhr.onabort = xhr.ontimeout =
xhr.onreadystatechange = null;
if ( type === "abort" ) {
xhr.abort();
} else if ( type === "error" ) {
// Support: IE <=9 only
// On a manual native abort, IE9 throws
// errors on any property access that is not readyState
if ( typeof xhr.status !== "number" ) {
complete( 0, "error" );
} else {
complete(
// File: protocol always yields status 0; see #8605, #14207
xhr.status,
xhr.statusText
);
}
} else {
complete(
xhrSuccessStatus[ xhr.status ] || xhr.status,
xhr.statusText,
// Support: IE <=9 only
// IE9 has no XHR2 but throws on binary (trac-11426)
// For XHR2 non-text, let the caller handle it (gh-2498)
( xhr.responseType || "text" ) !== "text" ||
typeof xhr.responseText !== "string" ?
{ binary: xhr.response } :
{ text: xhr.responseText },
xhr.getAllResponseHeaders()
);
}
}
};
};
// Listen to events
xhr.onload = callback();
errorCallback = xhr.onerror = xhr.ontimeout = callback( "error" );
// Support: IE 9 only
// Use onreadystatechange to replace onabort
// to handle uncaught aborts
if ( xhr.onabort !== undefined ) {
xhr.onabort = errorCallback;
} else {
xhr.onreadystatechange = function() {
// Check readyState before timeout as it changes
if ( xhr.readyState === 4 ) {
// Allow onerror to be called first,
// but that will not handle a native abort
// Also, save errorCallback to a variable
// as xhr.onerror cannot be accessed
window.setTimeout( function() {
if ( callback ) {
errorCallback();
}
} );
}
};
}
// Create the abort callback
callback = callback( "abort" );
try {
// Do send the request (this may raise an exception)
xhr.send( options.hasContent && options.data || null );
} catch ( e ) {
// #14683: Only rethrow if this hasn't been notified as an error yet
if ( callback ) {
throw e;
}
}
},
abort: function() {
if ( callback ) {
callback();
}
}
};
}
} );
} );
Wenn du das Backend öffnest, auf z.B. meine Erweiterungen gehst, dann werden dort viele XHR-Request an Shopware geschickt und dort bekommst du in der Regel eine json Datei zurück. Unter umständen wirft eines dieser XHR-Requests ein Fehler und lässt das Backend abstürzen. Es geht hier nicht um eine Datei!
Wenn ich deinen Ausgangsproblem noch einmal lese, ggf. hat sich deine Datenbank zerschossen und es fehlen noch weitere Spalten/Tabellen.
Da hilft leider wirklich nur nach jedem Aufruf in den error log schauen und die Fehler analysieren.
Okay, ich fürchte, das übersteigt meine Fähigkeiten. Ich habe die „Werkzeuge für Webentwickler“ eingeschaltet, aber ich verstehe quasi nichts von dem, was da ausgegeben wird. Ich bin echt genervt, dass Shopware bei jedem Update solche Zicken macht. Jedes Mal tagelanges Reparieren und herumprobieren, bis es wieder läuft… Ich spiele jetzt erst mal wieder das Backup ein und versuche es morgen nochmal. Aber so langsam gehen mir die Ideen aus.
In dem Fall würde ich sagen, dass in deinem Hosting/Konfiguration etwas grundlegend nicht stimmt.