Customizations
There are several ways to customize the designer to your needs. It’s crucial to understand all of them to find out the way that works best for you and your team.
Please mind: For all ways of customization developer skills are needed.
Please also keep in mind that - if you’ve implemented a customization and it works for you - there’s still a tiny risk that it will stop working after you’ve updated the product designer or your online shop system to a new version. So you should test your customizations after each update again.
If you are eligible for using our official support and you have some issues using the designer please make sure to disable all your customizations before contacting us - so you can be sure that the issues are not created by one of your customizations.
Monkey Patching 🐒
This is the recommended way if you or your colleagues have basic knowledge in programming and you don’t want to spend too much time and money in developing customizations and keeping them up to date. The designer source code will not be touched. Instead you will still use the compiled files which are bundled into the shop plugin. Monkey patching takes place in additional JavaScript and CSS files which will be loaded after the compiled files of the designer. Using this way you don’t replace logic but patch it afterwards to fulfill your requirements. Therefore it’s not required to download the source code using this approach - still it’s recommended to have a look into it to get a better understanding of what’s happening behind the scene.
While it’s possible to achieve some great results there are some disadvantages using this approach though:
- It’s required to load more files from the server (the JavaScript/CSS files containing the customizations).
- If your customizations are complex or need a lot of lines of code it could be hard to maintain these - because the core designer logic you modify with your customizations is minified and therefore hard to read. Developers won’t get the whole picture.
- There’s a small time frame between the loading of the core designer files and your customization files. The designer initially loads in it’s original state and later on your customizations will be applied. This could be visible to the end user. There are smart ways to work-around that issue - like setting elements initially to hidden via CSS - but you have to take care about this.
- While it’s quite possible to do deep customizations using this approach it can be tricky sometimes. If you need deeper ways of customization or prefer a cleaner way this approach may not be the right for you.
Read more about monkey patching here.
Source code plugins 🔌
This is the recommended way if you want to deeply change the core logic of the designer using a clean approach and without risking too many compatibility issues with future versions of the designer. Using this approach you and your team need to have advanced knowledge in programming, especially in JavaScript, Typescript and NPM. Also it’s helpful to have some knowledge in Vue.js, Tailwind CSS, fabric.JS and Vite
For this approach it’s required to download the source code of the designer frontend and/or backend. You can implement your own plugins which will modify the functionality of the designer then. Finally you have to re-compile the designer source code including your plugins, upload the compiled files to your server and configure your shop plugin configuration to use the customized compilation files instead of the original ones bundled with the shop plugin.
Please mind: The recompilation is just needed to have your plugins bundled and compiled into the output files. Using this approach you don’t modify the original source code files - you basically just use dependency injection to replace some of their logic.
Read more about source code plugins here.
Source code modifications 🔨
Of course it’s possible to directly modify the original source code files and compile it again - so this is an option, too. You could use this approach if you don’t care about being compatible to future updates and you don’t want to be forced into the DI architecture the source code plugin approach requires. In general we don’t recommend touching the source code directly - but, if you were thinking about writing your own product designer from scratch and you just use our product designer as a foundation to save time and money this could be a legit way.
Post Message API 📮
Usually data between the product designer and your online shop are shared using a GraphQL API. There’s one exception: The moment the customer finishes the design & the product designer gets closed there’s a post message sent from the iframe to the HTML page of the web shop. The post message payload contains some information of the newly created design like the price and the basket image preview URL. You could listen for the Post Message API request and handle it on your own.
Read more about the Post Message API here.