I would like to suggest a new feature and discuss it.
I was surprised that I haven’t found a similar post in the forum, but maybe I was looking in the wrong place. If one already exists, let me know
Suggestion:
Option to only publish individual pages
Why?
Especially when several users are working on different pages/features at the same time, publishing the project would take unfinished states live
Pages can be rolled back to earlier versions individually without reverting changes to other pages
If a critical error is found on a page, it can be fixed specifically and taken live immediately without the risk of unintentionally changing other parts of the project
Option to only revalidate individual pages when publishing changes (currently we call an API endpoint in Next.js with the Publish Webhook and revalidate all pages)
There are certainly other advantages, let’s discuss them in the post.
If there were significant decisions not to implement this feature (yet), please let me know.
Hello @michaelb, you can hide work-in-progress pages by prefixing their names with an underscore. Learn more here: Pages | Learn Plasmic
Plasmic also offers a Branching feature, available exclusively to enterprise customers upon request. This enables your team to work on separate branches, ensuring that only production-ready work gets merged into the main branch. Learn more here: Branching | Learn Plasmic
We’re already on the Enterprise Plan and using the Branching feature for development purposes (when we introduce new code components / registrations). We are referencing the Plasmic branch in code when loading the project (with initPlasmicLoader) and that is based on the git branch name - so we have a reference between code branch and plasmic branch. We can then deploy our code branches to different deployment environments (dev/test/staging) and we can test new features seperately without affecting the “main” Plasmic branch. When testing is done, we move changes to the main branch and publish the whole project.
Our marketing team and other team members that are responsable for making layout / design / text changes for the deployed website do these changes directly on the main Branch in Plasmic and publish. I think forcing them to create branches would feel like a step away from ease (when just swapping out a picture, change a text, or create new banner / text blocks). It’s more related to multi-user editing experience.
Also, the branching feature is still in beta (as far as I remember) and the “merge from main / merge into main” is sometimes not working correctly. E.g. when I have a branch created a couple of days ago, and someone added a new page in main - when merging back to main the new page is marked as “deleted” and get’s removed as soon as I merge.
I remember a message from Jason about when he enabled branching for us
Do note we have some known issues with merging that we are currently working on fixing and improving.
The approach we use for branching is different as for my understanding.
I just want to make sure that it is correctly understood what my feature request is about. Perhaps other users / organizations that use branching could comment on how they currently use the flow.
We see the branching feature more as a way to make new code components / registrations available in the app and to develop outside of the “main / production” state.
By multi-user editing we mean working together, simultaneously on the project (as is currently the case in the productive main branch). If changes are made simultaneously by different users on the productive state, there should be the possibility to publish individual pages separately, rather than the entire project.
I just want to give an overview of how we - and possibly others - use the tooling and to simplify it for our daily work.
I just wanted to get sure that my request is understood in general, because this is a crucial part of our workflow which would significantly improve. If you need more information, please let me know.
Currently all our versioning and branching works per project and not per page. I think the best way to achieve what you’re trying to do is to create separate projects for a page or set of pages that you want to version independently. Then, your app needs to be configured for the multiple projects. Both our codegen and loader methods are designed to work well with multiple projects.
I don’t think multiple projects would fix the problem for us, since then I would need a project per page, and that’s definitely inconvenient for us developers, but also for marketing team and other departments that are working on the projects.
Maybe you will be changing that in the future, as when other people also rise this request. But for now we may continue having a detailed look on the changes, which pages are affected, before publishing the project.
Is there a way flagging pages when calling a revalidate Webhook on publish? Currently we need to revalidate all pages, even though only one page changed.
Yes it’s a bit inconvenient to make a page per project. Other teams have made projects per group of pages instead, which only partially alleviates the issue.
We’ll look into flagging which pages changed during a publish and get back to you.
