First of all, let’s check prerequisites: besides general Magento requirements, there is one more thing you should be aware of. X.Commerce Fabric transfers data in AVRO format, so client extension uses php library provided by Apache to encode and decode messages. However, it performs 64-bit operations, so if you get errors from avro library during this tutorial, you may need to install GNU Multiple Precision (GMP) Arithmetic Library for PHP to get it working. You may obtain the latest version of library from ... mehr zu Working with X.commerce]]> In this series of blog posts, we will build a sample Magento module and configure it to communicate with another Magento instance through X.Commerce Fabric. As you may already know, there is an X.Commerce Integration Pack available on both Github and Magento Connect, and we will use it in our implementation. This post is dedicated to setting up the communication between local Magento instance and the X.Commerce Fabric.

First of all, let’s check prerequisites: besides general Magento requirements, there is one more thing you should be aware of. X.Commerce Fabric transfers data in AVRO format, so client extension uses php library provided by Apache to encode and decode messages. However, it performs 64-bit operations, so if you get errors from avro library during this tutorial, you may need to install GNU Multiple Precision (GMP) Arithmetic Library for PHP to get it working. You may obtain the latest version of library from http://gmplib.org. Please note that you have to compile PHP with GMP support by using the –with-gmp option. For Windows, you have to use the VC9 build of PHP 5.3. Make sure that php_gmp extension is enabled in php.ini.

And check if your webserver supports SSL. If not, take care of generating the self-signed certificate and providing necessary configuration. You should be able to access secure urls in your magento installation.

Let’s start with clean Magento installation. Obtain the latest available version of X.Commerce Integration Pack from Github https://github.com/xcommerce/Integration-Pack-for-Magento (either clone the repo or download as zip package) and put the files into the root of your Magento directory. Log into backend and clear the cache if needed — as a result, there would be a ‘X.commerce authorization file isn’t loaded’ message in a notice bar.

To get use of X.Commerce advantages, you have to register at X.Commerce Developer’s Portal https://devportal.x.com/. For some weird reason, you have to use PayPal account to log in (surely you have already got one, though I doubt that you would be keen to share the password with another developer just to use the same test environment. Possibly it may be more convenient to register a new account that will be used solely for the development needs).

After logging in, proceed to Manage Sandbox section and navigate to Register Capability dialog https://devportal.x.com/xfabric/register_capabilities

Fill in company and capability names (you don’t have to fill Endpoint URL if you would like to run the magento instance from local environment), then click on Register Capability button.

Navigate to Manage Test Merchant section, then click on Create Test Merchants link.

Fill in required fields, and click the Add Merchant button.

Open My Capabilities section, select your capability and click the Onboard Merchant button. Select your test merchant from drop-down list and click the Test On-boarding button, then Authorize Capability and, finally, Finish button.

For some reason, Fabric Sandbox environment does not provide you with extension authorization file generator (this option is available for live environment only). So, in order to use the integration pack functionality, we have to obtain the auth file and then modify it with sandbox environment values. In your magento backend, navigate to System/Configuration/Fabric section and expand Fabric Registration tab. By clicking the Register button, you will be redirected to devportal. Type in anything for online store name field and click Generate Authorization File button. After that, the auth file will be downloaded. Open it and modify data according to the instructions (you will need to open the capability details page in Fabric Sandbox to get correct values):

capabilityId: 
Use numbers at the end of URL for capabilityId (for example, ’120702132643′ if url is https://devportal.x.com/xfabric/view_capability/PPX2VSLE7NXR4_120702132643)

capabilityName: 
Use string displayed next to Capability Name.

destinationId: 
Use string displayed next to Capability ID.

Authorisation params for “type”:”XFABRIC”


“bearerToken” – Use string displayed next to Fabric Credentials prepended with Bearer
 (You may need to substitute this value for local testing with token received from XBridge).

Authorisation params for “type”:”SELF”


”bearerToken” – Use string displayed next to Capability Credentials.

”tenantName” – Use string displayed next to Capability Name prepended with SELF-.

“tenantId” – Use string displayed next to Capability ID.

”tenantPseudonym” – seems like not affecting anything for now, use Capability Name for example.

Authorisation params for “type”:”TENANT”

bearerToken – Use string displayed next to Token: in Tenants List prepended with Bearer.

tenantName – Use string displayed next to Tenant Name in Tenants List.

tenantId – Use string displayed next to Tenant ID in Tenants List.

tenantPseudonym – seems like not affecting anything for now, use Tenant Name for example.
fabricUrl: 
Production and sanbox urls are listed on Fabric Endpoints section of Fabric Sandbox.
Use “https://api.sandbox.x.com/fabric” for sandbox (please note that you should use escaping character before slashes).

After applying changes, save the auth file. Navigate to System/Configuration/Fabric section in magento backend and expand the Fabric Authorization tab. Upload the modified auth file by selecting it from choose file dialog and then clicking on Save Config button. You will be able to see your capability name and fabric URL on the same page after reload. There is also the Test connection button, but it won’t connect to Fabric yet if you’re running magento on the local environment.

To effectively communicate with X.Commerce Fabric, the server running our Magento installation should be able to accept incoming messages. To solve this issue for local environment, we will use XBridge tool, which performs periodical checks for outgoing messages on the Fabric server, and re-routes them to the local endpoint.

To get XBridge, download X.Commerce developer package from https://www.x.com/sites/default/files/x_commerce_devpack.zip

Unpack the archive, then navigate to XBridge directory and edit xbridgeclient.settings file. Remove demo tokens and capability urls and add your own: for token use string displayed next to Capability Credentials without Bearer word, for capability url provide path to xfabric endpoint controller on your local magento instance, for example:


Token2=MLDhwZOpkKLvvwaxK+Iiod6hgsjXdG4+xJzBIAjs0vJur/wQ5+45ghjksa
TokenType=Bearer
TokenCapabilityUrl2=https\://magento.local/xfabric/endpoint/

Save the file and run XBridge client from command line:

java -jar xbridge-client-0.0.12-SNAPSHOT.jar

After that, you can try to test the connection from magento backend. In XBridge console you should be able to see next log message:

INFO: Local capability at https://magento.local/xfabric/endpoint/message/ping returned response code: 500

That means that XBridge client is not authorized to send the redirected message from XFabric to magento. Let’s fix this: reopen the xbridgeclient.settings file and check the ClientAuthorizationBearerToken parameter – this is the token that is being used by XBridge client app. Copy it, reopen capability auth file and substitute the bearerToken value in XFABRIC section with this one. Save auth file, and re-load it from magento backend.

Now we’re ready to test the communication between our local Magento installation and X.Commerce Fabric. Just navigate to System/Configuration/X.Commerce/Fabric section in admin backend, and hit the Test Connection button. Let’s check what happens next:

The XBridge console should now display successful responses:

INFO: Local capability at https://magento.local/xfabric/endpoint/message/ping returned response code: 200
INFO: Local capability at https://magento.local/xfabric/endpoint/message/pong returned response code: 200

Back to Magento backend, you’ll see the connection success message. You may also navigate to System/X.Commerce Fabric/Debug section to check the logged requests and responses in detailed form.

In our next publications we will review the functionality of Xcom_Chronicle module bundled within X.Commerce Integration Pack and will create our own module which would allow us to synchronize the products data between two magento instances.

Author: Eugene Varava

Share and Enjoy

Zusätzlich zu den üblichen Überwachungen (wie z.B. Load, RAM Verbrauch oder der Festplatten Auslastung), sollten auch alle laufenden Applikationen überwacht werden. Im Fall Magento oder generell eCommerce ist es essentiell wichtig, dass Dienste, wie z.B. Mail Versand aus dem Shop, funktionieren. Außerdem müssen auch in Magento alle Indexe aktuell sein und Caches sowie viele andere Funktionen (wie z.B. auch evtl. erstellten Reports) überwacht werden.

Dies sind wichtige Fragen welche, bei möglichen Problemen, vorab helfen können ... mehr zu Application Monitoring für Magento]]> Ist es sinnvoll seine Systeme zu überwachen? Ja, durch die Überwachung werden Fehler verschiedenster Art schneller erkannt und durch das Sammeln von Performance Daten können Informationen gewonnen werden, ob die Kapazitäten der bestehenden Systeme für aktuelle Anforderungen ausreichen oder skaliert werden müssen. Gerade z. B. bei neuen Werbeaktionen ist es wichtig, die Systeme und die Anforderungen vor der Aktion genau überprüfen zu können, um sicher zu stellen das es während der Werbeaktion zu keinen Performance Engpässen kommt.

Zusätzlich zu den üblichen Überwachungen (wie z.B. Load, RAM Verbrauch oder der Festplatten Auslastung), sollten auch alle laufenden Applikationen überwacht werden. Im Fall Magento oder generell eCommerce ist es essentiell wichtig, dass Dienste, wie z.B. Mail Versand aus dem Shop, funktionieren. Außerdem müssen auch in Magento alle Indexe aktuell sein und Caches sowie viele andere Funktionen (wie z.B. auch evtl. erstellten Reports) überwacht werden.

Dies sind wichtige Fragen welche, bei möglichen Problemen, vorab helfen können einen Fehler gezielt und zeitnah zu finden und zu beheben. Außerdem können so die Zeiten der evtl. nicht Erreichbarkeit oder Teilerreichbarkeit so gering wie möglich gehalten werden.

Mögliche Auswirkungen, wenn Applikationen Fehler melden:

• Magento Caches sind nicht aktiv: Performance Verlust, im Cache werden häufig gestellte Anfragen gespeichert. Anfragen, die aus dem Cache geantwortet werden können, werden von Magento selbst nicht bearbeitet. Anfragen ohne Cache dagegen, müssen ggf. von PHP und MySQL in Magento bearbeitet werden, was unter Umständen zu starken Performance Einbüßen führen kann.
• Magento Indexe sind nicht aktuell: Anzeige von ggf. falschen Preisen oder Lagerbeständen. Performance Verlust, da die Daten nicht aus den optimierten Index Tabellen bezogen werden können.
• Magento Reports werden generiert: Im Frontend werden Fehler angezeigt, Zahlungen können nicht durchgeführt werden oder der Shop ist nicht erreichbar.
• Magento Compiler ist nicht aktiv: Performance Verlust oder der Shop ist nicht erreichbar.
• E-Mails können nicht verschickt werden: Kunden und / oder Shop Betreiber erhalten keine Nachrichten über Zahlungs- oder Lieferstatus.

Magento bietet verschiedene Skripte im “shell”-Verzeichnis im Magento Root zur Überprüfung der Standardfunktionen von Magento, wie die Indexe und den Compiler. Mithilfe von diesen Skripten kann der aktuelle Status über alle wichtige Funktionalitäten in Magento manuell bzw. über Shell abgefragt werden. Um die Statusabfragen auch innerhalb eines Monitorung Tools, wie z.B. Nagios, Icinga oder Zabbix, nutzen zu können, kann noch ein zusätzliches Skript (Wrapper-Skript) als Wrapper um Magento eigene Skripte erstellt werden. Dieses Wrapper-Skript analysiert die Ausgabe des Magento-Skripts und gibt diese Information nach eigenen Wünschen gefiltert und formatiert weiter. Alternativ kann auch ein eigenes Skript erstellt werden, welches sich mit Magento direkt ohne Umweg, über Magento eigene Status Skripte, verbindet, und so gewünschte Informationen liefert. So kann man die Magento eigene Funktionalität erweitern, denn die Standard Skripte liefern nicht immer alle notwendige Informationen, z.B. wird bei dem Indexer-Skript nicht ausgegeben wie lange ein Status bereits aktiv ist, wodurch man nicht erkennen kann, ob ein index rebuild möglicherweise Fehlgeschlagen ist oder Aufgrund seiner Dauer ein anderer Fehler besteht.

Share and Enjoy

In der IT wird anstelle eines Stresstests auch oft von einem Lasttest gesprochen. Ein solcher Test ist jedoch nicht gleichzusetzen mit einem Performancetest, da die gewonnenen Informationen über andere Dinge Auskunft geben sollen:

Mit den Ergebnissen können dann weitere Entscheidungen gefällt werden ob weitere Optimierungen notwendig sind. Da kleine Probleme bekanntermaßen unter hoher Last zu schwerere werden, können diese besser bei einem Lasttest ... mehr zu Stresstests in der Praxis]]> Heute finden Stresstests in vielen Bereichen wie z.B. bei Banken oder Atomkraftwerke Einsatz. Situationen werden simuliert um Grenzen zu ermitteln und darauf hin Schlussfolgerungen erzielen zu können.

In der IT wird anstelle eines Stresstests auch oft von einem Lasttest gesprochen. Ein solcher Test ist jedoch nicht gleichzusetzen mit einem Performancetest, da die gewonnenen Informationen über andere Dinge Auskunft geben sollen:

• Lässt sich der Shop bzw. die Webanwendung noch betreiben?
• Wie viele Web-, Datenbank- oder Cacheserver werden benötigt?
• Kommt es zu abstürzen von Diensten oder ganze Systeme?
• Können Dienste während hoher Last noch administriert werden?
• Treten Fehlermeldungen, Dateninkonsistenzen oder Deadlocks auf?
• Wie viel Zeit wird benötigt bis die Umgebung wieder in den Normalbetrieb übergeht?
• Greifen Schutzmaßnahmen?
• Kommt es zu einer automatischen Skalierung der Umgebung?
• Wurden alle Dienste optimal konfiguriert?
• Werden Failover-Maßnahmen erfolgreich durchgeführt?

Mit den Ergebnissen können dann weitere Entscheidungen gefällt werden ob weitere Optimierungen notwendig sind. Da kleine Probleme bekanntermaßen unter hoher Last zu schwerere werden, können diese besser bei einem Lasttest aufgespürt und dann auch behoben werden.

Wir führen bei unseren Projekten mindestens nach jeder Iteration automatische Lasttests durch. So vergleichen wir jeweils die Ergebnisse zu den vorherigen und können bei einer Verschlechterung sofort eingreifen.

Für verschiedene Protokolle gibt es zahlreiche freie und kommerzielle Tools für die Realisierung von Lasttests. Für eine Webanwendung eignet sich hier besonders “Siege” und unterstützt Authentifizierung, Cookies, URL-Files sowie das HTTP- und HTTPS-Protokoll.

Da einzelne Anfragen von unterschiedlichen Caches zwischengespeichert werden können, sollte ein Lasttest immer verschiedene URLs aufrufen und niemals ein und dieselbe. Um eine solche Liste zu generieren, eignen sich besonders Webserver-Logdateien. Aus diesen kann eine URL-Liste erstellt werden. Dies kann u.a. wie folgt gemacht werden:

awk '{print "http://my-domain.tld"$7}' /var/log/apache2/access.log |tee url.txt

Nun befinden sich in der soeben erstellten Datei „url.txt“ eine Liste mit Domains und übergeben diese Siege beim starten. Neben der URL-Liste übergeben wir auch noch weitere Optionen um z.B. die Anzahl der gleichzeitigen simulierten Benutzer zu setzen oder auch die Dauer des Lasttests festzulegen. Der folgende Befehl startet einen 10-sekündigen Test, der versucht 50 gleichzeitige Benutzer zu simulieren.

siege -b -c 50 -t 10S -f url.txt

Siege gibt nach dem Beenden Informationen aus die Auswertung mit berücksichtigt werden sollten.

** SIEGE 2.67
** Preparing 50 concurrent users for battle.
The server is now under siege...
Lifting the server siege..      done.
Transactions:		      156087 hits
Availability:		      100.00 %
Elapsed time:		        9.71 secs
Data transferred:	       24.71 MB
Response time:		        0.00 secs
Transaction rate:	    16074.87 trans/sec
Throughput:		        2.54 MB/sec
Concurrency:		       49.64
Successful transactions:           0
Failed transactions:	           0
Longest transaction:	        0.08
Shortest transaction:	        0.00

In unserem Fall haben konnten wir beim Lasttest feststellen, das die Infrastruktur automatisch horizontal skaliert wurde um die Last abzufangen.

Share and Enjoy

There are three factors in product development that remain in constant tension: cost, quality, and time.  For the sake of this discussion, quality shall mean the number of features a product is to have, and their depth, usability, and polish. The cost of a given project is usually computed by enumerating its features, and  the time it will take to implement them.  Likewise, the number of features and  their depth of quality and usability are limited by finances and time.  The amount of time a project will take is a direct result of the feature set, and the amount of  money the company is willing to spend.  Since ... mehr zu Magento performance testing via jmeter]]> What is the purpose of testing the shop performance during its development? Is it necessary? Why spending additional effort and costs on this? To what extent does it make sense? We will try to answer these and many other questions in this article.

There are three factors in product development that remain in constant tension: cost, quality, and time.  For the sake of this discussion, quality shall mean the number of features a product is to have, and their depth, usability, and polish. The cost of a given project is usually computed by enumerating its features, and  the time it will take to implement them.  Likewise, the number of features and  their depth of quality and usability are limited by finances and time.  The amount of time a project will take is a direct result of the feature set, and the amount of  money the company is willing to spend.  Since these factors have a direct relationship, when you attempt to adjust any one of them, the other two feel the effect. You can’t reduce the cost without sacrificing features or deadlines.  You can’t increase features without incurring extra costs and time spent.  You can’t reduce time to meet a market window without reducing features or increasing costs.

Everyone likes to control the cost factor because it is the easiest one to see the effect on bottom-line profitability.  Product features and time windows are less tangible and require work to make the connection.  Product features are most important to people closest to customers because solving their needs makes  them happy and results in good bonuses.

During development of Magento-based project, the project accumulates a lot of custom functionality, which has been developed according to customer wishes. Those functionalities can be developed or can be taken from Magento Connect. Very often it happens so, that during development more attention is payed to the final result and developers ask themselves very rarely how this new future will work under high load, with big amount of products in catalog or an increasing number of transactions. And as the result, when the project goes live with the full product catalog, it very often happens that the shop can’t work under high load, becomes very slow and in the worst case it can even go down. So agencies get the final product with  bad performance. Customer asks developers to solve those problems and they in their turn start a research of shop performance. This analysis can take a lot of time and what is most important, it can cause total rebuilding of some parts of the newly implemented features which will again cost time and money.

What do we have in this case?  Customer incurs a loss and loses own customers. Developers spent a lot of time for problem solving at their own cost, get bad feedback and can lose this customer for further cooperation.

How can we improve this situation? Performance while keeping the quality! The main idea is to implement a process of continous performance testing and improvement in every single agile iteration. What is needed are the right tools with the right configuration incorporated in the workflow, so that the performance and load tests become essentioal parts of every iteration, which can not be released unless the performance is not checked and guaranteed. We call it continuous performance tweaking.

What can we do for this?   We can add a bit more time to our development process, this would allow us to check quality of our product at different development phases. This extra time will be spent for automated performance testing of Magento performance.  This extra time will be planned for creation of all necessary information required for automated testing as well in every single iteration as well as for the test execution and potential tweaking.

How can we use information, that we obtain after the performance testing? In case when we get a worse result in the ongoing iteration compared with the previous one:

1. We will know about possible problems.
2. We can make a decision when and how we would fix the appeared issue.

Now it’s time to answer the following questions:

1. How we can do this.
2. What we can use for this.

How can we do this?

In our development process we use iteration based development. At the end of each iteration we provide a customer with a list of new futures, which have been implemented during the last iteration. At the end of each iteration we perform automated performance testing and get respective results. After analyzing the results we will know about the problem in advance. We will also have a list of developed features and as the result we will be able to easily find the problematic feature among them.

What we use for this.

For performance testing we use:

1. Separate performance infrastructure, which includes 1 web server for code base, 1 db server and 1 jmeter server.
2. Jmeter as the main tool for performing the test.
3. Git based project repository. As the additional information repo contains all necessary data for performance testing such as: schedule time, respective test plan, all necessary changes related with deployment. Test plan and time schedule should be updated in each iteration, all other information is created only once when we start the development process.
4. “Fabric” as our own deployment tool with our modifications, which allows us to use it for deployment to the internal development servers and to the performance servers.

So, at the end of iteration a team lead makes performance deployment and according to the time schedules jmeter server executes a respective testing plan and ultimately testing documents with respective results are created. Those documents are downloaded for later analysis y the team and potential tasks are generated for the next iteration. A project can have a few different test plans that can be executed one by one.

As always we give some sample. Our example will consist of the following points:

1. Required equipment.

JMeter requires a fully compliant JVM 1.5 or higher.

• Install JVM using a way your OS provides.
• Download from http://jmeter.apache.org/download_jmeter.cgi and unpack Jmeter to any location.
• Modify jmeter (jmeter.bat) script to set allowed amount of memory to be used by JVM.
• Search for HEAP variable.
• Set memory limit to at least 512m, e.g: -Xms512m -Xmx512m
• Check that JMeter works by launching it: jmeter -v

2. Test plan creation

Create a test plan using GUI version on your local computer. Check that your plan contains all listeners (result visualizers and interpreters) you want to use. How to for test plan creation here: http://jmeter.apache.org/usermanual/index.html

3. Testing phases.

For performance testing we use different scenarios.

• Performance without any caches
• Performance with cache system
• Separate test for different part of content:
  • Content only
  • Full page with media, css and js

For all those scenarios a separate test plan should be created. All those plans should be executed one by one. Why should we make so many plans and what are all those actions for? This way we can find and analyze bottlenecks in different parts of the generated content.

4. Result analyzes.

We will use the demo shop for our tests. The demo test has been developed during 1 week. During this time in default functionality the main following parts have been modified:

• Catalog view
• Product view

Other modifications do not matter for now.

In order to execute testing we will create and use two plans where we will test home page, category page, product details page, products compare functionality, customer account page, forgot password page, customer account login customer login post and a few cms pages. Our test plans should cover 2 following cases:

• Document only without any media and css data
• Document with all content loaded to the customer’s browser.

Testing scenario should be as follows:

• FPS turn off always
• First test should be performed on the clear magento enterprise 1.12 installation
• Second test should be performed at the end of development.

After collecting all results we can compare the performance of our shop before our modifications and after. The main idea is to include it in every iteration we deliver to immediately see whether a newly implemented feature affects the performance in a negative way or not and if so, to fix it. The constant performance is regarded as done-done creteria for user stories in our development and only an improved or constant performance is a success criteria acepted by our QA. Our results will be following:

Document only on the clear installation:

Document only after our modifications:

Document full on the clear installation:

Below we provide average values for each page.

After analyzing the average value for each page we can say that we stay almost on the same position as before we started our implementation. And that nothing bad happened during our last iteration. So we can move toward.

Share and Enjoy

The usual development process for the Magento platform requires a lot of common operations related with project development, module creation, creation of different models, helpers, blocks etc. from developers. Those actions take a lot of time useful in the every-day work and therefore increase the project costs and time-to-markets as key team members and developers do use it for this tasks instead of really value adding and contributing through new ideas, solving complex problems or consulting the customer. Sooner or later each developer, developing different functionalities for Magento starts thinking how he can improve his own work, how time for common operations can be reduced and how potential bugs can be avoided occuring when humans repeat the same, not so demanding tasks, multiple times with different levels of attention. (Magento) code-generators can be one potential answer and solution.

You can find ... mehr zu Magento code generator tools]]>

1. Module Creators
2. Magento Developer Utils
3. Usage of MageTool + Mtool
4. Providers and their actions
5. Summary

The usual development process for the Magento platform requires a lot of common operations related with project development, module creation, creation of different models, helpers, blocks etc. from developers. Those actions take a lot of time useful in the every-day work and therefore increase the project costs and time-to-markets as key team members and developers do use it for this tasks instead of really value adding and contributing through new ideas, solving complex problems or consulting the customer. Sooner or later each developer, developing different functionalities for Magento starts thinking how he can improve his own work, how time for common operations can be reduced and how potential bugs can be avoided occuring when humans repeat the same, not so demanding tasks, multiple times with different levels of attention. (Magento) code-generators can be one potential answer and solution.

You can find a lot of different tools related to code-generation, so the questions is always what metric and arguments to focus on while comparing these tools. We at Magento Gold Partner Symmetrics felt, the main problem is related with TIME, and how it can be saved in a useful and most efficient way. Thats why we decided to start our search and comparison with checking out, what is out there in the market and how it can be potentially utilised. We have our own Magento SDK, containing >14 products and service for rapid and high quality development, quality control, reusability, deployment and many more. Before creating our own code-generation instrument we compared different tools in order to understand whether they can be used as a starting point and how.

This article provides a first overview of such tools we have looked at during our research, a brief comparison of them and finally our choice of tools for our internal Magento development work and a quick guide how it can be used in daily tasks as well as some examples related with creation of simple modules with all necessary files.

Those tools, which we will describe in this article, provide us with lots of usable features related to shop management and new code-generation. Those tools allow us to reduce human errors, save time for development as well as error search caused by copy-past. As the result we can deliver developed projects to our customers faster and with less bugs and testing effort resulting in significant business value through a shorter time-to-market and less costs as well as an optimized TCO (total cost of ownership) later in the Maintanence&Support mode. It also allows customers to plan all actions related with a new project launch more precisely and keeps deadlines and goals even more reliable in Magento projects, attracts investments and contributes to successful business growth.

So let’s start. From the list of tools which we could find, we can define two categories, each of them contains a few tools.

Module Creators

In the provided table we can see that the first two tools (Mtool, MageTool) might be worthy of our attention. Those tools provide a lot of useful functionality and can be used from the command line. MageTool contains more functionality related with “Add new entities” and “Rewrites”, but dose not support migration management and auto file/class comments and required python for its work. What is very important for us is the code standard support (auto file/class comments), migration management and integration with ZF, which enables further scalability of the used tools more easily. Considering all this, our choice would be Mtool.

Magento Developer Utils

In the provided table we can see that the first two tools (MageTool, Wiz) might be worthy of our attention. As we can see Wiz offers even more functionality than MageTool. It also has a well-documented code, but does not have ZF integration. As mentioned before, ZF integration is very important for us, because we want to find the best tool from each category and want to be able to use them together and if possible use common command line syntax.

MageTool is a very powerful tool which facilitates a number of repetitive tasks during development. Rather than switching between mysql tools and the Magento admin system, finding the way to add a new user, you can just run a simple command and improve your work-flow greatly. Considering all this our choice would be MageTool.

As a result we chose Mtool and MageTool. Those tools are ZF based, and what is the most important – MageTool inherited MTool functionality so common command line syntax can be used.

In order to work with our new tools, we need Zend Framework, Mtool and MageTool. Installation process can be performed very easily according to corresponding documentation, links to which have been provided before.

Usage of MageTool + Mtool

You should navigate to project’s root directory before calling zf to let the tools generate correct folder structures and to access the existing config files.
zf [--global-opts] action-name [--action-opts] provider-name [--provider-opts] [provider parameters ...]
Note: You may use “?” in any place of the above usage string to ask for more specific help information.
Example: “zf ? version” will list all available actions for the version provider.

Providers and their actions

Version

zf show version mode[=mini] name-included[=1] 

Note: There are specialties, use zf show version.? to get specific help on them.

Config

zf create config
zf show config
zf enable config 

Note: There are specialties, use zf enable config.? to get specific help on them.

zf disable config 

Note: There are specialties, use zf disable config.? to get specific help on them.

Phpinfo

zf show phpinfo 

Manifest

zf show manifest 

Profile

zf show profile 

Project

zf create project path name-of-profile file-of-profile
zf show project

Note: There are specialties, use zf show project.? to get specific help on them.

Application

zf change application.class-name-prefix class-name-prefix 

Model

zf create model name module 

View

zf create view controller-name action-name-or-simple-name module 

Controller

zf create controller name index-action-included[=1] module 

Action

zf create action name controller-name[=Index] view-included[=1] module 

Module

zf create module name 

Form

zf enable form module
zf create form name module

Layout

zf enable layout
zf disable layout

DbAdapter

zf configure db-adapter dsn section-name[=production]

DbTable

zf create db-table name actual-table-name module force-overwrite

Note: There are specialties, use zf create db-table.? to get specific help on them.

ProjectProvider

zf create project-provider name actions

MageAdminUser

zf show mage-admin-user

MageCoreCache

zf clear mage-core-cache tags[=all]
zf flush mage-core-cache
zf enable mage-core-cache tags[=all]
zf disable mage-core-cache tags[=all]

MageCoreCompiler

zf run mage-core-compiler
zf clear mage-core-compiler
zf enable mage-core-compiler
zf disable mage-core-compiler
zf stat mage-core-compiler

MageCoreIndexer

zf info mage-core-indexer code[=all]
zf mode mage-core-indexer mode code[=all]
zf run mage-core-indexer code[=all]

MageCoreResource

zf show mage-core-resource code
zf delete mage-core-resource code
zf update mage-core-resource module

MageCoreConfig

zf show mage-core-config path scope
zf set mage-core-config path value scope
zf replace mage-core-config match value path scope
zf lint mage-core-config config-file-path[=app/code/local] lint-file-path

MageApp

zf version mage-app
zf dispatch-event mage-app name data

MageExtension

zf create mage-extension vendor name pool[=local] file-of-profile

mage-module

zf create mage-module name
zf install mage-module name version
zf upgrade mage-module name mode version

mage-model

zf create mage-model target-module model-path
zf add mage-model model-path
zf rewrite mage-model target-module origin-model your-model

mage-rmodel

zf rewrite mage-rmodel target-module origin-model your-model

mage-helper

zf create mage-helper target-module helper-path
zf add mage-helper helper-path
zf rewrite mage-helper target-module origin-helper your-helper

mage-block

zf create mage-block target-module block-path
zf add mage-block block-path
zf rewrite mage-block target-module origin-block your-block

The last topic of this article is an example, where we will create a simple Magento module using these tools with models, helpers, migrations, and some rewrites and where we will compare the average time needed for every single operation doing it with or without the code-generation tool. So let’s start and have fun

Our simple module will be called “Test”. This module will be created in the Symmetrics namespace and the local code pool.

Switch to your Magento shop document root.

1. Create a new module:

zf create mage-module Symmetrics/Test

In case of success, you will be able to see the message “Done”
Time for this action:

2. Add installation script:

zf install mage-module Symmetrics/Test 0.1.1

In case of success, you will be able to see the message “Done”
Time for this action:

3. Add upgrade script:

zf upgrade  mage-module Symmetrics/Test to 0.1.3

In case of success, you will be able to see the message “Done”
Time for this action:

4. Create model Info:

zf add mage-model Test/Info

For the first case the tool will prompt name space and module name. So type the following:

Symmetrics/Test

In case of success you will be able to see the the message “New model created under Symmetrics_Test module”
Time for this action:

During the next model creation, the tool will define everything automatically. So try to create a new model Message:

zf add mage-model Test/Message

In case of success you will be able to see the message “New model created under Symmetrics_Test module”
Time for this action:

5. Create helper Data:

zf add mage-helper Test/Data

For the first case the tool will prompt name space and module name. So type the following:

Symmetrics/Test

In case of success you will be able to see the the message “New helper created under Symmetrics_Test module”
Time for this action:

During the next helper creation the tool will define everything automatically. So try to create a new helper Message:

zf add mage-helper Test/Message

In case of success you will be able to see the message “New helper created under Symmetrics_Test module”
Time for this action:

6. Create block Info:

zf add mage-block Test/Info

For the first case the tool will prompt name space and module name. So type the following:

Symmetrics/Test

In case of success you will be able to see the message “New block created under Symmetrics_Test module”
Time for this action:

During the next block creation tool will define everything automatically. So try to create a new block Message:

zf add mage-block Test/Message

In case of success you will be able to see the message “New block created under Symmetrics_Test module”
Time for this action:

7. Rewrite core catalog_product model:

zf rewrite mage-model Symmetrics/Test catalog/product catalog_product

Time for this action:

8. Rewrite core customer_data helper:

zf rewrite mage-helper Symmetrics/Test customer/data customer_data

Time for this action:

9. Rewrite core catalog_product_view block:

zf rewrite mage-block Symmetrics/Test catalog/product_view catalog_product_view

Time for this action:

Summary

In this example we created a simple module “Test” which contains:

• 11 php files with correct file/class comments and ready for logic implementation
• 2 xml files with correct comments
• 11 directories

For all those actions we spent about 1 min using our Magento code-generation tool and this is much faster than performing all those actions manually. As you can see, the manual execution of all those action would have taken about 57 min. It should be noted however, that time for manual implementation can be different and depends on the qualification and skill level of the developer, however, the difference in the two ways of solving the same problem is obvious..

Our experience shows that the usage of such tools is justified in the followig cases:

1. For a new module creation and supporting of modules which have been written using general code standards.
2. For usage by developers with big experience in Magento development.

We strongly do not recommended to use such tools:

1. For developers who are beginners in Magento development, because when taking this way such developers wont learn or extend their knowledge in Magento development.
2. For support of modules that have been developed by third parties.

It is up to you to start using those or similar tools in your daily work or not. We made our choice and now use those tools very actively. We shared the first and basic steps of starting the usage of code-generation tools. Of course, a potential speed up is not only a question of tools but mostly of the processes and overall workflows as well as controlling, testing and qa procedures you have in place. In different setups and team constellations the speed up can be higher or lower. We usually avoid providing this tool to new team members or junior developers as well as Magento unexperienced developers. We first want to teach them the “real development” and understanding of Magento and the architecture and ways of solving problems before providing them tools to optimize or automatize their workflows (optimizations they often have not thought about before as they did not have many problems such tools help to solve). But again, what we described are the basic tools everyone can download, setup, configure and start using. Within our Magento SDK we significantly modified and extended the basic functionality of those tools that we use in our daily work, in order to achieve an even higher boost and improvement and we keep evolving and developing them every day. Just to share an impression, the following new features have been added by us into our code generation:

• create/rewrite controller
• create/rewrite layout
• templates for migrations (create admin user, change config values, website/store management)
• add custom email templates
• grid generation
• add fields to quote/order
• acl configuration
• events listeners

Share and Enjoy

Nach Ethan Marcotte’s Ideologie, ist Responsive Design die Gestaltung der Website über flexible Weiten, um sie je nach Bildschirmgröße des Besuchers individuell anzupassen.

In der Praxis sieht das so aus, dass wenn ein Besucher mit FullHD Bildschirm auf eine Responsive Website kommt, kriegt er mehr auf einmal zu sehen, als ein Besucher mit nur 1024×768 Auflösung. Inhaltlich sind aber beide Seiten gleich. Schön zu sehen auf folgenden Seiten:

http://css-tricks.com/ http://www.smashingmagazine.com/

Seit längerem beschäftigen wie uns bei symmetrics mit Magento Responsive Design und arbeiten neben der theoretischen Grundlage aktiv an ersten Kundenprojekten und Magento Themes. In Magento sind Fluid Grids in einem bestehenden Shop unter hohem Zeitaufwand gegenüber statischem Grid umsetzbar. Beinah jegliche Weiten und Abstände müssen in Prozent angegeben werden. Intelligente Floatings sind u.U. neu zu erarbeiten. Gleiches gilt für Produktbilder und weitere andere Grafiken. All ... mehr zu Magento Responsive Design]]>

1. Fluid Grid
2. Statisches Grid
3. Breakpoints
4. Media Queries
5. lt IE9
6. Brauche ich Responsive Design in meinem Magento Shop?
7. Pros
8. Cons
9. symmetrics – Ihr Partner für Magento-Responsive Design

Fluid Grid

Nach Ethan Marcotte’s Ideologie, ist Responsive Design die Gestaltung der Website über flexible Weiten, um sie je nach Bildschirmgröße des Besuchers individuell anzupassen.

In der Praxis sieht das so aus, dass wenn ein Besucher mit FullHD Bildschirm auf eine Responsive Website kommt, kriegt er mehr auf einmal zu sehen, als ein Besucher mit nur 1024×768 Auflösung. Inhaltlich sind aber beide Seiten gleich. Schön zu sehen auf folgenden Seiten:

http://css-tricks.com/
http://www.smashingmagazine.com/

Seit längerem beschäftigen wie uns bei symmetrics mit Magento Responsive Design und arbeiten neben der theoretischen Grundlage aktiv an ersten Kundenprojekten und Magento Themes. In Magento sind Fluid Grids in einem bestehenden Shop unter hohem Zeitaufwand gegenüber statischem Grid umsetzbar. Beinah jegliche Weiten und Abstände müssen in Prozent angegeben werden. Intelligente Floatings sind u.U. neu zu erarbeiten. Gleiches gilt für Produktbilder und weitere andere Grafiken. All das müsste von Anfang an in einem Magento Projekt geplant werden oder in einem bestehenden Magento Template angepasst werden. Designvorlagen vorausgesetzt, denn man läuft Gefahr, dass sich das Erscheinungsbild des Shops mit flexiblen Weiten stärker verändert als mit festen Weiten. Plant man all das vor einem Projekt, fällt schnell der Begriff „Mobile First“ – die Erstellung einer Website beginnend mit dem nötigsten für einen Mobilen Shop, um den Kern zu erarbeiten und dann auf Desktopgröße hoch zu ziehen und mit Inhalten wie Upsells, Crosssells, Callouts und mehr zu füllen.

Statisches Grid

Wenn Sie gerade auf einem Desktoprechner unterwegs sind, ziehen Sie testweise einmal das Browserfenster zusammen und auseinander und sehen Sie, wie sich der Inhalt an die Weite des Fensters anpasst.  Eine weitere schöne Seite die das statische Grid veranschaulicht finden Sie unter http://framelessgrid.com/.

Die Vorteile von festen Weiten an bestimmten Breakpoints, Breakpoints werden im nächsten Abschnitt erklärt, sind daher in einen bestehenden Shop schneller und damit kostengünstiger umzusetzen. Das Design kann zu jedem Breakpoint festgelegt werden und man kann somit das Layout für jeden Step bestimmen. Das Design wirkt effizienter und bestimmender, denn während bei Fluid Grid der Inhalt prozentual gestaucht wird, reicht es auch oft aus einfach nur die font-size und die Weite einiger Elemente zu verringern.

Probleme kann es geben, wenn man die Seite speziell auf Mobile Devices anpassen will. Die feste Größe kann hier aufgrund der verschiedensten Auflösungen mehr Anpassungen benötigen. Ein Fluid Grid kann hier seine Vorteile ausspielen, da es sich genau an die Weite anpasst. Man kann also ein Mix aus Fluid und statischem Grid als Idee anbringen. Jedoch können z.B. gezielt iPhone und iPad  Auflösungen angesprochen werden und die User-Experience angehoben werden.

Breakpoints

Geht man von einem bereits bestehenden Magento Shop aus – egal ob Fluid oder Frameless Grid -  benötigt man festgelegte Breakpoints. Breakpoints können ganz einfach bestimmt werden – Browserfenster auf die maximale Weite bringen. Dann von rechts nach links das Fenster kleiner ziehen. Sobald die Seite horizontal anfängt zu scrollen, ist man am ersten nötigen Breakpoint angekommen.

Für gewöhnlich werden die Breakpoints 320, 480, 760, 1024 (Größen für z.B. iPhone/iPad Landscape und Portrait-Orientation) und aufwärts genutzt – wobei der Gedanke hinter Responsive Design nicht als die Anpassung einer Website an Mobile Geräte gedacht war, es ist nur ein positiver Effekt den man nutzen kann. Am Ende muss aber jede Seite speziell auf Breakpoints überprüft werden.

Diese Analyse unternehmen wir von symmetrics mit unseren Magento Kunden vor einem Projekt oder bei den zahlreichen Magento Shops, die zu uns umziehen im Rahmen der Weiterentwicklung.

In der Praxis konnten die sinnvollsten Breakpoints in der Kategorieansicht ermittelt werden. Geht man von FullHD Auflösung aus, so kann beispielsweise eine 8er Grid gezeigt werden. Staucht man das Browserfenster zusammen sollte jeder Breakpoint so gewählt werden, dass bei z.B. 1800px nur noch eine 7er Grid ist, bei 1600px eine 6er Grid und immer so weiter. Mit Hilfe dieser ermittelten Breakpoints aus der Kategorieansicht kann man weiterarbeiten. Danach folgen Header- und Footeranpassungen.

Media Queries

Um mit dem Magento Responsive Design zu beginnen wird zunächst ein Meta Template benötigt um das Viewport Scaling bei Mobile Devices zu unterbinden. Das automatische Zoomen auf den Websiten Container von iOS kann dazu führen, dass die Bildqualität sinkt und Größen, bzw. Proportionen verfälscht werden.

Der Block sowie die CSS werden wie folgt in die Module Layout XML eingebunden:

<layout version="0.1.0">
    <default>
        <reference name="head">
            <action method="addCss"><stylesheet>css/responsivedesign.css</stylesheet></action>
            <block type="page/html_head" name="responsive.head" template="page/html/responsive-head.phtml" />
            </reference>
    </default>
</layout>

In das Magento Template wird folgender Inhalt eingefügt:

<meta name="viewport" content="width=device-width; initial-scale=1.0; maximum-scale=1.0" />

Als Alternative hier die Einbindung des Viewport Metas ausschließlich über Layout XML mit:

<layout version="0.1.0">
    <default>
        <reference name="head">
            <block type="core/text" name="responsive.viewport">
                <action method="setText">
                    <text>
                    <![CDATA[<meta name="viewport" content="width=device-width; initial-scale=1.0; maximum-scale=1.0" />]]>
                    </text>
                </action>
            </block>
        </reference>
    </default>
</layout>

In die CSS kommen dann die Standard und individuellen Breakpoint Media Queries.

/* Smartphones (portrait and landscape) ----------- */
@media only screen
and (min-device-width : 320px)
and (max-device-width : 480px) {
/* Styles */
}

/* Smartphones (landscape) ----------- */
@media only screen
and (min-width : 321px) {
/* Styles */
}

/* Smartphones (portrait) ----------- */
@media only screen
and (max-width : 320px) {
/* Styles */
}

/* iPads (portrait and landscape) ----------- */
@media only screen
and (min-device-width : 768px)
and (max-device-width : 1024px) {
/* Styles */
}

/* iPads (landscape) ----------- */
@media only screen
and (min-device-width : 768px)
and (max-device-width : 1024px)
and (orientation : landscape) {
/* Styles */
}

/* iPads (portrait) ----------- */
@media only screen
and (min-device-width : 768px)
and (max-device-width : 1024px)
and (orientation : portrait) {
/* Styles */
}

/* Desktops and laptops ----------- */
@media only screen
and (min-width : 1224px) {
/* Styles */
}

/* Large screens ----------- */
@media only screen
and (min-width : 1824px) {
/* Styles */
}
/* iPhone 4 ----------- */
@media
only screen and (-webkit-min-device-pixel-ratio : 1.5),
only screen and (min-device-pixel-ratio : 1.5) {
/* Styles */
}

Die Übergabe der Media Queries per CSS ist nur ein Weg um die Styles zu bearbeiten. Ein anderer Weg wäre, die Breakpoint Media Queries auf eigene CSS Dateien aufzuteilen, um bei großen Projekten Dateigrößen einzusparen.

<layout version="0.1.0">
    <default>
        <reference name="head">
            <action method="addCss">
                <stylesheet>css/filename.css</stylesheet>
                <params>media="screen and (min-width: 701px) and (max-width: 900px)"</params>
            </action>
        </reference>
    </default>
</layout>

Im Gegensatz zur Magento Community Edition ist bei der Magento Enterprise Edition zu beachten, dass mit dem CSS Merge die generierte media.css die Funktionalität der Ermittlung der Media Queries über das link-Tag unterbunden wird. Dies kann man umgehen, indem man entweder per Layout XML die CSS so einbindet:

<layout version="0.1.0">
    <default>
        <reference name="head">
            <block type="core/text" name="media.900">
                <action method="setText">
                    <text>
                        <![CDATA[<link rel="stylesheet" media="screen and (min-width: 701px) and (max-width: 900px)" href="css/filename.css" />]]>
                    </text>
                </action>
            </block>
        </reference>
    </default>
</layout>

Oder in die erstellte responsive-head.phtml unter dem Viewport Meta diese Zeile einfügt.

<link rel="stylesheet" media="screen and (min-width: 701px) and (max-width: 900px)" href="css/filename.css" />

lt IE9

Thema Internet Explorer. Für IE8 und darunter wird entweder respond.js oder media-queries.js verwendet. Falls Responsive Design im Shop ausschließlich für Mobile Devices genutzt werden soll, kann auf das Fallback-Script verzichtet werden, da IE8 und geringer dort keine Verwendung findet.

<layout version="0.1.0">
    <default>
        <reference name="before_body_end">
            <block type="core/text" name="lt.ie9.responsive" after="-">
                <action method="setText">
                    <text>
                        <![CDATA[<!--[if lt IE 9]><script src="http://css3-mediaqueries-js.googlecode.com/svn/trunk/css3-mediaqueries.js"></script><![endif]-->]]>
                    </text>
                </action>
            </block>
        </reference>
    </default>
</layout>

Brauche ich Responsive Design in meinem Magento Shop?

Für Shopbetreiber ist es nun schwer sich zu entscheiden, ob man Responsive Design braucht oder nicht. Daher eine erste Pro/Contra Liste, die bei der Entscheidungsfindung helfen soll.

Pros

• Auflösungen von Handy bis FullHD können optimal dargestellt werden.
• Technik wird großflächig unterstützt
• Mehr mögliche Werbung auf Landing Pages / Homepage / Kategorie-Callouts
• Der Kunde sieht mehr auf einmal und kann Produkte in der Grid besser vergleichen
• Mögliches Alleinstellungsmerkmal – neuartige Technik im E-Commerce Bereich
• Bei kleinen Screens ist kein horizontales Scrolling nötig und man verpasst somit kein Inhalt
• Technik mit geringstem Aufwand, Webshops an jedes beliebige Mobile Device anzupassen
• Keine großen Frameworks/Libraries nötig
• Hoch- und Querformate von Mobile Devices können unterschiedlich genutzt werden
• Inhalte umstrukturieren, nicht löschen
• Geringer Testaufwand
• Bessere Bedienbarkeit auf Mobile Devices
• Ein Template, welches sich an alle Bildschirmgrößen auf Desktoprechner sowie an Mobile Devices wie Tablets und Smartphones anpasst
• Kostenersparnis durch einmaliges Invest in ein Magento Responsive Theme anstatt mehrere optimierte Templates für verschiedene Geräte zu bauen
• Conversionoptimierung durch zufriedene Kunden und geringere Kaufabbrüche im Shop

Cons

• Gewöhnungsbedürftiges Layout in großen Darstellungen

symmetrics – Ihr Partner für Magento-Responsive Design

Als Europas größter Magento Gold Partner haben wir uns als erstes Unternehmen für Magento Shops  in der Magento Community und Magento Enterprise auf die Erstellung von Magento Responsive Designs fokussiert und hier umfangreiche Expertise aufgebaut, wir bieten Online Händlern jeder Größe hier:

• Beratung bei theoretischen Grundlagen und Maßnahmen zur Conversionoptimierung und Umsatzsteigerung durch Magento Responsive Design
• Analyse des Designs bestehender oder auch neuer Webshops
• Konzepterstellung für Handy,Tablet bis hin zu FullHD Bildschirmen unter Einhaltung von Corporate Designs
• Aussprache von Empfehlungen und Zusammenarbeit mit Designagenturen sowie agile Anpassungen von neuen Ideen während der Entwicklung
• Umfangreiche Tests mit verschiedenster mobiler Hardware (Apple, HTC, Windows Mobile, Samsung)
• Verringerung der Ladezeiten auf mobilen Geräten durch Anpassung medialer Inhalte
• Sehr schnelle Umsetzungen möglich, da keine Frameworks oder starke Mobilanpassungen nötig sind. Allein die Auflösung bestimmt das Design der Seite
• Verwendung neuester Möglichkeiten von HTML5 und CSS3
• Anpassungen an verschiedenste Browser bis runter zu IE7 sind möglich und stellen kein Problem für symmetrics dar
• Optimierung in Bereichen SEO und Usability

Für die kommenden Wochen sind neben Präsentationen und weiteren Beiträgen aus unserer neuen Abteilung rund um das Thema ebenso Schulungen sowie ein Magento Responsive Produkt geplant, welches wir in zur Verfügung stellen werden. Aktuell läuft die Schlussphase der ersten Kundenprojekte in denen das Verfahren eingesetzt wird, wir werden darüber berichten, sobald diese abgeschlossen sein werden. Stay tuned!

In Verbindung mit der Symmetrics-Magento Varnish- / ESI Lösung aus unserem Portofilio ermöglichen wir schnelle dynamische Online-Shops mit denen Sie Ihre Conversionrate und Umsatz steigern können.

Share and Enjoy

Um Varnish mit ESI betreiben zu können, muss man ein gewisses Grundwissen haben, wie die Konfiguration (VCL) von Varnish funktioniert. Zusätzlich sollte man Varnish 3 verwenden, da diese Version die Möglichkeit bietet eigene Module zu entwickeln. Dies sind sogenannte V-Mods. Für die lokale Entwicklung ist es ratsam sich Varnish aus den Sourcen selber zu kompilieren. Dies hat zwei große Vorteile. Erstens man kann sich mehrere Versionen parallel installieren und hält somit sein System sauber. Zweitens ist es dann auch einfacherer V-Mods zu schreiben und zu kompilieren. Dafür muss man aber ... mehr zu Varnish-ESI Caching mit Magento]]>

1. Voraussetzungen
2. Was ist ESI und wie funktioniert es?
3. Wie funktioniert ein ESI-Request in Zusammenhang mit Magento?
4. Was passiert, wenn ein ESI-Tag an den Browser gerät?
5. Wie kann Magento einen ESI-Request erzeugen?
6. Manuell
7. Automatisiert
8. Kann man die erzeugten ESI-Requests auch cachen?
9. Welche Probleme können mit ESI auftreten?
10. Was mache ich, wenn zu viele ESI-Anfragen entstehen?
11. Was mache ich, wenn das Backend (Magento) nicht verfügbar ist?
12. Wie verhindere ich das unnötige Erzeugen von Sessions?

Voraussetzungen

Um Varnish mit ESI betreiben zu können, muss man ein gewisses Grundwissen haben, wie die Konfiguration (VCL) von Varnish funktioniert. Zusätzlich sollte man Varnish 3 verwenden, da diese Version die Möglichkeit bietet eigene Module zu entwickeln. Dies sind sogenannte V-Mods. Für die lokale Entwicklung ist es ratsam sich Varnish aus den Sourcen selber zu kompilieren. Dies hat zwei große Vorteile. Erstens man kann sich mehrere Versionen parallel installieren und hält somit sein System sauber. Zweitens ist es dann auch einfacherer V-Mods zu schreiben und zu kompilieren. Dafür muss man aber eine entsprechende Umgebung haben, wie z.B. einen Mac mit installiertem XCode und den Compiler Commandline Tools. Dazu ist noch der Einsatz von Macports zu empfehlen. Dies ist aber auch problemlos mit einem Linux System, wie z.B. Ubuntu möglich. Es ist aber nicht unbedingt zu empfehlen dies unter Windows zu versuchen, da Varnish auf die POSIX system API calls verweist, welche unter Windows nicht standardmäßig verfügbar sind. Hierzu müsste man cygwin installieren.

Was ist ESI und wie funktioniert es?

ESI steht für Edge-Side-Includes, was auf Deutsch Quer-Seiten-Erfassung heißen würde. Technisch gesehen wird hier ein Bereich definiert, welcher bei dem Aufbau der Seite aus einer anderen Quelle bezogen wird. Dies ähnelt sehr den SSI (Server-Side-Includes). Die ESI-Tags sind reguläre XML Tags. Dies hat den Grund, dass diese einfacherer in ein XHTML-Dokument einzubetten sind und somit auch leichter zu verarbeiten. Zusätzlich erhöht es auch die Lesbarkeit des XHTML-Dokuments.

ESI selber wurde von Akamai spezifiziert und ist in Varnish nicht mit allen Features verfügbar. Derzeit wird von Varnish nur der include, remove und Kommentar Tag unterstützt.

Wie funktioniert ein ESI-Request in Zusammenhang mit Magento?

Um dies zu realisieren wird als erstes eine neue Route definiert. Am Besten macht man dies in einem eigenen Modul. Für die erstellte Route wird dann ein beliebiger Controller angelegt.
Beispiel:
- Route = varnish
- Controller = EsiController
- Dies würde dann folgende Route ergeben:

{BASE_URL}(/STORE_CODE)/varnish/esi/

Der Controller bietet dann eine beliebige Action, welche über einen zusätzlichen Parameter den gewünschten Block ausliefern kann. Als ESI-Tag würde das dann folgendermaßen aussehen:

<esi:include src="{BASE_URL}/varnish/esi/block/id/cart_sidebar" />

Dieser ersetzt dann den Block für die Darstellung des Carts in der rechten Sidebar. Zusätzlich ist noch zu empfehlen den esi:remove Tag zu verwenden, damit die Seite auch ohne Varnish oder deaktiviertem ESI noch lauffähig ist. Dies sähe in dem oben genannten Beispiel dann wie folgt aus:

<esi:include src="{BASE_URL}/varnish/esi/block/id/cart_sidebar" />
<esi:remove>
<div><p>This content will be removed by esi processing.</p></div>
</esi:remove>

Grundsätzlich kann man sagen, dass es zwei Möglichkeiten gibt ein ESI-Tag in Magento zu erzeugen. Dies wird im folgenden Absatz noch genauer beschreiben.

Was passiert, wenn ein ESI-Tag an den Browser gerät?

Der Browser wird die Tags ignorieren, da diese einen eigenen Namespace (esi) besitzen. Entwickler, die mit Java und Tapestry arbeiten, werden dies Verhalten bereits kennen. Dies hat zusätzlich auch als großen Vorteil, dass die Seite immer noch korrekt dargestellt werden kann, falls Varnish einmal ausfallen sollte. Hierzu muss aber dann richtig Gebrauch von dem esi:remove Tags gemacht werden.

Wie kann Magento einen ESI-Request erzeugen?

Um ein ESI-Request aus Magento heraus zu erzeugen gibt es zwei Wege.

Manuell

Dies ist für den Anfang und für erste Tests wohl der leichteste Weg. Will man aber mehrere Bereiche auf der Seite mit ESI abdecken, sollte man sich überlegen hier nicht einen Automatismus zu entwickeln. Dies senkt zu einem den Wartungsaufwand und minimiert auch die Fehleranfälligkeit.

Automatisiert

Bei einer automatisierten Lösung fängt man das Rendern der einzelnen Blöcke ab (core_block_abstract_to_html_after Event) und prüft ob dieser Block durch einen ESI-Request ersetzt werden soll. Ist dies der Fall, wird dann die Blockausgabe mit den entsprechenden esi Tags dekoriert. Dazu wird der Inhalt aus dem Block Transport Container modifiziert.

Kann man die erzeugten ESI-Requests auch cachen?

Ja es ist möglich, diese Requests auch in Varnish zu cachen. Eine Möglichkeit wäre hierfür einen zweiten Varnish zu verwenden, welcher nur für das Cachen der ESI-Anfragen zuständig ist. Hierbei muss aber beachtetet werden, dass die ESI-Anfragen für jeden Kunden individuell sind. Hier kann das Risiko bestehen, dass ein Kunde die Daten eines anderen Kunden sieht.

Welche Probleme können mit ESI auftreten?

Grundsätzlich gibt es drei Problem-Merkmale, die in Verbindung mit ESI auftreten können und zu beachten sind.

1. Zu viele ESI-Anfragen
2. Das Backend (Magento) ist nicht verfügbar
3. Erzeugen ungenutzter Sessions

Was mache ich, wenn zu viele ESI-Anfragen entstehen?

Wenn zum Beispiel auf jeder Seite die rechte Sidebar inklusive aller Standardfunktionen verwendet wird, dann ist für jeden dynamischen Bereich ein ESI-Request auszulösen.
Dies wären dann folgende:

1. Welcome Message im Header
2. Minicart
3. Zuletzt angesehen Produkte
4. Vergleichsliste
5. Umfragen
6. Wunschliste
7. Messages Block
8. Global Messages Block

Dadurch werden acht Anfragen an Magento für den spezifischen Bereich durchgeführt. Dies kann unter Umständen eine höhere Gesamtlast erzeugen, als wenn man Magento ohne Varnish Cache betreiben würde. Eine Lösung die zu umgehen ist, dass man jede ESI-Anfrage für die gültige Session cached und diese dann nach Bedarf leert. Zum Beispiel wenn sich der Kunde einloggt, leert man alle Placeholder. Hierbei ist auch zu beachten, dass man die Messages Blöcke spezifisch behandelt.

Was mache ich, wenn das Backend (Magento) nicht verfügbar ist?

Hierbei ist zu empfehlen, dass, wie schon beschrieben, die ESI-Requests gecached werden. Dadurch hat man die Möglichkeit die Fehlerausgabe von Varnish zu nutzten. Dadurch merkt der Kunde vorerst nicht gleich, dass der Shop nicht funktioniert und kann weiterhin im Katalog des Shops blättern. Zusätzlich kann man sich ein Varnish V-MOD schreiben, welcher dann entsprechend des Requests bei einem Fehler eine Standardausgabe darstellt.

Wie verhindere ich das unnötige Erzeugen von Sessions?

Ein Weg dies zu verhindern ist, dass man prüft ob der Kunde bereits ein entsprechendes Session-Cookie ausliefert. Ist das nicht der Fall, muss dem Kunden eine neue Session zugewiesen werden. Dies kann man z.B. durch einen direkten Request an das Backend (Magento) veranlassen, oder indem man eine entsprechende Logik in Varnish implementiert. Wird diese Logik nicht implementiert, besteht die Gefahr, dass für jeden ESI-Request eine neue Session erzeugt wird. Hierbei ist auch zu beachten, dass die Response Header der ESI-Anfrage nicht an den Client weiter gegeben werden. Somit ist eine Session-Zuweisung über ESI nicht möglich.

Ein weiterer wichtiger Punkt bei der Session Prüfung ist, das Suchmaschinen-Bots keine Sessions annehmen oder ausliefern. Um diese korrekt zu behandeln muss eine Weiche in die VCL implementiert werden.

Share and Enjoy

Ab sofort steht allen Nutzern der erfolgreichen Open Source E-Commerce-Plattform Magento, das neue Lokalisierungspaket „Market Ready Germany by symmetrics & Trusted Shops“ in der Version 2.0. zum kostenlosen Download zur Verfügung. Das Paket ist kompatibel mit allen aktuellen Versionen von Magento, sowohl der Community Edition 1.4 als auch erstmals vollständig mit Magento Enterprise Edition 1.8. Magento Enterprise Partner symmetrics und Trusted Shops, Europas führender Vertrauensdienstleister für Online-Händler, machen das Magento E-Commerce-Plattform automatisch fit für den deutschen Markt. Magento-Nutzer mussten bisher vielfältige manuelle Anpassungen an der Software, der Darstellung und den Texten vornehmen, wenn sie ihren Shop für die deutschen Anforderungen funktionell vollständig und rechtsicher machen wollten.

„Die Erweiterung “Market Ready Germany by symmetrics & Trusted Shops” ist ... mehr zu Market Ready Germany 2.0. (MRG 2.0) von Magento Enterprise Partner symmetrics ab sofort verfuegbar]]>

1. Market Ready Germany 2.0. (MRG 2.0) von Magento Enterprise Partner symmetrics und Trusted Shops ist ab sofort verfügbar
2. Neue Key-Features
3. Partner

Market Ready Germany 2.0. (MRG 2.0) von Magento Enterprise Partner symmetrics und Trusted Shops ist ab sofort verfügbar

Ab sofort steht allen Nutzern der erfolgreichen Open Source E-Commerce-Plattform Magento, das neue Lokalisierungspaket „Market Ready Germany by symmetrics & Trusted Shops“ in der Version 2.0. zum kostenlosen Download zur Verfügung. Das Paket ist kompatibel mit allen aktuellen Versionen von Magento, sowohl der Community Edition 1.4 als auch erstmals vollständig mit Magento Enterprise Edition 1.8.

Magento Enterprise Partner symmetrics und Trusted Shops, Europas führender Vertrauensdienstleister für Online-Händler, machen das Magento E-Commerce-Plattform automatisch fit für den deutschen Markt. Magento-Nutzer mussten bisher vielfältige manuelle Anpassungen an der Software, der Darstellung und den Texten vornehmen, wenn sie ihren Shop für die deutschen Anforderungen funktionell vollständig und rechtsicher machen wollten.

„Die Erweiterung “Market Ready Germany by symmetrics & Trusted Shops” ist ein Riesenerfolg: Die Extension wurde seit erstmaliger Einführung vor knapp einem Jahr fast 18.000 Mal heruntergeladen und gehört damit zu den populärsten Extensions weltweit. Dabei ist es die größte jemals releaste Modulsammlung mit nun 18 Einzelmodulen“, erklärt Boris Lokschin, CEO der symmetrics gmbh.

Die neue Version MRG 2.0. ist ein komplettes Refactoring “from scratch”. Hauptziel war es eine deutlich höhere Kompatibilität zwischen dem Paket und individuellen Modulen von Entwicklern und Agenturen zu erreichen. Zudem sollten alle neuen Magento Möglichkeiten umfänglich nutzt werden können und innovative neue Features eingebracht werden.
MRG 2.0. konfiguriert Magento automatisch vor für den deutschen Markt, ergänzt für Deutschland notwendige Funktionalitäten eines B2C Shops und bereitet Magento auf eine Zertifzierung durch Trusted Shops vor. Durch die Vorzertifizierung können Magento-Nutzer Sonderkonditionen für die Gütesiegel-Zertifizierung von Trusted Shops nutzen. Beispielsweise sorgt Market Ready Germany für die korrekte Preisauszeichnung der Artikel, gewährleistet die erforderliche Belehrung über das Widerrufsrecht und berücksichtigt wichtige Erfordernisse des Datenschutzes.

Aber auch zahlreiche neue Features sind in MRG 2.0. eingeflossen, wie z. B:

Neue Key-Features

• Volle Kompatibilität aller Module und Abhängigkeiten zu Magento Community Edition 1.4 und Magento Enterprise Edition 1.8.
• Vollständig mit Hilfe der Experten von Trusted Shops an alle aktuellen rechtlichen Anforderungen angepasst/aktualisiert worden
• Komplett überarbeitetes Impressum Modul für mehr Flexibilität, neuen Features, Komfort und besseren Verwendungsmöglichkeiten
• Komplett neues Invoice PDF Modul (Rechnung Modul) welches nicht mehr Magento Invoice überschreibt, sondern komplett eigene Funktionalitäten mit sich bringt. Für leichtere Anpassungen, Upgradefähigkeit und Erweiterbarkeit. Die Integration zum Impressum Modul wurde deutlich verbessert.
• neues Modul “Symmetrics_PdfPrinter” für den Export/Rendering beliebiger CMS Seiten als PDF
• neues Modul “Symmetrics_SecurePassword” verhindert die Verwendung der angegebene E-Mail Adresse auch als Passwort. Außerdem bietet es einen Brute-Force Schutz für den Login im Frontend; es sperrt nach mehreren fehlgeschlagenen Login-Versuchen zeitweise den Account. Im Registrierungsformular wird eine Notiz eingeblendet, die darauf hinweist, wie ein sicheres Passwort aussehen sollte.
• neues Modul “Symmetrics_SetMeta” für verbessertes SEO, dieses Modul füllt die Meta-Daten eines Produktes automatisch mit dem Produktnamen und den Kategorien
• neues Modul “Symmetrics_TweaksGerman” verändert das System im Hinblick auf die rechtlichen Erfordernisse eines Online-Shops am deutschen Markt. Das Modul entspricht der Vorzertifizierung für das Trusted Shop Gütesiegel und beinhaltet gemergte Teile von inzwischen entfernten Modulen aus MRG 1.0.
• uvm.

Die vollständigen Release Notes mit voller Beschreibung der Optimierungen, aller Verbesserungen bestehender Module und weiteren neuen Features finden Sie in den Release Notes unter: http://www.symmetrics.de/mrg/docs/mrg2-release-notes.pdf

Partner

MRG 2.0 integriert führende Branchenpartner in den Bereichen Rechtssicherheit, Vertrauensdienstleistungen und Payment in das Paket. Dies ermöglicht Shopbetreibern einen maximal einfachen Zugang zu den integrierten Services. Shopbetreiber können durch die Verwendung der weiterhin kostenfreien MRG Installation auf diese Weise zusätzlich von attraktiven Konditionen und einer einfachen technischen Integration profitieren. Es wurden bewusst bereits im Magento Umfeld etablierte Partner aus den jeweiligen Segmenten aufgenommen, deren Ziel eine nahtlose Integration in Magento CE 1.4.x und Magento EE 1.8.x ist.

Folgende führende Branchenpartner wurden mit Modulen und Sonderkonditionen aufgenommen:

• Trusted Shops Customer Rating
• Cash Ticket
• PAYONE

symmetrics bedankt sich bei dem MRG symmetrics Team, allen Partner, Sponsoren, Helfer aus der Community, Beta Tester, Shopbetreibern für das Testen und das zahlreiche Feedback im Vorfeld des Releases.
Weitere Informationen finden Sie unter: www.symmetrics.de oder unter Market Ready Germany 2.0 in Magento Connect: http://www.magentocommerce.com/magento-connect/symmetrics+GmbH/extension/1764/market-ready-germany

Share and Enjoy