Why I don't like Custom fields?

Shyim

Shyim

Developer @ Shopware

Normally every project needs custom values saved on products or another entities. Shopware does offer by default Custom fields. It looks nice, but it can produce very fast issues.

Before we start: This is my opinion

Let's start with a simple Pro Contra list.

Pro

  • Can be easily created in the Administration / Code.
  • Can define field types, labels etc and Shopware does the rendering in Administration for me
  • Loaded by default on the entities
  • Custom Fields are schema less. You can save anything in it

Contra

  • Custom Fields are schema less. You can save anything in it
  • They are saved as JSON
    • Hard to modify using SQL
    • Cannot have associations
    • Slow on SQL Filtering, Aggregation
  • Loaded by default on the entities
  • Support between MySQL and MariaDB differs and Performance
  • Cannot have Flags. All fields are public using Sales-Channel / Store-API
  • Cause it does not have a Schema they will be indexed as dynamic in Elasticsearch. This brings lot of other problems
  • You don't have a control is it translatable or not
  • Fields values cannot be easy deleted on all entities. You need to modify each entry.

The most problems are introduced cause of the usage of an JSON field. In SQL the accessed fields needs to be extracted. This takes some time of course. On a bigger shop using many products this could leak to performance issues in the listing when it's used inside a product filter.

But when search / filtering / aggregation is slow. Can I not just use Elasticsearch?

You can. But...

We learned before they don't have a Schema. So we have to index the custom Fields with dynamic enabled. With this option Elasticsearch tries to find the best suitable data type for your field. When we have multiple data types in the same field across entries the indexing will fail. Cause Elasticsearch decided to use first best suitable data type and rejects values does not match it.

But when is it okay to use them?

  • When you don't need to Filter / Aggregate / Search on it
  • When it's okay to be exposed in the Public API (Sales Channel / Store API)

But Entity Extensions are so annoying to create

The generation of the entities can be annoying. But I am working since some time on a generator. Give it a try. https://github.com/FriendsOfShopware/FroshDevelopmentHelper

How to deploy plugin updates automatically to the Shopware Store

Shyim

Shyim

Developer @ Shopware

This blog post describes a small example how to automaticly deploy plugin updates to the Store. I will use the FroshPerformance plugin as example.

Preparation

You will need

  • a Plugin which based on the 5.2 Pluginsystem or Shopware 6 Plugin
  • a Continuous Integration (i will use Travis as example)
  • Credentials for the Shopware Account
  • FroshPluginUploader

Prepare the Plugin itself

You will need a plugin.xml with filled title, version, description, compability and changelog for the languages en and de. All these informations will be picked up automaticly and updated in the Account.

Optional

You can define also the plugin description, manual and images in Resources/store. Currently supported files are

  • [shortLanguage (de, en)].html - for the Description
  • [shortLanguage (de, en)]_manual.html - for the Install Manual
  • images/*.(png|jpg|jpeg) will be used for Images. First image will be used as preview image.

Setting up the ci

As first you should define following environment variables as secret in your favourite ci

  • ACCOUNT_USER - Username of Shopware Account
  • ACCOUNT_PASSWORD - Password of Shopware Account

As next we setup a job to build the store ready plugin zip. The Uploader has an command to generate an zip file for your

php frosh-plugin-uploader.phar ext:zip:dir [Path to Git Folder]

After building an zip, we validate the zip file using the uploader with

php frosh-plugin-uploader.phar ext:validate my-plugin.zip

This will check all requirements from the Uploader and also from the Plugin Guidelines. which are also describe in Prepare the Plugin itself

After the validating you can sync the optional folder Resources/store to the account with

php frosh-plugin-uploader.phar ext:update FroshPerformance

As last step you can upload the zip with

php frosh-plugin-uploader.phar ext:upload my-plugin.zip

The command will also wait for the automatic code-review and will fail, if its not green. Reuploading same version will replace existing binary.