I am building a site that will have a lot of user-entered data into the CMS (self-service functionality); as well as other copy/image/video content entered by ourselves.
My questions are:
(1) how is the user-data protected on the live site [and not overwritten when the development site is published as live] ?; also
(2) how are collections / field additions handled under the same publish-as-live scenario?
It would be great to hear how you handle this, especially on larger projects where you have a lot of real-time user Create/Update/Delete/Query activity going on.
Not sure what you mean my overwritten. If you update data in the CMS, you’re overwriting it. Making sure you don’t overwrite something you didn’t intend to is one you (beyond the built-in features mentioned & linked to above).
Try setting up a CMS with a field, add some data to it, then try to remove that field. You’ll see a warning message about removing fields in that case.
For additions, just add a new field and re-publish.
There are common ways people handle it.
Use an automation service, like Make (Integromat) to mirror your data into Airtable or Google Sheets.
User data is stored in a combination of places
(a) within the Webflow CRM (using forms)
(b) within Memberstack
(c) within Stripe
(d) within Hubspot
(e) within MySQL/CloudSQL (Google)
Architecturally I am trying to keep the actual data in the Webflow CRM at a minimum and using CloudSQL as the hub for the hub/spoke of various data locations. I am using the Webflow CRM primarily to generate unique page-URLs for members and multi-part-keys for user relevant data.
thanks I will read/watch that now.
I guess my question is does webflow have a clear demarcation between actual data that resides within each CMS table and the development assets; such as the page layouts, styling, data table attribute structures, animations, etc.
Brilliant. I will read these as well. I am using mySQL/CloudSQL as the DB.
Your questions go a tad bit beyond the norm. I’d highly suggest writing down your use-cases and then opening up a test project, applying them, and seeing how it works.
But for a quickie brain dump…
If you attach a domain to your project, then you do have a “clear demarcation” for the design. You’ll have a staging (webflow.io) environment and a live site (your-domain.com) production environment. You simply deploy to staging first, QA, then deploy to production. Make good use of backing up your progress if you ever need to rollback a deploy.
That’s your clear demarcation.
As for assets, they are shared between environments. Imagine 1, and only 1 s3 bucket for all your assets. Uploading an image into the asset manager is shared between all environments.
In terms of assets stored in your CMS, same thing is applied (asset manager) with the exception of being able to apply draft, staged, and production (published) demarcation between those rows (items).
For (a) you’ll need a glue service like Make (Integromat). For Memberstack you’ll get a lot for free.
My best suggestion for you is to setup a test project and run through all your use-cases to confirm. If you hit a snag or question with a very specific use-case, post it here.
Chris: I think this answers my biggest question. My (maybe over simplistic) interpretation of what you’re saying is that project specific assets; such as image and other files we may upload during development; as well as CMS data that entered; remains in a separate single place that is shared across any number of domains we add to the same project. Do I have this correct or have I just created a lot of word salad?
Yes that is correct, for domains you add as well as the default webflow.io domain they provide. I’d say for data entered into the CMS you do get that demarcation with each item’s status (draft, staged, published) but yes, it’s still shared.
welcome to the forum.