Wow thanks @Jean_Pierre_Traets for prompt answer!
I more or less figured out those 2 solutions already, but I was hoping more direct way were I can copy pages (and its content/subpages) from one doc and paste it on another. I have a section that has quite an extensive pages / subpages system set up in one docs that I just wanna copy this whole section to another doc that I create. The first solution won’t really work because the destination doc has already pages and sections. The second solution is quite tedious because I have quite amount of pages and subpages.
Regarding to the relation, those that will still work of course only need to be the ones that still have their tables in those pages that I copied. If one of the tables are missing (not copied), than the relation will just simply dosn’t work. It’s understandable.
I take it that there are no such a function (copy and paste across doc) for now. Hopefully the team will consider making it.
It was quite a shock coming to Coda from Notion and finding that I couldn’t move Pages to another Doc…even if they didn’t contain Tables or Lookups and simply contained markup.
The limitation really removes being able to develop a project or an idea in a fluid manner and then reorganize once it’s fleshed out. It forces full consideration and planning for where you want the content and functionality to live before you even begin to flesh out the idea…
In my early days of working with Coda (before being aware of this limitation) I had to spend hours rebuilding a complicated relational system from scratch because when you copy/paste those related tables to a new Doc, there remains “ghost relations and lookups” from the original Doc. I could see them in the Doc map but there was no way to delete them and it was confusing for the users.
This is where you would want to use CrossDoc to pull that information in and then write it back as needed
Unfortunately copying (solution 2) doesn’t preserve everything. E.g. formatting of “inline code” disappears.
This is one more reason to prefer to put all your data into a single doc if possible.
Yep… Just makes it impossible to develop a new “app” or “system” in private and then publish to the monolithic Doc when it’s done. Everything has to be developed within the live monolithic Doc.
Can you pull pages from one doc into another?
Dear @Evan_Bartlett ,
It’s not possible to pull pages from one into another, even when the docs are connected with “crossdoc”.
It’s happened with me to, right now!
I’m bringing all my things from Notion to Coda, and now I discover that move pages between docs is not possible. It will be very, very, very desnecessary hard work dispended to rearrange all things using this copy/past option as recomended by people.
Yeah, how difficult can it be to have a move to page thing? Just like google docs, or notion has.
We have many text pages that was added to a seperate doc, but it does not make sense to have it in that doc anymore. I should be together with another doc we use alot. So I want to move those pages, without having to copy text!
Is this in the product roadmap or shall I have to plan to do this at some point?
Another bump for this one! Move/copy should be a thing in Coda.
Cross Doc is awesome for tables, but doesn’t work for pages, so that doesn’t do the trick.
Please add my vote here.
Moving pages between docs and folders would be so nice. I’ve gotten spoiled by having that feature in ClickUp and Notion.
I am glad you mentioned that part about including all of the related lookup tables. Thank you!
I’m a Coda noob and this was literally the first thing I googled on starting to tinker.
I can’t conceive how this isn’t the fundamental consideration for Coda (like, how can anything be used without this functionality? As detailed above, the suggestions don’t actually work [as the OP, and I, intended] - am I missing something?)
Can anyone buzz someone from team to chime in here?
This has gots to be a team consideration, right!?
Same here. Coda noob. Have yet to find a diagram of container hierarchy for Coda (Workspace➞Folder➞Doc➞Sub-Docs➞Headings➞Paragraphs➞Indented Paragraphs?). I put my notes about “The Learn Doc” as a sub-doc in “The Learn Doc” and now want to move them, per standard note-taking, to be next to, and not part of, “The Learn Doc”.
Can anyone point me to a suggested “best practice” for organizing content in Coda?
I’d like to separate resources from notes and docs I create.
I want to publish or share some docs, and I need to control access to all docs and sub-docs.
“Best practice” is a nebulous term, because it will always depend on the purpose of your doc.
I’ll share a few ideas that I personally adhere to:
- Keep the document count to a minimum.
For my personal PIM, I have just one doc. In that doc is my “dictionary”, my list of interesting books, webpages, Facebook comments to get back to, my expense tracker, my contact list, my action list, etc, etc. And the topics keep expanding, e g the expense tracker has evolved into a rudimentary accounting package. For banks with CSV files, I cut and paste, for banks that do not, I parse the line in Coda. It can do journals. And report month by month. The list of webpages feeds into my “research” area.
What I do have separate is a Coda example doc, because I often share that with the community, and if course docs that I do for my clients.
- keep as much as possible in one table
There are two dimensions to this, rows and columns. As far as rows go, i have not come close to pushing Coda. People talk about 10,000 rows being ok, of course depending on the formulas and other recalculations in the table. If number of rows becomes a problem, just archive to another table.
With columns I find that people split tables to easily, a holdover from 3rd normal design. Much can be achieved with filters and views on a single table. So what if not all columns are always populated?
I would rather have one business partner table, than separate customer and vendor tables, for example. In another dimension, i would keep an invoice in one table, not a separate header and item table.
- if you think that you might want to copy a structure of tables in the future, keep them on one page. Otherwise I keep one table per page.
-it is also generally recommended to keep the tables themselves in a special “back office” area, and use views of those tables in the rest of the doc. It keeps things conceptually separate, and also allows you to configure characteristics that you want to propagate to all views of a table.
- overall, keep things simple.
But then we get into the debate on whether e=mc^2 is a complex or simple formula…
Thank you, @Piet_Strydom , for the simple, learned, usable advice , and for understanding my question better than I could have phrased it with my limited knowledge of Coda.
“Best practices” is nebulous. Perhaps I should have said, “guidelines for beginners”. I expect to fold whole biota from the sheets in my Workspace; those guidelines will become my best practices. For now, disarmed by blanks, my need as I examine my tools and layout my work table is more about not folding myself into a corner.
Good judgement, I hear tell, comes from experience. Experience comes from bad judgement. Thank you for shortening my journey by sharing your wisdom. I would get much from a sophisticated guidelines for beginners .
Thanks Kirby or your kind words.
Just to add to the acquisition of wisdom - They also say to study history to avoid repeating old mistakes. It allows you to make new mistakes…
Hiding Pages and Subpages is one (partially-limited) solution to this problem.
So far as the published doc goes, those hidden pages (or let’s just call them objects) will not be visible or available to users until you reference them somehow (@object… etc) or unhide them.
I sometimes use an approach something like this :
- Public Stuff (not-hidden)
– Sub Page of Public Stuff (not-hidden)
- DEV stuff (hidden)
– other hidden stuff
but you can also work less systematically
- Public Thing (not-hidden)
– Sub-Public thing that is ready (not-hidden)
– Sub-Public thing still in DEV (hidden)
It gets a little funky with tables and views but, generally, where there is a will there is a way.
Hello! This is now enabled via the feature update in this post: Launched: Copy a page to a another doc