Hey @Sebastien - that’s right. When you embed a form into a doc, users will be able to submit in view mode. You’ll be able to see their submissions in the intake table in your editable /d doc.
1 Like
I am guessing I can publish one Coda doc to a subdomain (codadoc.example.com), but can I also publish a second Coda doc to a second subdomain (anotherdoc.example.com) at the same time?
1 Like
Thanks for your answer @Glenn_Jaume. Any idea of when the edit feature will be released ? Even a rough estimation would help us on strategic decisions. We are building an application using Coda which ideally should be shared with customers under their respective brands.
1 Like
Yes, publishing multiple different Coda docs to different subdomains of a registered domain is supported
1 Like
I want to know this too!
I’ve been waiting for this. Thanks a lot team. I’ll give it a try. 
Now wondering how well the marvellous Encryption Template will work with “view-only” custom domains.
It could give a single entry point to clients on our own website to securely see their data 
Any incompatibility ahead, @Jono_Bouwmeester ?
1 Like
Honestly not sure, so I wouldn’t plan on it coming soon for edit based use cases (unless an embedded form works for you)
Hi Mohamed!
You can publish to subdomains, but not to a subfolder! Hope that helps :).
So does that mean a maker has to (1) create and publish a form, then (2) embed that form in the published site? Kind of a janky workaround, but I think I understand why. Can you confirm that’s the process? Thanks!
Jack
Hi @Jack_Beaudoin, yes - I can confirm that is the correct workaround. Thanks for double checking!
1 Like
I couldn’t find the answer to this elsewhere, so I’ll ask here. Is there an opportunity in published docs to offer “site search”? I love the advances Coda.io has made in its search capabilities over the years (still hoping for the ability to search attached files), and would hope that this could be deployed on a published sites.
Love this feature and have a ton of ideas to make use of it. One thing I’d like to suggest though, with regard to the publishing feature, is if your doc is set to Edit interaction mode, then it’s all fine if the user interacts at the custom domain, e.g., it doesn’t allow page edits but allows adding your own items to a table and blocks deletion of other people’s items. however, if that user now navigates to their main view of docs and goes into the published doc that way, they now can edit everything. Is there a way to prevent the doc showing up in their workspace? I would prefer not to have to get the Team plan for locking unless that is the only way to prevent unwanted public changes.
Hello @John_Li1 ,
I am noticing the following:
My doc, published to a custom domain, seems to be in play mode, regardless of the settings (View, Play, Edit). This is not a major concern for me (at this point in time), but is not correct.
Greetings, Joost
Hi, I’ve started a new topic in “Ask the Community” called How do I…? for custom domains. It might be good, for those of us excited about this new (and frequently requested) feature to share information and ask questions under one topic…
Cheers,
Jack
1 Like
Hi @John_Li1,
love the possiblity of publishing Coda-docs to custom domains! However, I’m running into a problem, as the published doc is solely reachable when a user types “testdomain.com” into their browser (ie without the www-prefix). When the user tries to access “www.testcomain.com”, they encounter an error message. More details below:
From Coda’s Help pages, I have gleaned the following:
Hence, I managed my DNS settings as follows:
- In addition to setting the A-Records as per the “Publish Settings” of my Coda doc,
- I also set the CNAME record for “www” to the root A-record as well.
- I have verified these settings with my DNS provider’s customer service (in my case, GoDaddy) several times, and received the “all clear, all settings correct, domain forwarding should now work” multiple times.
Needless to say, it still does not work (hence, my motiviation to write this post). In one of my many conversations with GoDaddy, I finally received the following instruction:
“The issue lies with the Hosting Provider. It needs to add the re-direction on their hosting server in order to for URL redirection to work on an individual website level”.
Now, blaming the other party is, of course, not an entirely new method of trying to resolve a situation.
However, please look into this matter and let me know if there is merit to it, and if so, if this can be rectified.
Thanks,
Nina
4 Likes
Same problems here, my redirection doesn’t work at all. My domain provider (gandi.net) support said that there is a problem with the SSL certificates.
Neither www. or plain domain work.
Any ideas?
I had the same issue and I think it is the way this is setup by Coda. I tried different things with the DNS and didn’t get it to work properly.
I found 2 solutions (better is 2 if you can find it in your hosting options):
- You can put a small file in the root http(s)docs directory to make this work:
index.html
- If your webserver management panel allows for it (I use Plesk)
where the default is often ‘None’
3 Likes