ich habe alle PHP Tips und Tricks ausprobiert.
backend funktioniert soweit ich http://wpd.ssd-shop.de/shopware.php/backend eingebe.
Direkt über den Installationsroutinebutton komme ich da auch nicht hin. Hat jemand einen Hinweis für mich. Danke im voraus
Passen die SW Systemanforderungen? http://community.shopware.com/Systemanforderungen_detail_1840.html
Lg
also ich muss sagen, dass ich diese Ansicht auch schon gelegentlich hatte. Hoste bei Shopwarepartner, daran kann es nicht liegen.
Da ich während des Artikeleinstellens im FE öfter mal F5 drücke um zu prüfen, kam diese Anzeige auch schon mal. Hab dann gleich nochmal F5 gedruckt und alles war wieder an Ort und Stelle.
@vitago GmbH
Mein Hoster ist 1&1 ( ich weiß, ist nicht gerade der Favorit) und das einzige was er bei der Installation angemeckert hatte war
PHP-Extensions / Webserver
und beim Speicher hatte er keine 256 sondern nur 128
hier meine php. ini
zend_extension =/homepages/13/d1xxxxxx/htdocs/Ioncube/ioncube_loader_lin_5.6.so
memory_limit = 90M;
upload_max_filesize = 40M;
max_execution_time = 50000;
max_input_vars = 5000;
browscap = /usr/lib/browscap.ini
;
error_reporting = E_ALL & ~E_NOTICE & ~E_WARNING
url_rewriter.tags = “a=href,area=href,frame=src,form=fakeentry,fieldset=”;
mysql.default_socket = “/tmp/mysqld.sock”
mysqli.default_socket = “/tmp/mysqld.sock”
session.save_path = “/tmp”
sendmail_path = “/usr/sbin/sendmail -t -i”
extension_dir = “/usr/lib/php/extensions/no-debug-non-zts-20060613”
memory_limit = 256M;
upload_max_filesize = 20M;
magic_quotes_gpc = Off;
allow_url_fopen = on;
und hier noch die htaccess
RewriteEngine on
RewriteBase /
RewriteRule ^(.*).html$ test/index.html
RewriteRule shopware.dll shopware.php
RewriteRule files/documents/.* engine [NC,L]
RewriteRule application.yaml engine [NC,L]
RewriteRule images/ayww/(.*) images/banner/1
RewriteRule sitemap.xml(.\*) shopware.php?controller=SitemapXml
RewriteRule templates/.\*(css|js) engine/backend/php/sCacheTemplate.php?file=0 [NC,L]
RewriteRule engine/core/php/sAjaxSearch.php engine/backend/php/sAjaxSearch.php [NC,L]
RewriteRule engine/core/php/campaigns.php$ engine/backend/php/campaigns.php [NC,L]
RewriteCond %{REQUEST_URI} !(engine/|images/|files/|templates/|.js$|.css$|.jpg$|.png$)
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ shopware.php [PT,L,QSA]
DirectoryIndex index.php
DirectoryIndex shopware.php
Deny from all
Options -Indexes
#php_flag session.auto_start off
#php_flag suhosin.session.cryptua off
#php_flag zend.ze1_compatibility_mode Off
AddType x-mapp-php5 .php
AddHandler x-mapp-php5 .php
wie gesagt Backend funzt
habe das mehrfach versucht zu aktualisieren, habe das template auch schon mehrfach neu geladen und kompiliert, habe auch schon ein anderes Temp. versucht, das selbe Ergebnis
Also wie hier im Forum nachzulesen ist, kommt es bei 1und1 und all-inkl oft zu Problemen.
Welche php Version hast Du?
Lg
Ja, die habe ich meines Erachtens nach alle durch.
PHP 5.6.15
Laut Systeminfo im Backend sind auch alle Shopware Datein vorhanden und verfügbar
Sind die Ordner berechtigungen korrekt? Cache geleert + Theme wieder aufgebaut?
Vitago - überall bei denen FTP-User ungleich Webserver-User laufen, machen Userrechte Probleme - also eigentlich überall da, wo PHP als Apache-Mod läuft, also Sharedsysteme.
Ausser “Lastprobleme” gibt es bei All-Inkl. keine Probleme, wenn man entweder nach dem Upload alles auf Apache-User stellt (dann kann man selber aber nichts mehr per FTP machen), oder man lässt den Shop im CGI-Modus laufen, dann gibt es - ausser Last - NULL Probleme bei All-Inkl! All-Inkl Probleme sind eher E45-Fehler (45cm vor dem Monitor).
Für mich sieht das nach einem Rechteproblem im /web Verzeichnis aus - soll heissen: Kompilieren geht nicht, weil falsche Schreibrechte. Werden denn in /var/log Dateien angelegt? Wenn nein - wohl Rechteproblem, wenn ja: Eine Log-Datei mit Timestamp rund um die Kompilierungszeit wäre mal interessant.
Wollte mit meinem Beitrag ja auch nicht sagen all-inkl ist schei… 
Es ist halt so dass einige bei dem Hoster Probleme habe, da eben viele unerfahren sind. Von daher ist für unerfahrene ein Hosting-Partner von SW sicher die bessere Wahl.
Lg
Vitago 
Die Unerfahrenheit ist das Problem - da nehme ich mich auch nicht aus. Das mit MOD vs. CGI war für mich auch lange unbekannt. Hätte mir früher so manche wundesame Rechteprobleme ersparen können. Nebenbei ist CGI auch sicherer und sollte bei Shardedhosting default sein.
Genug Offtopic. Zu obiges Problem würde ich wirklich gerne mal eine Log-Datei sehen.
Nachtag
der Web Ordner 755
cache 777
was ist ein Hostingpartner von SW?
Nein, der Screenshot ist mehr ein Log über Aktivitäten in Backend - meine ich jedenfalls. 
Im Hauptverzeichnis vom Shop gibt es einen Unterordner /var/log
Treten Fehler auf, wird darin eine Logdatei fortgeschrieben. Kompilierst Du nun das Theme aber es ändert sich nicht, direkt danach in dieses Verzeichnis gucken, ob dort eine Logdatei liegt, deren letzte Änderung zur Zeit oder nach der Kompilierung geändert wurde.Ich hatte letzte Woche einen kleinen Fehler in einer LESS und das Kompilieren ist einfach im Backend hängen geblieben. Den Fehler selber hat mit dann eine Exception angezeigt, die in der Log „gelogged“ wurde. Also: Irgendwas bricht vermutlich wegen einem Fehler ab, und der dürfte dann in der Log-Datei stehen.
Guten Morgen,
im /var liegt eine .htaccess, sonst nichts
