URLs per .htaccess umleiten

Wenn eine URL erst einmal in Umlauf ist, lässt sich diese nur schwer wieder loswerden. Sollte sich jedoch in der Zwischenzeit ein Fehler eingeschlichen haben oder die Seite ist unter einer anderen URL erreichbar, dann brauchen Sie eine URL-Weiterleitung. Gleichzeitig benötigen Sie aber auch für bspw. Google einen Status Code, der dem jeweiligen Robot sagt, dass eine Weiterleitung vorliegt und die Seite jetzt unter einer neuen URL aufrufbar ist oder dass die Seite gar nicht mehr aktiv ist und nicht mehr existiert.

Was ist ein HTTP-Statuscode?

„Ein HTTP-Statuscode wird von einem Server auf jede HTTP-Anfrage als Antwort geliefert. Der Server teilt durch den HTTP-Statuscode dem Client mit, ob die Anfrage erfolgreich bearbeitet wurde. Im Fehlerfall gibt der Statuscode Auskunft darüber, wo (beispielsweise über einer Umleitung) oder wie (zum Beispiel mit Authentifizierung) er die gewünschten Informationen erhalten kann.“

Quelle: https://de.wikipedia.org/wiki/HTTP-Statuscode

Falls Sie oder Ihr Hoster einen Apache Server im Einsatz haben, dann können Sie die Weiterleitungen in der Datei .htaccess einrichten. Diese liegt im Root-Verzeichnis Ihrer Webseite.

301 – Weiterleitungen

Damit leiten Sie eine alte Url zu einer neuen um.

Fügen Sie an das Ende Ihrer Datei alle Weiterleitungen im folgenden Format ein. Für jede Weiterleitung wird eine separate Zeile verwendet.

.htaccess

#old urls to new ones
Redirect 301 /oldurl  /newurl
Redirect 301 /oldurl2  /newurl2
Redirect 301 /oldurl3  /newurl3

410 – Weiterleitungen

Dazu richten Sie zunächst eine Infoseite ein, auf die weitergeleitet wird. Hier erfährt der Besucher Ihrer Seite, dass die aufgerufene Seite nicht mehr vorhanden ist. Im folgenden Bsp. habe ich eine Datei 410.php im Root-Verzeichnis angelegt. Das ist eine rein informative Seite. Der eigentliche Status Code wird vorher schon bei der Weiterleitung gesendet.

Datei 410.php

<?php
echo "Die aufgerufene Seite ist nicht mehr vorhanden.";
?>

.htaccess

Auch hier fügen Sie die nicht mehr existierenden Seiten an das Ende der Datei wie folgt an.

#Error file
ErrorDocument 410 /410.php
#urls, which do not exist anymore
Redirect Gone  /oldurl
Redirect Gone  /oldurl2
Redirect Gone  /oldurl3

Damit müssten Sie die aufgelaufenen URLs unter den Crawler Fehlern aus dem Google Webmaster Tools beheben und beseitigen können.

Wenn Sie oder Ihr Hoster Nginx im Einsatz haben, dann ist keine Datei .htaccess vorhanden. Hier werden die Weiterleitungen in der Nginx-Konfiguration eingetragen.

Für Shopware gibt es jetzt mit dem Plugin „SEO Fehlerseiten und Weiterleitungen (404, 301 und 410)“ auch eine einfachere Möglichkeit – nämlich URLs über das Backend weiterzuleiten. Hier werden die Fehlerseiten direkt in der DB gespeichert und Sie müssen nicht mehr warten bis die Google Webmaster Tools die Crawler Fehler endlich anzeigen. Bei aufgelaufenen Fehlern entscheiden Sie, ob Sie eine 410- oder 301 Weiterleitung einrichten möchten. Hier geht es zum Plugin.

Die Scrum-Revolution

Folgender Gastbeitrag stammt von der Firma Adacor Hosting GmbH, welchem ich voll ganz zustimme.

Softwareentwicklung besitzt oftmals einen hohen Stellenwert in einem Unternehmen. Doch nach wie vor sind spezialisierte Softwareentwickler eine begehrte Mangelware auf dem Arbeitsmarkt und dementsprechend schwer zu finden. Zudem gehören Softwareentwickler zu den bestbezahltesten Mitarbeitern. Ein entscheidender Faktor ist, dass Softwareentwicklungen sehr komplexe und zeitaufwendige Prozesse sind, was einen Projektverlauf entscheidend beeinflussen kann. Klassische Projektplanung führt oft zu einem unflexiblen und bürokratischen Vorgehen, daher geht der Trend hin zum agilen Projektmanagement – mit Scrum. Aber was ist das eigentlich?

Grenzen klassischer Entwicklungsmethoden

Das hergebrachte Wasserfallmodell bei dem der Entwicklungsprozess aus einzelnen Phasen besteht, stößt an seine Grenzen, wenn flexible Reaktionen gefragt sind oder sich die Umgebungsbedingungen rasch ändern.

Folgende Fragen illustrieren die Herausforderungen:

  • Was tun, wenn die Teamgröße zunimmt?
  • Wie kann eine optimale Wissensverteilung gewährleistet bleiben?

So entstanden bei der klassischen Methode Schwierigkeiten durch die Ernennung von nur einem Entwickler zum Projektverantwortlichen. Dieser betreute das Projekt von Anfang bis Ende allein, mit der Folge, dass dem Vorgesetzten die Übersicht über den Fortschritt fehlte. Darüber hinaus erforderte die Ein-Mann-Verantwortlichkeit große Anstrengungen bei der Priorisierung der Projekte untereinander, denn es kannten sich immer nur wenige Mitarbeiter in einem Projekt aus. Erschwerend kam hinzu, dass diese häufig mit langlaufenden Tasks arbeitstechnisch schon voll ausgelastet waren.

Im Laufe von Projekten konnte außerdem beobachtet werden, dass die Motivation des Programmierers regelmäßig sank. Die Gründe dafür sind nachvollziehbar: So entstand durch die immer gleiche eintönige Arbeit über lange Zeiträume hinweg eine gewisse Monotonie. Zusätzlich fühlten sich die Projektverantwortlichen teilweise allein gelassen oder überfordert. Unter diesen Voraussetzungen war Führung nur schwer möglich. Denn so wie die Motivation der Entwickler im Projektverlauf abnahm, konnte der Vorgesetzte kaum sinnvoll in das Geschehen eingreifen, geschweige den Projektfortschritt realistisch kontrollieren.

Zunehmende Komplexität und Inselwissen wird zum Problem

Entwicklungsprojekte nehmen normalerweise eine Komplexität an, die es für nicht tiefgreifend beteiligte Personen nahezu unmöglich macht, sinnvolle Entscheidungen für die weitere Vorgehensweise bei der Programmierung zu treffen. Weiterhin fördert eine solche Arbeitsweise die Entstehung von Inselwissen, was in der Vergangenheit bei Krankheit oder der Urlaubsplanung regelmäßig zu Planungsschwierigkeiten führte.

Zuletzt hatten die Entwickler aber auch dieselben Probleme, die für die meisten Prozessreformer in Richtung Scrum die Hauptgründe für einen Umstieg sein dürften: Fehlerhafte Einschätzungen bei der Höhe der Entwicklungsbudgets und die Entwicklung von Spezifikationen die sich nicht vollständig an den Bedürfnissen der Nutzer orientieren.

Vorteile für den Einsatz von Scrum

Unternehmen scheuten trotzdem lange Zeit den Schritt zur Einführung von Scrum. Der Grund für den langfristigen Einsatz der klassischen Entwicklungsmethoden waren Kundenanforderungen, die im Gegensatz zu der Vorgehensweise bei Scrum stehen. Viele Kunden fragen nämlich bereits vor einer Beauftragung nach einem möglichst genauen Maximalpreis sowie nach einer detaillierten, verlässlichen Spezifikation für die jeweilige Anpassung oder Neuentwicklung.

Eine Software nach dem Scrum-Prinzip zu entwickeln, bedeutet für den Kunden zu Beginn weder ein Gesamtbudget noch ein finales Konzept präsentiert zu bekommen. Diese Tatsache mag sich für einige Manager ungewohnt anfühlen, allerdings führt die intensive Zusammenarbeit des Scrum Teams während des Entwicklungsprozesses dazu, dass alle Beteiligten stets eng mit dem Projekt verbunden bleiben.

Der maßgebliche Vorteil für den Einsatz von Scrum in der Entwicklung, lässt sich wie folgt darstellen: Am Ende erhält der Kunde die Software, die er braucht und nicht eine, die nur anhand von Spezifikationen entwickelt wurde.

Darüber hinaus führt das schrittweise Vorgehen bei Scrum dazu, dass die Entwicklung einer Anwendung für den Kunden im Schnitt nicht nur günstiger ist, sondern sie ist optimal an seine Anforderungen angepasst. Ein weiterer Vorteil zeigt sich im frühzeitigen Ausprobieren der Software. Hierbei hat der Kunde die Möglichkeit, den Entwicklungsprozess nach jedem Sprint zu beenden, wenn die Software seiner Meinung nach genug Features enthält.

Der Scrum-Prozess – Motivation durch Selbstorganisation

BU: Scrum-Prozess bei der ADACOR

BU: Scrum-Prozess bei der ADACOR

Scrum unterscheidet drei Rollen: Product Owner (Software-Verantwortlicher auf Kundenseite), Entwicklungsteam (Unternehmen) und Scrum Master. Der Scrum Master unterstützt den Workflow in erster Linie als Moderator. Außerdem führt er die Scrum-Regeln ein und überprüft deren Einhaltung. Der Scrum Master gibt den Teammitgliedern keine Anweisungen. Obwohl der Scrum-Prozess einem festen Regelwerk sowie Priorisierungsvorgaben des Management beziehungsweise des Product Owner unterliegt, entscheiden die einzelnen Entwickler unter Berücksichtigung dieser Vorgaben relativ eigenständig, was sie in den nächsten Sprint aufnehmen wollen. In der praktischen Umsetzung zeigt sich, dass die Selbstorganisation zu einer enormen Motivationssteigerung bei den Entwicklern führt. Häufig nehmen diese sich eher zu viel vor als zu wenig. Es kommt sogar vor, dass sie früher als geplant ein selbst gestecktes Ziel erreichen, sofern der Vorgesetzte den Sprint nicht unterbricht und damit das Commitment hinfällig wird.

Sprint: Fester Zeitraum zur Umsetzung von Anforderungen

Ein Sprint ist ein Arbeitsschritt mit einer im Vorfeld festgelegten Zeitdauer, bei der ADACOR Hosting sind das zwei Wochen. Vor jedem Sprint plant das Scrum Team die Inhalte für den nächsten Sprint. Dabei folgen die Sprints immer direkt aufeinander. Dieses Vorgehen bietet verschiedene Vorteile: Die Zwei-Wochen-Schritte ermöglichen flexibles Handeln, sodass im Vorfeld kein fertiges Konzept erforderlich ist. Das Sprint Team benötigt vom Kunden nur eine Vision und eine User Story (Anforderungen im Product Backlog). Diese Anforderungen aus Kundensicht werden immer mit dem Kunden zusammen erarbeitet. Das Sprint Team erarbeitet im Sprint-Kick-off aus den User Storys anschließend die konkreten Tasks für das Sprint Backlog.

Unterstützt wird ein Sprint durch Daily-Scrum-Meetings. Dabei treffen sich das Entwicklerteam – sowie bei Bedarf der Scrum Master und/oder der Product Owner – täglich zu Arbeitsbeginn zu einem etwa 15-minütigen Informationsaustausch. Hier werden keine Probleme gelöst, sondern es geht für die Teilnehmer darum, sich einen Überblick über den aktuellen Stand der Arbeit zu verschaffen.

Der Sprint endet nach zwei Wochen mit einem Review (Prüfung aller Anforderungen, die bisher im Rahmen der Sprints fertiggestellt wurden), um das Product Backlog bei Bedarf anpassen zu können beziehungsweise einer Retrospektive, die kritische Überprüfung der bisherigen Arbeitsweise,  innerhalb des Teams sowie einem Ergebnisreport an die Stakeholder (Kunde, Anwender, Management). Damit bietet der Prozess für alle Beteiligten eine hohe Transparenz und die Gelegenheit, sich laufend über den Realisationsfortschritt zu informieren. Bei gleichzeitiger Anwendung des Konzepts der kontinuierlichen Integration (im Englischen bekannt als „continuous integration“) werden alle funktionierenden und abgenommenen Teile der entwickelten Software sogar sofort nach dem Sprint Review in das Produktivsystem eingespielt und damit direkt unter Produktivbedingungen getestet und eingesetzt. Hierdurch kann die Software noch besser und genauer auf die Nutzeranforderungen abgestimmt werden. Das Konzept eignet sich jedoch nicht für sehr betriebskritische Applikationen.

Als sehr positiv erweist sich beim Einsatz von Scrum die Wissensverteilung innerhalb des Sprint Teams. Gab es vor dem Umstieg oft die Situation, dass sich zu wenige Mitarbeiter mit einem Projekt auskannten und das Wissen schlecht verteilt war, führt die Selbstorganisation zu einer automatischen Wissensverteilung im Sprint Team, ohne dass dies der Vorgesetzte forcieren muss. Im Unternehmen wurde dieser Effekt durch den zusätzlichen Einsatz von Pair Programming als erwünschtes Konzept im Sprint noch verstärkt.

Fazit – vermeintlicher Nachteil verkehrt sich in Vorteil

Die Performance im Entwicklungsbereich hat sich durch Scrum insgesamt verbessert und die Arbeitsprozesse verlaufen generell reibungsloser.

Nachteilig ist bei Scrum auf den ersten Blick, dass zu Beginn weder die Gesamtkosten noch ein konkreter Umsetzungszeitraum genannt werden können. Dieser Nachteil verkehrt sich jedoch zu einem Vorteil, denn Schätzungen großer Projekte sind grundsätzlich aufwendig und ungenau. Darüber hinaus verlangen Entwickler stets hohe Sicherheitsaufschläge, um die Unsicherheit bei der Schätzung zu kompensieren. Bei Anwendung des Scrum-Prinzips und einer Bezahlung nach Aufwand, entfällt der Sicherheitsaufschlag für den Kunden.

PhpMyAdmin durch Shopware-Plugin aufrufen

PhpMyAdmin

PhpMyAdmin

Inspiriert durch den Blogartikel von Thomas Eiling habe ich sein Plugin für den Aufruf von PhpMyAdmin angepasst.

Es kommt öfters vor, dass bei Supportanfragen ein Blick auf die Datenbank notwendig ist, jedoch der Shopbetreiber weder Zugangsdaten hat, noch weiß, wie man auf die Datenbank zugreifen kann.

Damit ist jetzt Schluss.

Mit diesem Plugin MbdusPhpmyadmin wird automatisch PhpMyAdmin im eingeloggten Zustand aufgerufen. D.h. Zugangsdaten werden nicht benötigt. Lediglich Ihr Shopware-Benutzer muss API-Zugangsrechte und einen API-KEY besitzen. Andernfalls gelangen Sie zum Login-Fenster von PhpMyAdmin.

Laden Sie zunächst die Zip-Datei über den Pluginmanager „Plugin manuell hochladen“ hoch und installieren es.

Um zu PhpMyAdmin zu gelangen, rufen Sie im Shopware-Menü unter Einstellungen -> PhpMyAdmin auf.

Auf Github können Sie den Quellcode des Plugins unter https://github.com/mbdus/MbdusPhpMyAdmin finden.

Debuggen mit Shopware in einem Live-Shop

Es ist ein Fehler in Ihrem Shopware Shop aufgetreten. Um den Fehler finden zu können, müssten Sie an einer oder sogar einigen Stellen einen Variableninhalt prüfen. Das geht mit bspw. print_r relativ einfach und schnell. Das Problem ist nur, dass man die Ausgaben auf den Shopseiten sieht…

Um die Ausgaben im Hintergrund (Konsole) angezeigt zu bekommen, gibt es zwei Möglichkeiten:

Debug-Plugin

Hier geht es zum Shopware-Wikiartikel.

Aktivieren Sie das Debug-Plugin im Pluginmanager. Am besten tragen Sie in den Einstellungen noch Ihre IP-Adresse ein. Dann bekommen nur Sie die Konsolenausgaben angezeigt. Für Firefox benötigen Sie das AddOn Firebug. Nach der Installation und Öffnen von Firebug bekommen Sie die Shopwareausgaben (Templatevariablen, Exceptions, etc.) in der Konsole angezeigt.

In Ihrem Plugin oder an beliebig anderer Stelle können Sie
Shopware()->Debuglogger()->info('test');

verwenden, um bspw. einen Variableninhalt angezeigt zu bekommen.

Debug-Plugin mit Testausgabe

Debug-Plugin mit Testausgabe

Nur was tun, wenn Sie bspw. den Inhalt eines Arrays angezeigt bekommen möchten?

Leider funktioniert die Beschreibung aus diesem Shopware-Wikiartikel in den aktuellen Shopware 5 Versionen nicht mehr.

Abhilfe verschafft hier die Umwandlung des Arrays zu einem String:
$var = print_r($array, true);
Shopware()->Debuglogger()->info($var);

Generell bekommen Sie auch alle Templatevariablen in der Konsole angezeigt, die im PHP-Teil definiert und dem Template zugewiesen wurden.

Was tun, wenn Sie aus Ihrem Template heraus Variablen debuggen möchten?

Dazu können Sie in Ihrem Template den Befehl {debug} an der entsprechenden Stelle einfügen. Mit Aufruf des Templates wird eine neue Seite geöffnet, die alle Templatevariablen enthält. Allerdings muss Ihre neu Variable vorher wie folgt definiert worden sein:
{assign var="testOutput" value="hallo Welt"}

Da die Debuginfo nicht jeder sehen können soll, fügen Sie noch eine Abfrage mit Ihrer IP-Adresse hinzu:


{if $smarty.server.REMOTE_ADDR == '33.33.33.1'}

     {assign var="testOutput" value="hallo Welt"}

     {debug}

{/if}

{debug} muss dabei immer nach dem Quellcode-Teil stehen, den Sie debuggen möchten.

Debuggin in Smarty mit Testausgabe

Debuggin in Smarty mit Testausgabe

Shopware-Entwicklungsumgebung unter Windows

Mit Shopware 5 wird zwingend eine Linuxumgebung vorausgesetzt. Aber auch unter Windows ist es noch möglich per VitualBox lokal sich eine Entwicklungsumgebung einzurichten. Zusätzlich wird in diesem Tutorial erklärt, wie man in Eclipse per Rsync und Ant die Shopwaredateien automatisiert auf den Server übertragt (deployed).

Zunächst benötigen Sie folgende Software:

Ein vorbereitetes Vagrant Setup gibt es unter https://github.com/shopwareLabs/shopware-vagrant. Nach der Installation ist u.a. ein Apache- und MySql-Server und PhpMyAdmin installiert und konfiguriert. Eine Anleitung von Shopware gibt es unter https://developers.shopware.com/developers-guide/vagrant-phpstorm/. Dort wird jedoch die Einrichtung für PhpStorm erklärt.

Das obige Setup ist noch ohne eine Shopware-Installation. Dafür kann man damit auch andere Systeme wie Joomla, WordPress, etc. nutzen.

Nachdem Sie die Software VirtualBox, Vagrant und das Vagrant Setup heruntergeladen, entpackt und/oder installiert haben, sollten drei Verzeichnisse vorliegen:

  • Oracle (bspw.: d:\oracle\vmbox\)
  • Vagrant (bspw: d:\vagrant\)
  • Shopware-Vagrant (bspw.: d:\shopware-vagrant\)

Jetzt müssen Sie den Pfad zu Vagrant unter den Systemvariablen in Windows eintragen.

Dazu klicken Sie per Rechtsklick auf „Computer“, „Eigenschaften“ und dort auf „Erweiterte Systemeinstellungen“. Im Tab „Erweitert“ finden Sie den Button „Umgebungsvariablen“. Unter „Path“ tragen Sie den Pfad zum bin-Verzeichnis des Vagrant-Ordners ein.

Bsp.: d:\vagrant\bin

Systemeigenschaften

Systemeigenschaften

Umgebungsvariablen

Umgebungsvariablen

 

 

 

 

 

 

 

 

 

 

Systemvariable

Systemvariable

 

 

 

 

 

 

 

Cygwin

Um später aus Eclipse heraus auch Linux-Befehle ausführen zu können, brauchen wir noch die Möglichkeit Linuxbefehle unter Windows ausführen zu können. Dafür gibt es Cygwin. Cygwin stellt eine Reihe von Linux-Tools zur Verfügung. Das installieren wir an dieser Stelle noch gleich mit. Laden Sie sich die Datei setup.exe unter https://www.cygwin.com herunter und führen Sie die Installation durch.

Achten Sie darauf, dass die Pakete „rsync“ und „openssh“ aus der „Net“-Kategorie ausgewählt sind und mit installiert werden.

Anschließend tragen Sie unter den Systemvariablen, wie im vorherigen Schritt bereits erläutert, unter „Path“ den Pfad zum bin-Verzeichnis von Cygwin ein.

Bsp.: d:\cygwin\bin

Jetzt beginnen wir mit dem Vagrant Setup und erstellen ein Image für VitualBox.

Wechseln Sie zunächst im Kommandofenster in den Shopware-Vagrant\Vagrant Ordner. Dort starten Sie die automatische Konfiguration mit „vagrant up“.

vagrant

vagrant

Das kann jetzt einige Zeit (mehrere Minuten) dauern.

Wenn die Konfiguration funktioniert hat und der Server hochgefahren ist, ist der Server im Browser über:

https://33.33.33.10 erreichbar.

 

 

 

PhpMyAdmin:

https://33.33.33.10/phpmyadmin/

MySql-Zugangsdaten:

Benutzer: root

Passwort: shopware

SSH

Zugangsdaten:

Benutzer: vagrant

Passwort: vagrant

Damit Sie rsync in Eclipse, ohne ein Passwort eingeben zu müssen, nutzen können, benötigen Sie einen Public Key.

Diesen erzeugen Sie im Kommandofenster mit:
ssh-keygen

 

Geben Sie bei der Passwortabfrage kein Passwort ein.

Jetzt wurde ein Public und Private Key angelegt.

Der Public Key wird wie folgt auf den Server kopiert:

scp ~/.ssh/id_rsa.pub vagrant@33.33.33.10:~/
Abschließend wird der Public Key u.a. noch kopiert (hier muss noch ein Passwort eingegeben werden):
ssh vagrant@33.33.33.10
install -dv ~/.ssh
chmod 0700 ~/.ssh
cat id_rsa.pub >> ~/.ssh/authorized_keys
rm id_rsa.pubexit

Beim erneuten Aufruf sollten Sie kein Passwort mehr eingeben müssen:
ssh vagrant@33.33.33.10

Eclipse

In Eclipse können Sie entweder im Git-Fenster (Window -> Show View -> Other Git) direkt die Shopware-Dateien in ein neues Projekt von https://github.com/shopware/shopware.git klonen oder eine Zip-Datei von https://shopware.de herunterladen, entzippen und die entzippten Dateien in ein neues PHP-Projekt kopieren.

RSYNC, Ant

Weiter legen Sie in Eclipse in Ihrem Projekthauptverzeichnis zwei Dateien an und kopieren folgenden Inhalt rein.

build.properties:
#Rsync
rsync.username=vagrant
rsync.password=vagrant
rsync.host=127.0.0.1
rsync.dir=/home/vagrant/www/shopware/

build.xml:
<?xml version="1.0" encoding="UTF-8"?>
<project name="Demoshop">
<property file="build.properties" />
<target name="deploy" description="deploy usng rsync" >
<echo>Uploading files per rsync</echo>
<echo>${rsync.username}@${rsync.host}:${rsync.dir}</echo>
<exec executable="rsync" dir="." failonerror="true">
<arg line="-aOvz --chmod=a=rwx,Da+x --delete-after --exclude .svn .\
. --exclude .settings .\
. --exclude build.xml .\
. --exclude .project .\
. --exclude .buildpath .\
. --exclude *.properties .\
. --exclude .gitignore .\
. --exclude .editorconfig .\
. --exclude .idea .\
. --exclude .travis.yml .\
. --exclude /RemoteSystemsTempFiles/ .\
. --exclude /.metadata/ .\
. --exclude /.\/ .\
. --exclude /bin/ .\
. --exclude /cache/ .\
. --exclude /media/image/ .\
. --exclude /vendor/ .\
. --exclude /recovery/ .\
. --exclude /_sql/ .\
${rsync.username}@${rsync.host}:${rsync.dir}"/>
</exec>
</target>
</project>

Das sind die beiden Dateien, die für den automatischen Austausch der Dateien zwischen dem Server und Eclipse zuständig sind. Per Ant wird Rsync aufgerufen und es werden die Ordner und Dateien abgeglichen.

Unter den Zeilen mit „. –exclude“ werden alle Dateien und Verzeichnisse angegeben, die nicht berücksichtigt und abgeglichen werden sollen.

Sie könnten auch SFTP verwenden, damit werden aber „nur“ automatisiert geänderte oder neue Dateien hochgeladen und nicht auch gelöscht.

Abschließend öffnen Sie über Window -> Show View -> Other „Ant“. Ein neues Fenster wird im unteren Bereich hinzugefügt. Dort ziehen Sie per Drag & Drop die Datei build.xml rein.

Deploy in Eclipse

Deploy in Eclipse

 

 

 

 

 

 

 

 

Über einen Rechtsklick auf „deploy“ starten Sie den Upload der Shopware Dateien.

Datenbank, Shopware Installation

Über PhpMyAdmin (https://33.33.33.10/phpmyadmin/) legen Sie zuerst eine leere Datenbank an. Danach können Sie mit Aufruf der URL https://33.33.33.10/shopware/ die Shopware Installation starten.

Beim ersten Aufruf des Backends startet der “First Run Wizard”. Darin können Sie u.a. auch Demodaten installieren.