> Portal Navigation: > > - Append `.md` to any URL under `https://dev.wix.com/docs/` to get its markdown version. > - Pages are either content pages (article or reference text) or menu pages (a list of links to child pages). > - To get a menu page, truncate any URL to a parent path and append `.md` (e.g. `https://dev.wix.com/docs/sdk.md`, `https://dev.wix.com/docs/sdk/core-modules.md`). > - Top-level index of all portals: https://dev.wix.com/docs/llms.txt > - Full concatenated docs: https://dev.wix.com/docs/llms-full.txt ## Resource: Test Site Considerations ## Article: Test Sites and Velo ## Article Link: https://dev.wix.com/docs/develop-websites/articles/workspace-tools/testing-monitoring/test-sites/test-site-considerations.md ## Article Content: # Test Site Considerations When using [test sites](https://support.wix.com/en/article/about-test-sites) on a site with code, it is important to understand how the different versions of your site work with the following features. ## Database collections When you have both a published revision and a test site revision of your site, you still only have 1 version of your site's database collections that both revisions access. That means, when you perform a data operation such as updating an item from either your published or test site revision, the change affects both of your site revisions. While your data does not change based on the site revision, your database [schema](https://support.wix.com/en/article/about-database-collection-schemas) may differ from revision to revision. This means that a field that exists in the schema in the test site revision may not exist in the schema in the published revision. Because collection data itself is maintained regardless of whether a field is in the schema, this should not affect the functionality of your site revisions. ## Backend events Currently your site must be published at least once for the version of the event handler in your test site to run when a [backend event](https://dev.wix.com/docs/develop-websites/articles/coding-with-velo/backend-code/events/about-backend-events.md) on your test site is triggered. For example, let's say you have a `onNewOrder` event that handles new events in your store. In your published site your event handler sends an email to `p@supplier.com` for each order received, but in your test site the same event handler sends an email to `rc@supplier.com`. Whenever a site visitor places an order on your test site, an email is sent to `rc@supplier.com`. If you define a backend event handler in your test site revision without ever publishing the site, messages in backend code are not logged to the browser's console and the event handler never runs. Keep in mind that messages in backend code are not logged to the browser's console. ## Scheduled jobs When you [schedule jobs](https://dev.wix.com/docs/velo/articles/getting-started/schedule-jobs.md) in your site's backend, only the jobs scheduled in your published site revision run. The jobs scheduled in your test site revision do not run. ## Service plugins To use [service plugins](https://dev.wix.com/docs/develop-websites/articles/coding-with-velo/integrations/service-plugins-formerly-spis/about-service-plugins.md) in your test site revision, make sure to publish your site once after implementing the plugin. After that first initial publish, the service plugin implementation works on your test site revision. If the site hasn't been published, the published revision's implementation runs. Neither the published revision nor the test site revision runs your latest service plugin code. ## The Realtime API Currently the [Realtime API](https://dev.wix.com/docs/velo/api-reference/wix-realtime-backend/introduction.md) is partially supported for test sites. Keep the following considerations in mind: - [realtime_check_permissions](https://dev.wix.com/docs/velo/api-reference/wix-realtime-backend/realtime-check-permission.md) and [PermissionsRouter](https://dev.wix.com/docs/velo/api-reference/wix-realtime-backend/permissions-router/introduction.md) are not supported on test site revisions. - When publishing/subscribing to messages on a channel in both test site and published revisions, both sites receive messages from both versions. This means that the published site receives the messages from both the published site's backend and the test site's backend. Similarly, the test site receives the messages from the test site's backend and the published site's backend. It isn't possible to add new message types on the same channel with the aim to test it only in the test site revision because the published revision also receives the new message. This might cause unexpected behavior.