Warning: This feature is deprecated. If you have questions or concerns, contact us.
A widget component is a small element on a user’s site. Site visitors can see and interact with widget components.
In this article we'll tell you about all the things to keep in mind when developing a widget component to help you deliver the best possible experience for users.
Here's some useful things to know about a widget component:
A widget component is made up of two parts – the widget iframe and an App Settings panel. These components talk to our systems through our iframe SDK.
Important: Your widget must load the SDK in the component and App Settings endpoints, and both must support HTTPS.
When a user adds your app, we’ll generate a unique ID for your app for this specific site – this is the App Instance ID. You should use this to link your app to this site.
This ID is sent to you as part of the App Instance query parameter, which is a signed parameter that allows you to identify the website and the Wix user, and verify that the calling party is indeed Wix.
All of your app’s endpoints will have the same App Instance ID, so each request sent to the widget endpoint and to the App Settings endpoint includes the same App Instance ID in the iframe URL.
To build a widget component, you'll need to create an App Settings panel. Here's some things you should do to create an optimal App Settings experience:
When users change a setting in your app, update the app right away in the Wix Editor – but don’t change the app on the live site until the user publishes the site. Here’s how:
When users change your app’s settings, here’s how to update your app right away in the Wix Editor:
1. Detect changes that the user makes in the App Settings panel: Use the onChange or onClick function.
2. Update your database/backend server immediately.
3. Show the changes in your app: for a better user experience, don’t refresh your app – here’s what to do instead:
Users can copy the widget component as many times as they want on their website, and they can customize each widget differently. Here’s what you should do:
You’ll set an initial size for your app, but users can resize your app in the Wix Editor. Follow our UI/UX guidelines – we’ll show you how to decide your app’s initial size, and how to create the right user experience when users resize your app in the Wix Editor.
If your widget has text or other content that’s meaningful for your users’ SEO, develop a dedicated SEO endpoint for your widget component.
This will enhance your users’ SEO by allowing Wix to dynamically adjust app content displayed for search engines. Your SEO endpoint will be visible to search engine crawlers only.
You should only develop an SEO endpoint if your app’s content is meaningful for SEO. When we render a site’s SEO view, we use this endpoint to dynamically embed your app’s content into the SEO view.
Examples of apps that should have an SEO endpoint:
Examples of apps that shouldn’t have SEO endpoints:
Not sure if your widget should have an SEO endpoint? Get in touch.
Your SEO endpoint should be a stripped down version of your app – it should have just the static HTML content that’s visible on the user’s site, and none of the Javascript or dynamic functionality.
Here are some important things to keep in mind when creating your SEO endpoint:
<body>
tag: include all HTML elements inside the body – like headings, lists, paragraphs, images, etc. <title>
or <meta>
tags in the <head>
element: leave this data for the user to define.<h1>
element to the SEO endpoint: this can cause issues for users because they may end up with more than one h1 on the page.<script>
tags or other dynamic/interactive content.App HTML
SEO endpoint
You can see what your app looks like to a search engine crawler – whether or not you developed a dedicated SEO endpoint by accessing the site / page with a Googlebot.
Here’s how to do it in Google Chrome:
For browsers like Edge, Firefox and Safari, check out this article.
Create a mobile endpoint for your app so that it works well on mobile devices. This endpoint should have the same functionality as your web app – except for these differences:
URL Requirements
Widget request URL template:
Name | Value | Comments |
---|---|---|
endpoint | The Widget URL as provided during the app registration in the app dashboard | |
app-state | The inner state of the widget component | The app-state part of the URL may include a query string, but must not include a # |
instance | The signed instance | |
section-url | The base URL of the widget component | |
target | Attribute that must be added to all href anchors within the widget iframe | |
width | The width of the iframe in pixels | Note that the frame height will auto-adjust depending on the frame content |
cacheKiller | The cacheKiller is there to ensure no caching of the iframe content by the host browser | |
compId | The ID of the component | While the instanceId remain constant within the scope of the site, each iframe will have a unique and persistent compId |
viewMode | Current view mode | "editor" or "site". "editor" is valid inside the Wix editor, while "site" is available only in a published website |
locale | Current locale value | |
deviceType | Current device type | "desktop" or "mobile" |
App Settings request URL template
Name | Value | Comments |
---|---|---|
endpoint | The App Settings URL as provided in the app dashboard | |
instance | The signed instance | |
width | The width of the iframe in pixels | |
compId | The compId value for the app settings is always tpaSettings | |
origCompId | The ID of the component which associated with the App Settings | The origCompId identifies the current component that the user is editing |
locale | Current locale value |
It's really important to make sure your app is secure and protects the user's privacy. We've got a dedicated guide to help you with this.