[Pack] Add Page — As a doc owner, allow editors to add pages after 4.0


  • This pack will let editors add pages if a doc owner allows it.

  • I asked Coda before making this.

  • It removes the hard hit on wiki-heavy teams where editors want to make pages just for content.

  • That said, it’s not a replacement of upgrading. There’s plenty of motivation to become a Maker (or a Champion and get Coda for free :wink:).

  • I hope this is interim and Coda works on features to support the wiki folks better, e.g. by launching “rows as pages” eventually (an option to show canvases from a table as subpages on the left pane)


Coda 4.0 comes with a permission change: only Makers can now add and manage pages. While to me it makes a lot of sense, this change will make a lot of wiki people unhappy. They’re used to adding pages extensively not so much for “doc structure” as simply for “content structure”.

This pack is meant to be a temporary relief. It allows the doc owner to install a button that will allow editors to add pages to that doc.


  • Only the doc owner can install the pack
  • Can only access the doc it’s installed on
  • Handy autocomplete for the parent page
  • Autocomplete for page icons (default icons only, no custom icons — but you can always just type in the icon id)
  • Free & Open Source

This pack uses Coda API, which has endpoints for creating and primitively editing doc pages. These endpoints will be unavailable to editors but stay functional for doc makers. Since the packs platform is designed to make requests on behalf of the person who installed the pack and created the connection, this remains a valid way for a maker to consciously allow editors to add pages to their doc.

While this pack provides a relief for page-hoarding workspaces, it’s not a full replacement of becoming a Maker. There is no API methods to delete or reorganize pages — this is still limited to Makers only. And aside of that, there’s plenty of reasons to upgrade :raised_hands:

:orange_heart: A note on ethics

As one of the most devoted Coda makers, I want to see this platform grow and thrive. I understand and welcome that Coda wants to encourage more ‘passive’ users (viewers, editors) to convert to makers. But knowing Coda for a long time, I also know that they would never abandon their less-spendy audience. I’m sure the reason for this change comes not from the place of greed but to encourage better practices of working with docs. Paywalling isn’t a motivation to upgrade — if anyone wanted to game it there’s plenty of ways already (in the worst case the whole team could just share one login and password.) Offering the convenience of being a maker on your own is.

I’m also sure that until this change comes into effect in November, the team will keep on looking for a way to support wiki scenarios in a way that will be better designed than what we’ve had before. One of such features could be an option to display all canvases from a table as pages on the left navigation pane — I know this has been explored internally and I hope this makes it to the roadmap.

Lastly, before making this pack I ran this idea by Coda, and they were okay with it. This API capability is not going anywhere, so someone would’ve found it eventually anyways. There’s plenty of Coda API packs already, from generic (e.g. 1 2 3) to all-encompassing ones, which already enable this. I just made a specialized one that hopefully provides a little better UX than the rest, and also more security (by not allowing all the API modifications there can be but restricting it only to pages)



well done indeed @Paul_Danyliuk

the perfect balance between allowing an organisation to preserve the ability for editors to add pages, while restricting that ability to prevent wholesale abuse, and keeping alignment with the spirit of coda’s new regime.

and, as always, a very well engineered solution.


thanks, Paul!
I agree that having the option to show rows as subpages on the left pane would be a very helpful feature for a team like mine that is using Coda for content rather than for automations. While I know you can view a table using detail view, I find that engaging directly with a table is far less intuitive (and has a steeper learning curve) for new users who are more comfortable with google docs.

I will try this out :slight_smile:


As always, nice work Paul! :clap:

1 Like

PROPS to both you and Coda for green-lighting this!

While I’m not affected by the new changes, I can totally appreciate how editors feel about no longer being allowed to create pages.

While I initially felt isn’t it a matter of just ask the Doc maker “Hey Will, I need a new page…”, I can see where this could become a bit much if you have more than just a handful of users in your team, like in my case!

I feel Coda should focus heavily on Wiki functionality since (IMO), gorgeous, and easy to create Wiki pages (documentation) is a wonderful thing - especially when they’re easily viewable by the masses. :+1:

1 Like

Thanks all!

Wondering how bad would it be if I made the pack a symbolic $1/maker/mo “tip” but kept it open source so that folks who don’t want to pay could copy it for themselves and use it for free. Given that its audience is primarily teams that don’t have many makers (duh), it shouldn’t cost them a lot.

hey paul. I’m installing this now and am a bit confused. What is the difference between “private” and “shared” mode?

Oh, it’s a setting in every pack.

Private means that the connection can only be used by the person who created it. Every Coda user will need their own connection that will be used with that formula or action. Good example is a button to add an event to “my calendar” — for each person it will be a different calendar (their own) hence the button must be set up with a private connection mode. Every Coda user will then sign in with their Google Calendar account to press that button.

Shared means someone lets everyone else use their connection. E.g., this could be a button to send an email from a common “noreply” Gmail account. One person would sign in to Gmail with their “noreply” account and let everyone else press the button to send on their behalf.

With this pack, private mode doesn’t make sense, because the whole purpose is for the doc owner to let everyone add pages on their behalf. So choose Shared mode.

thank you! this was very helpful.

Sorry, another follow up question from a noob:

I installed the add page button and it works. But I’m not understanding how to set up the “rename page” button, since it seems you need to select which page you want it to rename when inserting i. Isn’t the point that someone can add a new page and then use this button to name that page? Or am I misunderstanding something? Does this mean that after an editor adds a new page, they must insert a “rename page” button on said page and then use it?

There’s plenty of optional parameters — including page name — that you can specify when you’re adding a new page. No need to separately rename:

To select the page to rename, choose the page here, and then also add the optional Name parameter


That’s a great pack! Is there a way to use the DuplicatePage() along with the Add page from this pack?

What should I do if I’m not getting the option to choose which page to rename?

similarly, i’m not understanding the rename function, as it seems you need to make a button to rename a page. but if said page doesn’t yet exist, how can you select it when setting up a button? It also seems like I would need to add these buttons to every single page of every doc, which is exhausting.

I made a page for my team that instructs them to use the button to create a new page and how I want them to set it up so I can just come in, name it, and move it and only have one button.

Interesting idea! If you are willing, I’m curious to see that page!

It’s just a short and to the point callout on a page titled “Add Page Workaround”

Thanks! You probably already know this, but if you want you can put that at the top of every page and set the button to make a sub page by selecting the page as the parent page.

1 Like

Hi Paul - I’ve been trying to use this pack (appreciate you putting this together!), but it takes ~ 1 min for the new page to show up in my doc. Same with renaming a page. Is that normal behavior?

@Julie_Duggins2 — yes, it is normal; that’s how making changes through the Coda API works. There is a delay.

Everyone else — sorry but the best I can do is offer the pack as-is. I won’t keep developing it, as I myself found it very frustrating to use and these days I’m just asking my clients to add myself as a maker temporarily so that I can do my things in their docs.


  • The parameters for renaming etc are there, they are just hidden in the dialog by default and you need to “add more parameters”.
  • The recently created pages may appear in the popup with the same API delay.
  • You can already specify a name when you create the page; no need to separately then rename it.
  • The create page action returns the ID of the created page, which you can store to a cell somewhere, and then use it to subsequently rename that page.

This pack was meant as a quick remedy for the wiki people whose need basically is just to add new (blank) pages somewhere in the hierarchy, e.g. add Pages to Documentation. For anything beyond that it is more frustrating than helpful. I do not have the capacity to keep developing this pack as I’m head over heels busy with relaunching my YouTube channel and everything around it. The pack is open source so everyone is welcome to examine its code, make copies and modify to their needs.

1 Like