Frequently asked questions

Yes, you can create photography portfolios that automatically generate album pages based on Google Drive folders. Use the Google Drive API (REST API v3) to fetch photos from specific folders and display them as sliders or slideshows in Webstudio. You'll need to set up API authentication and create resources in Webstudio that connect to your Google Drive folders. This allows for automatic updates when you add new photos to your Drive folders.

When you export static code from Webstudio, direct edits to the HTML may not appear in the browser due to the /assets/entries scripts that handle the styling and functionality. If you need to convert to PHP or integrate with a CMS like Drupal, consider using Webstudio's Content Blocks for editable areas instead. For complex integrations, using the CMS as a headless solution (via API) with Webstudio is recommended rather than rewriting the exported HTML.

Vimeo embed aspect ratios are defined in styles. For dynamic pages that need to handle both horizontal 16:9 and vertical 9:16 videos, you can conditionally show landscape or portrait instances based on CMS data. Add a field in your CMS to specify the video orientation, then use conditional visibility to show the appropriate embed configuration.

To hide the current blog post from a collection of related posts, use the Show toggle with a binding condition. The expression should be: system.params.slug == Collection Item.data.slug ? false : true. This compares the current page slug with each collection item's slug - if they match, it hides the item (false), otherwise shows it (true). Apply this condition to individual collection items, not the entire collection.

Slow server response times are often caused by Resources (API calls) placed at the root level. If you're using a Resource globally but only need it on specific pages (like Airtable for a careers page), move the Resource to the body of that specific page instead of the root. Airtable is particularly slow - consider switching to Baserow for faster API responses. Server response times can drop from 1200ms to 200ms by moving Resources appropriately. Caching options for Resources are planned to help with slow APIs.

For multilingual websites, avoid using show/hide with CSS classes as it loads all languages at once (slower page loads, bigger DOM) and SEO won't index hidden content properly. Instead, pull language content from separate JSON files or a CMS that supports i18n, then swap content dynamically with JavaScript based on user's language choice or browser settings. Don't forget about text direction (LTR/RTL) for non-Latin scripts, and include the lang tag for accessibility so content is read aloud in the correct language.

When integrating with Ghost CMS, the API only returns 15 items by default. To ensure all entries are included in your sitemap, add '&limit=all' to the Ghost API endpoint. This parameter will fetch all available entries instead of just the default limited set.

When working with CMS data that isn't in slug format, you can use JavaScript in an HTML Embed to format the links. Create click event handlers that process the text (convert 'Door Hardware' to 'door-hardware'), then navigate to the formatted URL. Remember to use event.preventDefault() to stop the original link behavior before applying your custom navigation logic.

Slow server response times are often caused by API resources being loaded on every page, even when not needed. Solutions:

1. Move API resources from the root to specific pages where they're actually used,
2. Consider faster CMS alternatives - Airtable is notably slow while Baserow is faster,
3. Implement caching for API responses when data doesn't change frequently. Moving a slow Airtable resource from root to page-specific usage can reduce server response time from 1.2s to 200ms.

To format DateTime strings (like ISO 8601 format from Hashnode or other CMS), use Webstudio's Time component. Simply bind the datetime string from your CMS to the Time component's data field, and it will automatically format the date according to the component's settings. This works with various datetime formats including '2025-08-06T22:26:05.044Z' format.

For date formatting, use the dedicated 'Time' component from the components panel, not the time HTML tag applied to text elements. The Time component has built-in date/time format options and can handle various date inputs from CMS or static values. The time tag on regular elements doesn't include formatting options.

To integrate Directus CMS with Webstudio, you need to use GraphQL queries similar to other CMS integrations. First, set up your Directus API endpoint, then create GraphQL queries in Webstudio's resource panel. You can find GraphQL schema and test queries in Directus's built-in GraphQL playground. The process is similar to integrating other headless CMS platforms that support GraphQL.

When integrating Ghost CMS with Webstudio, make sure to add '&limit=all' to your API endpoint URLs. By default, Ghost's API only returns 15 items, which can result in incomplete sitemaps and missing content. Adding this parameter ensures all your Ghost content is properly included in your Webstudio site's sitemap and navigation.

For DateTime objects from CMS (like Hashnode's ISO 8601 format '2025-08-06T22:26:05.044Z'), use Webstudio's Time component (not Date component). Simply bind your DateTime string from the CMS to the Time component's data field. The Time component will automatically parse and format the DateTime string according to your specified format settings.

For Sanity CMS dynamic pages:

1. Create a general resource for all posts using the URL field (not expression editor): https://YOUR-PROJECT.api.sanity.io/v1/data/query/production?query=*[_type == "post"]{..., person->, mainImage{asset->{url}}},
2. Create a single post resource using the expression editor: https://YOUR-PROJECT.api.sanity.io/v1/data/query/production?query=*[slug.current=="${system.params.slug}"][0]{..., person->, mainImage{asset->{url}}}. Use system.params.slug for URL parameters. Avoid multiple queries in GROQ within the URL as Webstudio may have issues with them.

When setting up headless WordPress with Webstudio, you may encounter issues where data displays in the builder but not on the published site. This is often because WordPress hosting providers (like SiteGround) block Cloudflare Workers requests, treating them as bots. Contact your hosting provider to whitelist Cloudflare Worker IP addresses. SiteGround specifically requires adding Cloudflare IPs to their whitelist.

To change the styling of links in embedded Ghost CMS content, look for the dropdown menu in the style panel when you have the Content Embed component selected. You can modify link styles including colors from there. The default bright blue link color can be customized to match your site's design.

Use the Time component from the component library instead of adding a time tag to an element. The Time component has built-in date format options that aren't available when you manually add a time tag to other elements. The Time component provides proper formatting controls for displaying dates and times from your CMS or data sources.

For content longer than 50,000 characters in HTML Embed or Content Embed components, you can load the content from a CMS using Webstudio's resources feature. Instead of embedding the content directly, store your lengthy content (like blog posts or Terms of Use) in a headless CMS and fetch it dynamically. This bypasses the character limit and also makes the content more manageable and editable.

Contentful's API response structure separates linked entries and assets into different arrays, which creates challenges with Webstudio's expression editor limitations. Since you can't easily connect linked entries and assets within the expression editor, the recommended solution is to create a data transformer using a CloudFlare Worker or similar service to restructure the API response before it reaches Webstudio.

For content longer than 50,000 characters like lengthy blog posts or documents such as Terms of Use, you can load them from CMS with resources instead of using HTML Embed or Content Embed elements directly.

Global variables allow you to reuse data like email addresses, phone numbers, and API endpoints across multiple pages and components without duplicating them. This feature significantly improves CMS workflows by making it much easier to get started with a CMS and maintain projects. Instead of hardcoding values, you can define them once as global variables and reference them throughout your project, making updates and maintenance much simpler.

API limits vary by platform: Airtable's free plan has very restrictive limits that can be hit quickly. Baserow has more generous limits (around 10 concurrent requests) and works well for sites with under 1000 visitors per day. For production sites, consider self-hosting Baserow for more freedom, or use dedicated blog CMS platforms like Ghost, Hyvor Blogs, or Zenblog. Always implement caching to avoid hitting limits on every page load.

For multilingual websites, avoid using CSS show/hide classes as it loads all languages at once (slower, bad for SEO). Better approaches: 1) Pull content from separate JSON files or a CMS with i18n support, 2) Swap content dynamically with JavaScript based on user's language choice or browser settings, 3) Use separate URLs for different languages, 4) Consider text direction (LTR/RTL) for non-Latin scripts, 5) Include proper lang tags for accessibility so screen readers can read content in the correct language.

The most common cause of slow server response (1+ seconds) is API resources being loaded globally at the root level when they're only needed on specific pages. Airtable is particularly slow and can cause 1.2s response times. Moving resources to page-specific usage and switching to faster alternatives like Baserow can reduce response times to 200ms. Caching options for resources are planned for future implementation (GitHub issue 4077).

For blogs with Webstudio, you have several options: 1) Use headless CMS like Ghost, Directus, or Contentful for structured content management, 2) For smaller blogs (under 50 posts), consider designing individual pages and copying/pasting elements between them, 3) Use dedicated blog platforms like Hyvor Blogs or Zenblog that are designed for Webstudio integration, 4) Implement caching strategies to avoid API limits and improve performance. Choose based on your scale, technical requirements, and content management needs.

For adding custom code like Google Tags via CMS, you have two approaches: 1) Fetch the complete code via API and place it in an HTML Embed element, or 2) Store only the tracking ID in your CMS and use that as part of a script template in Webstudio. The second approach is often cleaner as it separates data from code and makes tracking IDs easier to manage across different environments.

If CMS images appear broken in the builder but work when accessing the URL directly, it's likely a permissions issue with your CMS setup. For Directus, check that the assets have proper public access permissions. The image URL should be accessible without authentication. Directus has many permission settings that can affect asset access.

If WordPress CMS content works in the editor but not on the live site, try enabling 'client only' for all scripts in your project settings. This forces scripts to run on the client side rather than server-side, which can resolve content loading issues. Also check for any 404 errors in the browser console that might indicate routing or API access problems.

Yes, Webstudio will add the ability to set dynamic HTML attributes using CMS data in the future. Currently, you can work around this limitation by using HTML Embed components to add dynamic values from your data sources. This feature is on the roadmap for enhancing dynamic content capabilities.

Yes, Webstudio plans to add cache options for resources (GitHub issue 4077). This would allow users to override CMS/API cache headers and enable Cloudflare edge caching, which would improve performance and reduce API calls to the origin server. This is particularly useful for data that doesn't change frequently.

Not currently, but markdown support as Content Embed is planned (GitHub issue 3485). This would allow any text field to become rich text, making any database or backend suddenly CMS-capable with decent content editing. Markdown support would enable use of platforms like Strapi and Contentful that output markdown instead of HTML.