Tobias Forkel

Magento2 Module mit Konfigurationen verlinken

In der Regel werden Magento® 2 Module mit einer ./etc/adminhtml/system.xml Datei implementiert, welche dazu dient, zusätzliche Konfigurationen unter Stores > Configuration zur Verfügung zu stellen um diverse Funktionen im konfigurierbar zu machen.

Allerdings ist es nicht immer offensichtlich, wo diese zu finden sind. Es kommt vor, dass man solche Einstellungen erst nach Minuten unter Stores > Configuration findet, was unter umständen frustrierend sein kann. Darum möchte ich gerne meine Lösung teilen, welche ich inzwischen in jedem meiner Module implementiere und welche aus meiner Sicht durch jedem Backend-Entwickler in wenigen Minuten implementiert werden kann.

XML Layout

Zuerst muss eine existierende Layout Datei ( zum Beispiel ./view/adminhtml/layout/namespace_module_custom_index.xml ) ergänzt werden.

<?xml version="1.0"?>
<page xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="urn:magento:framework:View/Layout/etc/page_configuration.xsd">
<body>
    <referenceContainer name="content">
        <uiComponent name="namespace_module_custom_index"/>
        <block class="Magento\Framework\View\Element\Template" name="namespace.module.adminhtml.info" template="Namespace_Module::info.phtml"/>
    </referenceContainer>
</body>
</page>

<?xml version="1.0"?>

<body>

</referenceContainer>

</body>

</page>

Innerhalb des Reference Containers content muss folgender Block platziert werden.

<block class="Magento\Framework\View\Element\Template" name="namespace.module.adminhtml.info" template="Namespace_Module::info.phtml"/>

1	<block class="Magento\Framework\View\Element\Template" name="namespace.module.adminhtml.info" template="Namespace_Module::info.phtml"/>

Wichtig hier ist die Referenz zum Template Namespace_Module::info.phtml welche im nächsten Schritt genauer erklärt wird.

Template

Die Referenz Namespace_Module::info.phtml im folgenden Block erwartet eine info.phtml Datei im Verzeichnis ./view/adminhtml/templates/ welche lediglich folgenden HTML Code enthalten sollte.

<div id="namespace-module">
    <p><?php echo __('Go to <a href="%1">Stores > Configuration > Advanced > Admin</a> for module settings.', $this->getUrl('adminhtml/system_config/edit/section/admin')); ?></p>
</div>

<p><?php echo __('Go to <a href="%1">Stores > Configuration > Advanced > Admin</a> for module settings.', $this->getUrl('adminhtml/system_config/edit/section/admin')); ?></p>

</div>

Der Link-Text sowie der Parameter für getUrl muss natürlich noch geändert werden. Mein Beispiel zeigt auf Stores > Configuration > Advanced > Admin.

Cheers

Checkbox aus UI Component Listing in Magento2 entfernen

In der Regel werden UI Component Listings mit MassActions und Checkboxen erstellt, so dass in der Übersicht mehrere Elemente mit einer Aktion ( massAction ) gelöscht werden können.

In einigen Fällen braucht es diese Funktion jedoch nicht. Zum Beispiel wenn Datensätze nur hinzugefügt oder geändert werden sollen können, und/oder das Löschen von Datensätzen nur in der Detailansicht möglich sein soll.

Um die oben gezeigte Checkbox zu entfernen muss die XML Datei geöffnet werden, welche das für das neue Listing zuständig ist. Zum Beispiel:

[Namespace]/[Module]/view/adminhtml/ui_component/[namespace]/[module]_listing.xml

1	[Namespace]/[Module]/view/adminhtml/ui_component/[namespace]/[module]_listing.xml

In dieser Datei sollte sich die XML Node selectionColumn befinden, welche ohne weiteres entfernt werden kann.

<selectionsColumn name="ids">
	<argument name="data" xsi:type="array">
		<item name="config" xsi:type="array">
			<item name="resizeEnabled" xsi:type="boolean">false</item>
			<item name="resizeDefaultWidth" xsi:type="string">55</item>
			<item name="indexField" xsi:type="string">id</item>
		</item>
	</argument>
</selectionsColumn>

<item name="resizeEnabled" xsi:type="boolean">false</item>

</item>

</argument>

</selectionsColumn>

An der Stelle genügt es den Magento cache zu leeren um die Änderungen zu sehen.

PayPal Express Checkout und Unable to Place the order

Ich habe schon einige Probleme mit PayPal und Magento gelöst, aber folgendes war neu. Kunden konnten vom Warenkorb aus über den Check out with PayPal Button ganz normal die Bezahlung vornehmen. Nach erfolgreicher Bezahlung wurde jedoch die Fehlermeldung ” Unable to Place the order ” angezeigt und die Bestellung unterbrochen. Einige Kunden dachten etwas während der Bestellung falsch gemacht zu haben, und versuchten es gleich noch einmal. Nun wurde die Fehlermeldung ” Transaction refused because of an invalid argument. A successful transaction has already been completed for this token. ” angezeigt.

Kurz, beim ersten Versuch wurde das PayPal Konto bzw. die Kreditkarte des Kunden bereits belastet. Darum konnte beim zweiten Versuch die Transaction nicht noch einmal vorgenommen werden. Hinzu kam, dass trotz korrekten IPN Response im Backend keine Bestellung erstellt wurde. Der Grund war folgender:

2015-06-11T06:50:23+00:00 ERR (3):
exception 'PDOException' with message 'SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '100000213' for key 'UNQ_SALES_FLAT_INVOICE_INCREMENT_ID''

1 2	2015-06-11T06:50:23+00:00 ERR (3): exception 'PDOException' with message 'SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '100000213' for key 'UNQ_SALES_FLAT_INVOICE_INCREMENT_ID''

Bei solchen Fehlermeldungen lohnt es sich immer einen Blick in die EAV tables zu werfen. In meinem Fall wurde aus irgendeinem Grund die increment_last_id vom Typ sales/order_invoice geändert.

mysql> select * from eav_entity_store;
+-----------------+----------------+----------+------------------+-------------------+
| entity_store_id | entity_type_id | store_id | increment_prefix | increment_last_id |
+-----------------+----------------+----------+------------------+-------------------+
|               1 |              5 |        1 | 1                | 100000798         |
|               2 |              6 |        1 | 1                | 1212              |
|               3 |              8 |        1 | 1                | 100000028         |
+-----------------+----------------+----------+------------------+-------------------+
3 rows in set (0.01 sec)

mysql> select * from eav_entity_store;

+-----------------+----------------+----------+------------------+-------------------+

+-----------------+----------------+----------+------------------+-------------------+

| 1 | 5 | 1 | 1 | 100000798 |

| 2 | 6 | 1 | 1 | 1212 |

| 3 | 8 | 1 | 1 | 100000028 |

+-----------------+----------------+----------+------------------+-------------------+

3 rows in set (0.01 sec)

Die Länge der ID wird zudem in entity_model festgelegt, was in meinem Fall nicht übereinstimmte.

mysql> select entity_model, increment_pad_length from eav_entity_type where entity_type_id = 6;
+---------------------+----------------------+
| entity_model        | increment_pad_length |
+---------------------+----------------------+
| sales/order_invoice |                    8 |
+---------------------+----------------------+
1 row in set (0.00 sec)

mysql> select entity_model, increment_pad_length from eav_entity_type where entity_type_id = 6;

+---------------------+----------------------+

| entity_model | increment_pad_length |

+---------------------+----------------------+

| sales/order_invoice | 8 |

+---------------------+----------------------+

1 row in set (0.00 sec)

Da es keinen Grund gab die länge der Rechnungs Nummer zu ändern, habe ich diese wieder “recovered”.

mysql> UPDATE `eav_entity_store` SET `increment_last_id` = '200000001', `increment_prefix` = '2' WHERE `entity_type_id` = '6';

1	mysql> UPDATE `eav_entity_store` SET `increment_last_id` = '200000001', `increment_prefix` = '2' WHERE `entity_type_id` = '6';

Da ich zu diesem Zeitpunkt nicht wusste, wie viele Bestellungen schon vorgenommen wurden, habe ich ausserdem increment_prefix auf 2 gesetzt, einfach um sicher zu gehen, dass es keine weiteren Konflikte gibt. Vermutlich hätte ich auch die Rechnungsnummer einfach auf 100001000 setzen können, denn so viele Bestellungen sind definitiv nicht eingegangen.

mysql> select * from eav_entity_store;
+-----------------+----------------+----------+------------------+-------------------+
| entity_store_id | entity_type_id | store_id | increment_prefix | increment_last_id |
+-----------------+----------------+----------+------------------+-------------------+
|               1 |              5 |        1 | 1                | 100000802         |
|               2 |              6 |        1 | 2                | 200000001         |
|               3 |              8 |        1 | 1                | 100000028         |
+-----------------+----------------+----------+------------------+-------------------+
3 rows in set (0.00 sec)

mysql> select * from eav_entity_store;

+-----------------+----------------+----------+------------------+-------------------+

+-----------------+----------------+----------+------------------+-------------------+

| 1 | 5 | 1 | 1 | 100000802 |

| 2 | 6 | 1 | 2 | 200000001 |

| 3 | 8 | 1 | 1 | 100000028 |

+-----------------+----------------+----------+------------------+-------------------+

3 rows in set (0.00 sec)

Wie auch immer, das Problem mit den PayPal Express Bezahlungen wurde damit gelöst und funktioniert auch zwei Wochen nach dem Change noch.

Template Variable Image und Media Sources

Neben der Standard Media Resource Filesystem habe ich für die Rolle Content Editor eine isolierte Media Resource Catalog erstellt, so dass Editoren keinen Zugriff auf die gesamte Dateistruktur von MODx haben, sondern nur auf das Verzeichnis data/catalog/*.

Heute habe ich eine neue Template Variable vom Typ Image für ein Portrait erstellt, um Bilddateien aus dem Verzeichnis data/catalog/* auswählen zu können, jedoch hatte ich keine Möglichkeit das Bild zu ändern oder ein neues auszuwählen.

Um das Problem zu lösen, habe ich die Template Variable als Administrator editiert, und im letzten Reiter Media Sources den Source geändert.

Nun habe ich Zugriff auf alle Dateien im Verzeichnis data/catalog/*.

Magento 2 – Installieren

In diesem Artikel erkläre ich Schritt für Schritt, wie du Magento 2 unter Ubuntu mit Hilfe von Git und Composer installieren kannst.

1. Systemvoraussetzungen

Zunächst musst du überprüfen ob auf deiner Entwicklungsumgebung mindestens Apache Version 2.2 oder höher verwendet wird.

$ apache2 -v
Server version: Apache/2.4.7 (Ubuntu)
Server built:   Oct 14 2015 14:18:49

$ apache2 -v

Server version: Apache/2.4.7 (Ubuntu)

Server built: Oct 14 2015 14:18:49

Du solltest ebenfalls mindestens PHP Version 5.5.x verwenden.

$ php -v
PHP 5.5.9-1ubuntu4.14 (cli) (built: Oct 28 2015 01:32:13) 
Copyright (c) 1997-2014 The PHP Group

$ php -v

PHP 5.5.9-1ubuntu4.14 (cli) (built: Oct 28 2015 01:32:13)

Magento 2 setzt zudem mindestens MySQL Version 5.6 voraus. Falls deine Version kleiner ist, wirst du im Magento 2 Installer Probleme haben.

$ mysql -u {root or another mysql user} -p
$ Enter password:
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 167
Server version: 5.5.46-0ubuntu0.14.04.2 (Ubuntu)

$ mysql -u {root or another mysql user} -p

$ Enter password:

Welcome to the MySQL monitor. Commands end with ; or \g.

Your MySQL connection id is 167

Server version: 5.5.46-0ubuntu0.14.04.2 (Ubuntu)

Informiere dich allenfalls selbst wie du dein System mit apt-get update und upgrade aktualisieren kannst.

2. Vorbereitungen

Für die Installation muss einiges vorbereitet werden.

2.1 Composer

Die Installation von Magento 2 wird mit Composer vorgenommen. Es vereinfacht den gesamten Installationsprozess um einiges und stellt sicher, dass am während oder am Ende keine Pakete fehlen. Falls du bisher noch nicht mit Composer gearbeitet hast, wirst du jetzt quasi dazu gezwungen damit anzufangen. Überprüfe kurz ob Composer korrekt installiert ist, bevor du zum nächsten Schritt übergehst.

$ composer --version
Composer version 1.0-dev (764de14b5eb2980ba9d479865b075ef3bf858600) 2016-01-07 14:56:48

1 2	$ composer --version Composer version 1.0-dev (764de14b5eb2980ba9d479865b075ef3bf858600) 2016-01-07 14:56:48

Falls Composer nicht installiert ist, kannst du dies mit apt-get nachholen.

$ apt-get install composer

1	$ apt-get install composer

2.2 Git

Für die nächsten Schritte als auch in Zukunft musst du mit Git arbeiten. Keine Sorge, falls du bisher noch nicht mit Git gearbeitet hast. Für die Magento 2 Installation must du nur einen Befehl ausführen, ohne Vorkenntnisse zu haben. Falls Git nicht installiert ist, kannst du dies mit apt-get install git nachholen.

Für einen Personal Access Token, den du später in die Datei auth.json einfügen musst, brauchst du zudem einen kostenlosen GitHub Account den du unter https://github.com/join erstellen kannst.

2.1.1 Personal Access Token

Einen Personal Access Token bei GitHub zu erstellen ist recht einfach. Gehe dazu einfach in den Bereich Settings deines Profils und öffne anschliessend den Tab Personal Access Tokens auf der linken Seite.

GitHub - Einstellungen aufrufen — GitHub – Einstellungen aufrufen

Dort klickst du auf den Link Generate a personal access token. Auf der nächsten Ansicht definierst du eine kurze Beschreibung ( z.b Magento 2 ) und erstellst den neuen Token mit den vorausgewählten Scopes.

GitHub - Neuen Token erstellen und Scopes auswählen — GitHub – Neuen Token erstellen und Scopes auswählen

Auf der nachfolgenden Seite wird dir der Token nur einmal angezeigt. Diesen musst du also kopieren und sicher aufbewahren.

GitHub - Neuen Token jetzt kopieren — GitHub – Neuen Token jetzt kopieren

2.2 Magento Connect

Du brauchst zudem einen kostenlosen Account auf Magento Connect um dort einen Sicherheitsschlüssel für die Magento 2 Installation zu generieren. Das ganze hört sich komplizierter an als es tatsächlich ist.

Log dich auf Magento Connect ein.
Klicke auf My Account oben rechts.
Auf der linken Seite öffne den Tab Developers.
Klicke auf den Link Secure Keys.
Erstelle einen neuen Key und verwende als Name zum Beispiel den Namen deines Kunden.
Dort wo vorher ” There are no Secure Keys … ” zu sehen war solltest du nun einen Public Key und einen Private Key sehen.

Magento Connect - Neuen Secure Key erstellen — Magento Connect – Neuen Secure Key erstellen

2.3 Benutzer und Berechtigungen

Hin und wieder passiert es, dass Dateien für die Konfiguration ( z.b Auth.json, local.xml oder andere Dateien ) mit dem User root kopiert oder entpackt werden, der Webserver welcher mit dem User apache oder www-data läuft, darauf jedoch keinen Zugriff hat. Das Resultat ist oft ein Installationsprozess welcher mittendrin mit einer Exception abbricht. Um solche Probleme hier zu vermeiden, erstellst du einen neuen SSH Account und verknüpfst diesen mit der Gruppe vom Apache.

2.3.1 Benutzer erstellen

Log dich zunächst mit SSH auf deine Entwicklungsumgebung ein. Entweder mit root oder einem anderen Benutzer der dir erlaubt mit super-user rechten zu arbeiten.

$ ssh username@hostname
username@hostname's password:

1 2	$ ssh username@hostname username@hostname's password:

Nun erstellst du den neuen Benutzer. In diesem Fall passt magento_user ganz gut.

$ adduser magento_user
Adding user `magento_user' ...
Adding new group `magento_user' (1001) ...
Adding new user `magento_user' (1001) with group `magento_user' ...
Creating home directory `/home/magento_user' ...
Copying files from `/etc/skel' ...

$ adduser magento_user

Adding user `magento_user' ...

Adding new group `magento_user' (1001) ...

Adding new user `magento_user' (1001) with group `magento_user' ...

Creating home directory `/home/magento_user' ...

Copying files from `/etc/skel' ...

Du wirst im Anschluss aufgefordert ein Passwort für diesen Benutzer zu erstellen. Für die Entwicklungsumgebung genügt ein einfaches Passwort.

Enter new UNIX password: 
Retype new UNIX password: 
passwd: password updated successfully
Changing the user information for magento_user
Enter the new value, or press ENTER for the default
	Full Name []: Tobias Forkel
	Room Number []: 
	Work Phone []: 
	Home Phone []: 
	Other []: 
Is the information correct? [Y/n] y

Enter new UNIX password:

Retype new UNIX password:

passwd: password updated successfully

Changing the user information for magento_user

Enter the new value, or press ENTER for the default

Full Name []: Tobias Forkel

Room Number []:

Work Phone []:

Home Phone []:

Other []:

Is the information correct? [Y/n] y

Jetzt musst du den neuen Benutzer magento_user in die Gruppe hinzufügen, welche von Apache verwendet wird. In den meisten Fällen ist es www-data, was aber je nach Linux Distribution anders sein kann.

$ ps axo user,group,comm | egrep '(apache|httpd)'
www-data www-data apache2

1 2	$ ps axo user,group,comm \| egrep '(apache\|httpd)' www-data www-data apache2

Füge nun den Benutzer magento_user in die Gruppe von www-data hinzu.

$ usermod -g www-data magento_user

1	$ usermod -g www-data magento_user

Überprüfe anschliessend ob die Gruppeneinstellungen für den Benutzer magento_user korrekt übernommen wurden.

$ groups magento_user
magento_user : www-data

1 2	$ groups magento_user magento_user : www-data

Zum Schluss musst du den Webserver einmal neu starten.

$ service apache2 restart
* Restarting web server apache2

1 2	$ service apache2 restart * Restarting web server apache2

Du kannst dich nun als magento_user einloggen und mit den nächsten Schritten weiterfahren.

$ su magento_user
Password:

1 2	$ su magento_user Password:

2.4 Dateisystem

Wenn wir gerade beim Thema Berechtigung sind, kannst du gleich die Berechtigungen für Dateien und Verzeichnisse korrekt setzen. Zuerst setzt du die Gruppe www-data.

$ cd /var/www/html/{VirtualHost}/
$ chown -R :www-data .

1 2	$ cd /var/www/html/{VirtualHost}/ $ chown -R :www-data .

Nun kannst du im gleichen Verzeichnis die Berechtigungen setzen. Verzeichnisse benötigen volle Berechtigung ( 770 ) ausschliesslich für den Besitzer. Für Dateien gilt, Lese und Schreibberechtigung für den Besitzer und die Gruppe, und keine Berechtigung für andere.

$ find . -type d -exec chmod 770 {} \; && find . -type f -exec chmod 660 {} \; && chmod u+x bin/magento

1	$ find . -type d -exec chmod 770 {} \; && find . -type f -exec chmod 660 {} \; && chmod u+x bin/magento

2.5 Auth.json

Einloggt als magento_user erstellst du nun die Datei auth.json im Home Verzeichnis.

$ mkdir ~/.composer/
$ nano ~/.composer/auth.json

1 2	$ mkdir ~/.composer/ $ nano ~/.composer/auth.json

In der Datei auth.json fügst du folgende JSON Konfiguration ein.

{
   "github-oauth": {
     "github.com": "{GITHUB_PERSONAL_ACCESS_TOKEN}"
   },
   "http-basic": {
      "repo.magento.com": {
         "username": "{MAGENTO_CONNECT_PUBLIC_KEY}",
         "password": "{MAGENTO_CONNECT_PRIVATE_KEY}"
      }
   }
}

{

"github-oauth": {

"github.com": "{GITHUB_PERSONAL_ACCESS_TOKEN}"

"http-basic": {

"repo.magento.com": {

"username": "{MAGENTO_CONNECT_PUBLIC_KEY}",

"password": "{MAGENTO_CONNECT_PRIVATE_KEY}"

}

3. Installation durchführen

Gehe nun in dein Hauptverzeichnis, für das ein VirtualHost existiert und welches über den Browser aufrufbar ist.

$ cd /var/www/html/

1	$ cd /var/www/html/

3.1 Source klonen

Starte git clone und warte bis der Source fertig geladen ist.

$ git clone -b 2.0 https://github.com/magento/magento2.git ./{VirtualHost}/
Cloning into './{VirtualHost}/'...
remote: Counting objects: 937933, done.
remote: Compressing objects: 100% (3505/3505), done.
remote: Total 937933 (delta 2255), reused 0 (delta 0), pack-reused 933736
Receiving objects: 100% (937933/937933), 246.94 MiB | 487.00 KiB/s, done.
Resolving deltas: 100% (525819/525819), done.
Checking connectivity... done.
Checking out files: 100% (22910/22910), done.

$ git clone -b 2.0 https://github.com/magento/magento2.git ./{VirtualHost}/

Cloning into './{VirtualHost}/'...

remote: Counting objects: 937933, done.

remote: Compressing objects: 100% (3505/3505), done.

remote: Total 937933 (delta 2255), reused 0 (delta 0), pack-reused 933736

Receiving objects: 100% (937933/937933), 246.94 MiB | 487.00 KiB/s, done.

Resolving deltas: 100% (525819/525819), done.

Checking connectivity... done.

Checking out files: 100% (22910/22910), done.

In meinem Beispiel verwende ich -b 2.0 um den Source aus dem Release Branch zu kopieren. Ohne -b 2.0 wird der Source vom Develop Branch heruntergeladen welcher evt. noch untested Code enthält.

3.2 Installation starten

Nun kannst du mit der Installation beginnen. Bitte stelle sicher, dass du weiterhin als magento_user eingeloggt bist um Berechtigungsprobleme zu vermeiden.

$ cd /var/www/html/{VirtualHost}/ && composer install

1	$ cd /var/www/html/{VirtualHost}/ && composer install

Composer wird Anhand der von Magento 2 mitgelieferten Datei composer.json diverse Abhängigkeiten überprüfen und gegebenenfalls die Installation mit detaillierten Fehlermeldungen abbrechen. Es lohnt zudem einen Blick in die Datei composer.json zu werfen um zu verstehen, was wahrend der Installation passiert.

Hier ein Beispiel für eine Fehlermeldung.

Loading composer repositories with package information
Installing dependencies (including require-dev) from lock file
Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - The requested PHP extension ext-intl * is missing from your system. Install or enable PHP's intl extension.
  Problem 2
    - The requested PHP extension ext-xsl * is missing from your system. Install or enable PHP's xsl extension.

Loading composer repositories with package information

Installing dependencies (including require-dev) from lock file

Your requirements could not be resolved to an installable set of packages.

Problem 1

- The requested PHP extension ext-intl * is missing from your system. Install or enable PHP's intl extension.

Problem 2

- The requested PHP extension ext-xsl * is missing from your system. Install or enable PHP's xsl extension.

Je nach Server Setup kann es also sein, dass diverse PHP Erweiterungen manuell nachinstalliert werden müssen. Sind alle Abhängigkeiten auf dem Server installiert, kann die Installation mit dem Composer wiederholt werden. Die Installation sollte mit Generating autoload_files Erfolgreich enden.

$ composer install
magento_user@hostname:/var/www/html/{VirtualHost}/$ composer install

Loading composer repositories with package information
Installing dependencies (including require-dev) from lock file
  - Installing magento/magento-composer-installer (0.1.5)
    Downloading: 100%         

  - Installing braintree/braintree_php (2.39.0)
    Downloading: 100%         

  - Installing justinrainbow/json-schema (1.5.0)
    Downloading: 100%         

  - Installing symfony/console (v2.6.11)
    Downloading: 100%

..........

phpunit/php-code-coverage suggests installing ext-xdebug (>=2.2.1)
phpunit/phpunit suggests installing phpunit/php-invoker (~1.1)
sjparkinson/static-review suggests installing sensiolabs/security-checker (Required for ComposerSecurityReview.)
Generating autoload files
magento_user@hostname:/var/www/html/{VirtualHost}/$

$ composer install

magento_user@hostname:/var/www/html/{VirtualHost}/$ composer install

Loading composer repositories with package information

Installing dependencies (including require-dev) from lock file

- Installing magento/magento-composer-installer (0.1.5)

Downloading: 100%

- Installing braintree/braintree_php (2.39.0)

Downloading: 100%

- Installing justinrainbow/json-schema (1.5.0)

Downloading: 100%

- Installing symfony/console (v2.6.11)

Downloading: 100%

..........

phpunit/php-code-coverage suggests installing ext-xdebug (>=2.2.1)

phpunit/phpunit suggests installing phpunit/php-invoker (~1.1)

sjparkinson/static-review suggests installing sensiolabs/security-checker (Required for ComposerSecurityReview.)

Generating autoload files

magento_user@hostname:/var/www/html/{VirtualHost}/$

3.3 Setup starten

Um mit dem Setup zu beginnen, musst du nun die URL in deinem Browser aufrufen welche im VirtualHost definiert ist. Du solltest folgenden Screen sehen. Klicke auf Agree and Setup Magento um mit dem Installer fortzufahren.

3.3.1 Installer

Im Magento 2 Installer wird unter anderem die Datenbank hinzugefügt, sowie einige Standard Konfigurationen vorgenommen.

3.3.2 Readiness Check

Mit dem Readiness Check überprüft Magento 2 nochmals ob alle nötigen Erweiterungen installiert sind. Du solltest nur fortfahren wenn der Readiness Check erfolgreich ist.

Magento 2 - Installer Readiness Check — Magento 2 – Installer Readiness Check

3.3.3 Add Database

Falls du für deinen VirtualHost noch keine Datenbank erstellt hast, kannst du dies hier kurz nachholen.

$ mysql -u root -p
Enter password: 
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 119
Server version: 5.5.46-0ubuntu0.14.04.2 (Ubuntu)

$ mysql -u root -p

Enter password:

Welcome to the MySQL monitor. Commands end with ; or \g.

Your MySQL connection id is 119

Server version: 5.5.46-0ubuntu0.14.04.2 (Ubuntu)

Im folgendem Beispiel erstelle ich nur einen neuen Benutzer mit allen Berechtigungen sowie eine Date

mysql> CREATE USER 'username'@'localhost' IDENTIFIED BY 'password';
Query OK, 0 rows affected (0.01 sec)

mysql> GRANT ALL PRIVILEGES ON *.* TO 'username'@'localhost';
Query OK, 0 rows affected (0.00 sec)

mysql> FLUSH PRIVILEGES;
Query OK, 0 rows affected (0.00 sec)

mysql> create database username;
Query OK, 1 row affected (0.00 sec)

mysql> CREATE USER 'username'@'localhost' IDENTIFIED BY 'password';

Query OK, 0 rows affected (0.01 sec)

mysql> GRANT ALL PRIVILEGES ON *.* TO 'username'@'localhost';

Query OK, 0 rows affected (0.00 sec)

mysql> FLUSH PRIVILEGES;

Query OK, 0 rows affected (0.00 sec)

mysql> create database username;

Query OK, 1 row affected (0.00 sec)

Anschliessend kannst du den neuen Benutzer

Magento 2 - Installer - Add Database — Magento 2 – Installer – Add Database

3.3.4 Web Configuration

In diesem Schritt wird die BaseURL sowie der Pfad zum Admin Panel festgelegt.

3.3.5 Customize Your Store

Hier kannst du die Standard Zeitzone, Währung sowie Sprache festlegen. Falls du dir nicht sicher bist, kannst du einfach fortfahren und die Anpassungen später vornehmen.

3.3.6 Create Admin Account

Erstelle einen Admin Account und stelle sicher, dass du das Passwort in Zukunft auch nicht vergisst.

3.3.6 Install

You’re ready! Super, du kannst nun mit der Installation fortfahren. Warte bitte bis die Installation abgeschlossen ist. Wird die Installation erfolgreich abgeschlossen, bekommst du im Anschluss eine Zusammenfassung. Dieses solltest du dir wenn möglich als PDF drucken, oder zumindest solltest du den Encryption Key sicher ablegen.

Magento 2 - Installer - Success — Magento 2 – Installer – Success

Fehlermeldungen, Verbesserungsvorschläge und Kritik bitte unten als Kommentar.

Magento und max_input_vars

Es gibt Tage als Magento Entwickler bei denen man einfach nur verzweifelt, und zwar dann, wenn man komplexe Produkte oder Kategorien erstellen möchte. In den letzten zwei Wochen habe ich mich gleich mit zwei solchen Problemen beschäftigt, bei denen leider keine Fehlermeldung (system.log, exception.log etc.) zu sehen war welche zumindest ein bisschen weiterhelfen würde. Konkret geht es um die Standardeinstellung in der php.ini.

; How many GET/POST/COOKIE input variables may be accepted
; max_input_vars = 1000

1 2	; How many GET/POST/COOKIE input variables may be accepted ; max_input_vars = 1000

Diese Standardeinstellung führt dazu, dass komplexe Formulare im Admin Panel zwar Erfolgreich abgeschickt werden können, jedoch nicht alles vom Server akzeptiert wird. Will man also Kategorien mit mehr als 1000 Produkten speichern oder 100 bis 150 Bundle Items zu einem Bundle Produkt hinzufügen, gibt es hier möglicherweise Probleme.

Das Problem kann gelöst werden indem man den Wert für max_input_vars in der php.ini oder in der .htaccess auf 2000 oder mehr erhöht, aber nicht unbedingt mehr als benötigt.

<IfModule mod_php5.c>
    php_value max_input_vars 5000
</IfModule>

php_value max_input_vars 5000

</IfModule>

Das ganze kann man mit LocationMatch auf das Admin Panel beschränken.

<LocationMatch "(index\.php/)?admin/">
    <IfModule mod_php5.c>
        php_value max_input_vars 5000
    </IfModule>
</LocationMatch>

php_value max_input_vars 5000

</IfModule>

</LocationMatch>

Malware in Bilddateien finden

Es ist ein Alptraum. Die Liveumgebung deines Kunden wurde gehackt und du weisst nicht, wie genau und welche Daten gestolen wurden. Schnell muss also untersucht werden, wo die Schwachstelle liegt um solche Angriffe in Zukunft besser abzufangen. Natürlich gibt es verschiedene Wege sich Zugang zu einer Liveumgebung zu verschaffen. In diesem Post möchte ich nur kurz darauf eingehen, wie mittels Bilddateien beliebiger Code eingeschleust werden kann.

Wie auf Snapfast und Sucuri beschrieben, kann beliebiger Code in EXIF von Bilddateien untergebracht werden. Oft genügt schon ein einfaches Script um einen neuen Administrator account zu erstellen. Alles weitere passiert dann im Hintergrund, oft unerkannt.

Leider hilft ein svn status oder git status nicht um geänderte Dateien zu erkennen, denn oft sind Verzeichnisse wie /media/ nicht versioniert.

Hier ein einfacher Befehl wie du solche Bilddateien mit “find” aufspüren kannst.

$ cd /var/www/{{{MAGENTO}}}/
$ find . -iregex '.*\.\(jpg\|gif\)' -exec grep -o -P 'base64_decode' {} \;

1 2	$ cd /var/www/{{{MAGENTO}}}/ $ find . -iregex '.*\.$jpg\\|gif$' -exec grep -o -P 'base64_decode' {} \;

Sollten Dateien auf dem Produktivsystem infiziert sein, bekommst du folgendes Suchergebnis.

Binary file ./media/test.jpg matches

1	Binary file ./media/test.jpg matches

5 praktische Beispiel für die tägliche Arbeit mit Magento

1. Sicherung von media/catalog

So erstellst du eine Sicherung von media/catalog ohne dem /cache/ Verzeichnis.

$ cd /var/www/{{{MAGENTO}}}/media/
$ tar -czf ~/catalog.tar.gz catalog --exclude 'catalog/product/cache/*'

1 2	$ cd /var/www/{{{MAGENTO}}}/media/ $ tar -czf ~/catalog.tar.gz catalog --exclude 'catalog/product/cache/*'

Das gleiche mit dem aktuellen Datum im Dateinamen.

$ tar -czf ~/"catalog_$(date '+%Y%m%d').tar.gz" catalog --exclude 'catalog/product/cache/*'

1	$ tar -czf ~/"catalog_$(date '+%Y%m%d').tar.gz" catalog --exclude 'catalog/product/cache/*'

2. Dateien ohne Berechtigungen für Apache

So findest du Dateien welche nicht die nötigen Berechtigungen für Apache besitzen. Das macht Sinn wenn du Berechtigungsprobleme früh erkennen möchtest. Zum Beispiel Schreib- oder Leseberechtigungen bei Dateien oder Verzeichnissen für diverse Upload Funktionen.

$ cd /var/www/{{{MAGENTO}}}/
$ find . \! -group www-data \! -user www-data

1 2	$ cd /var/www/{{{MAGENTO}}}/ $ find . \! -group www-data \! -user www-data

3. SQL / CSV Dateien im Projektverzeichnis

Manchmal ist es keine gute Idee Datenbank Sicherungen oder andere exportierte Dateien mit sensiblen Informationen im Projektverzeichnis abzulegen. Je nach Sicherheitseinstellungen können solche Dateien von dritte heruntergeladen werden. Um mögliche Sicherungen auf dem Produktivsystem auffinden zu können, brauchst du nur ein einfachen ” find ” Befehl mit der Option ” iregex “.

$ cd /var/www/{{{MAGENTO}}}/
$ find -iregex '.*\.\(sql\|tar\|gz\|zip\|csv\)'

1 2	$ cd /var/www/{{{MAGENTO}}}/ $ find -iregex '.*\.$sql\\|tar\\|gz\\|zip\\|csv$'

4. Report Dateien der letzten 24 Stunden

$ cd /var/www/{{{MAGENTO}}}/var/report/
$ find . -type f -ctime -1

1 2	$ cd /var/www/{{{MAGENTO}}}/var/report/ $ find . -type f -ctime -1

Hier sind weitere Optionen fuer ” -ctime “.

# find files created greater than 24 hours ago
find . -type f -ctime +0

# find files created between now and 1 day ago
# (i.e., in the past 24 hours only)
find . -type f -ctime 0

# find files created less than 1 day ago
find . -type f -ctime -1

# find files created between 24 and 48 hours ago
find . -type f -ctime 1

# find files created more than 48 hours ago
find . -type f -ctime +1

# find files created greater than 24 hours ago

find . -type f -ctime +0

# find files created between now and 1 day ago

# (i.e., in the past 24 hours only)

find . -type f -ctime 0

# find files created less than 1 day ago

find . -type f -ctime -1

# find files created between 24 and 48 hours ago

find . -type f -ctime 1

# find files created more than 48 hours ago

find . -type f -ctime +1

5. Logdateien leeren

Schnell wachsende Logdateien wie system.log oder exception.log können eine Ursache für einen Serverausfall sein. Mit Hilfe von ” truncate ” kannst du log Dateien ohne Risiko auf deinem Produktivsystem leeren.

$ cd /var/www/{{{MAGENTO}}}/var/log
$ truncate -s 0 system.log

1 2	$ cd /var/www/{{{MAGENTO}}}/var/log $ truncate -s 0 system.log

Wenn du nicht alles entfernen möchtest, kannst du auch einen Teil für die Fehlersuche behalten.

$ truncate -s 10M system.log

1	$ truncate -s 10M system.log

Praktische Beispiele für deine Magento Logdatei Analyse

Verbessere deine wöchentliche Logdatei Analyse mit ein paar einfachen ” grep ” Befehlen. Verwende diese vor jedem Rollout um sicher zu gehen, dass dein Code einwandfrei funktioniert und keine Fehlermeldungen generiert. Um bei grösseren Logdateien die Übersicht zu behalten, kannst du mit ” tail ” die letzten 1000 Zeilen überprüfen, oder zunächst einfach mit ” wc -l ” schauen wie hoch die Anzahl an Fehlermeldungen überhaupt ist.

Zähle die Resultate mit ” wc -l ” am Ende.

$ grep -oi 'undefined index' system.log | wc -l

1	$ grep -oi 'undefined index' system.log \| wc -l

Zeige die letzten 1000 Zeilen von system.log mit ” tail -n 1000 ” an.

$ tail -n 1000 system.log | grep -i 'undefined index' system.log

1	$ tail -n 1000 system.log \| grep -i 'undefined index' system.log

1. System.log

1.1 Zugriffe auf ein Array mit einem Key welcher nicht existiert

$ grep -i 'undefined index' system.log

1	$ grep -i 'undefined index' system.log

1.2 Zugriff auf eine Variable welche nicht definiert ist

$ grep -i 'undefined variable' system.log

1	$ grep -i 'undefined variable' system.log

1.3 Debug Ausgaben mit Mage::log() generiert

$ grep -i 'debug' system.log

1	$ grep -i 'debug' system.log

1.4 Diverse fehlgeschlagene Versuche eine Datei oder ein Verzeichnis zu erstellen oder manipulieren

$ grep -i 'permission denied' system.log

1	$ grep -i 'permission denied' system.log

1.5 Falsch definierte oder nicht existierende Template Dateien

$ grep -i 'not valid template file' system.log

1	$ grep -i 'not valid template file' system.log

1.6 Fehler bei Zugriff auf ein Objekt

$ grep -i 'trying to get property of non-object' system.log

1	$ grep -i 'trying to get property of non-object' system.log

1.7 Parameter an eine Funktion nicht korrekt übergeben

$ grep -i 'missing argument' system.log

1	$ grep -i 'missing argument' system.log

1.8 Ungültige Variable an eine Schleife übergeben

$ grep -i 'invalid argument supplied' system.log

1	$ grep -i 'invalid argument supplied' system.log

Alles mit einmal finden:

$ cat system.log | egrep -i '(debug|notice: undefined|permission denied|not valid template file|trying to get property of non-object|missing argument)'

1	$ cat system.log \| egrep -i '(debug\|notice: undefined\|permission denied\|not valid template file\|trying to get property of non-object\|missing argument)'

2. Exception.log

2.1 Generelle Probleme mit XML Dateien

$ grep -i 'xml schema' exception.log

1	$ grep -i 'xml schema' exception.log

2.2 Spezifische Probleme mit dem Authorize.net Gateway

$ grep -i 'paygate.*gateway' exception.log

1	$ grep -i 'paygate.*gateway' exception.log

2.3 Spezifische Probleme mit dem PayPal Gateway

$ grep -i 'paypal.*gateway' exception.log

1	$ grep -i 'paypal.*gateway' exception.log

2.4 Generelle Probleme mit CURL

$ grep -i 'curl' exception.log

1	$ grep -i 'curl' exception.log

Alle mit einmal finden:

$ cat exception.log | egrep -i '(xml schema|paygate.*gateway|paypal.*gateway|curl)'

1	$ cat exception.log \| egrep -i '(xml schema\|paygate.gateway\|paypal.gateway\|curl)'

3. Reports

Report Dateien auf der Konsole zu überprüfen ist mühsam. Mit den folgenden Befehlen kannst du schnell die neusten 10 Reports mit einmal durchsuchen.

3.1 MySQL Verbindungen

$ ls -1t | head -10 | xargs grep -i 'mysql server' -sl

1	$ ls -1t \| head -10 \| xargs grep -i 'mysql server' -sl

3.2 Invalid config field

$ ls -1t | head -10 | xargs grep -i 'invalid config field' -sl

1	$ ls -1t \| head -10 \| xargs grep -i 'invalid config field' -sl

3.3 Unable to read response

$ ls -1t | head -10 | xargs grep -i 'unable to read response' -sl

1	$ ls -1t \| head -10 \| xargs grep -i 'unable to read response' -sl

3.4 External urls redirect

$ ls -1t | head -10 | xargs grep -i 'external urls redirect' -sl

1	$ ls -1t \| head -10 \| xargs grep -i 'external urls redirect' -sl

Alle mit einmal finden:

ls -1t | head -10 | xargs  egrep -i '(mysql server|invalid config field|unable to read response|external urls redirect)' -sl

1	ls -1t \| head -10 \| xargs egrep -i '(mysql server\|invalid config field\|unable to read response\|external urls redirect)' -sl

4. Apache error logs

4.1 Fehlende Dateien im Projektverzeichnis

$ tail -n 1000 /var/log/httpd/{virtualhost}-error_log | grep -i 'file does not exist'

1	$ tail -n 1000 /var/log/httpd/{virtualhost}-error_log \| grep -i 'file does not exist'

Geplante Tasks für Apache Benutzer einrichten

Geplante Tasks (Cron jobs) für PHP Applikationen sollten einem spezifischen Benutzer ohne root Berechtigungen zuordnet werden, also zum Beispiel www-data. So verhinderst du unter anderem, dass bei einem System Update die geplanten Tasks für root überschrieben werden.

1. Apache user suchen

Den Benutzer welcher von Apache verwendet wird, kannst du aus der Prozessliste entnehmen.

$ ps axo user,group,comm | egrep '(apache|httpd)'
root     root     apache2
www-data www-data apache2

$ ps axo user,group,comm | egrep '(apache|httpd)'

root root apache2

www-data www-data apache2

2. Tab editieren

Editiere den crontab mit der Option -u und dem Benutzer welcher von Apache verwendet wird. Dieser Befehlt erstellt eine Benutzerspezifische Datei in /var/spool/cron/crontabs/.

$ crontab -u www-data -e

1	$ crontab -u www-data -e

Füge deinen Cronjob ein und speichere alle Änderungen mit CTRL-O.

# For example, you can run a backup of all your user accounts
# at 5 a.m every week with:
# 0 5 * * 1 tar -zcf /var/backups/home.tgz /home/
#
# For more information see the manual pages of crontab(5) and cron(8)
#
# m h  dom mon dow   command
*/5 * * * * /bin/sh /var/www/{{{magento}}}/cron.sh

# For example, you can run a backup of all your user accounts

# at 5 a.m every week with:

# 0 5 * * 1 tar -zcf /var/backups/home.tgz /home/

# For more information see the manual pages of crontab(5) and cron(8)

# m h dom mon dow command

*/5 * * * * /bin/sh /var/www/{{{magento}}}/cron.sh

3. Syslog überprüfen

Anschliessend kannst du schauen ob dein Cronjob korrekt ausgeführt wird.

$ grep CRON.*\(www-data\) /var/log/syslog

1	$ grep CRON.*$www-data$ /var/log/syslog