Block Level PublishingTeam, the all or nothing publishing model is causing me a lot of extra work (mostly planning etc.). I also can’t revert changes after publishing if something breaks.The ability to publish at the level of a single block would make it a lot faster for me to iterate on app changes. This can be a control in a block (e.g. publish me) or the publish button can bring up a list of all available blocks (by page) that have changes so I can check the ones I want to go live with. I can also update a page for just the page settings but not publish any blocks.
Full Site - update all
Page - update whole page
Update Page Settings - granular…
Block 1
Block 2
Block 3
etc.
Being able to see all pages and blocks that are new/updated would be awesome.If I can’t get this granularity, at least let me publish individual pages.
Dear @johntreadway, thank you for the suggestion, I added it to our feature requests list. Meanwhile, you can use the app unpublish button. We are also going to release the feature to revert the performed changes by the end of the year, if everything goes as expected
Until an actual feature comes out for this, there is a workaround. I wouldn’t recommend it for all use cases but it might be helpful in the specific case where you have a block or page that needs to be updated and republished way more frequently than the rest of the app.
What you can do is move it out into a separate app, and then embed it back in the original app. Then you can update and republish from that separate app.
Yes, that is the idea. I think one issue you might run into right away is that that a logged-in user on the main site will not automatically be logged into the embedded page/block, because the session cookie is going to be scoped to the main site’s origin, not the embedded site. I suspect there is a way for the main app to reach down into the embedded app and give it the session token, but I haven’t explored that.
Unpublish takes my whole site offline - that’s not a solution.
Revert is a partial solution and creates other issues. If that sets all of my changes back and doesn’t let me know which blocks and pages were effected, then that’s going to create a new nightmare. I might have done an emergency update to one block to make the site work and then it picked up work-in-progress when I hit publish. If I revert and lose all of my changes then that’s not going to be worth even releasing IMO.
Granular publishing is the real solution (per page or even per block). Minimally per page is the only really acceptable option.
Dear @johntreadway, I got your point and agree with you that a separate block publishing option would help a lot to see how that particular block would work while in live. In any way, we will definitely consider adding this option to Softr!
When I want to make changes to a site that’s not broken let’s say, I always duplicate or add new block and hide the old one. This way if the desired changes don’t work I delete the block and unhide the old one and continue as it was before.
Also you can duplicate your whole app and for big changes or overhauls put in the name v1, v2 etc. Publish to the same domain and if you ever need to go back you can with a couple clicks.
It’s not exactly what you want but it can help. I agree with you though, sometimes my adhd brain bounces around all over my pages constantly tweaking stuff only later to realize I broke something or didn’t finish a certain block until after publish.
I guess it makes sense why companies have QA testing before shipping, whether it’s physical products or code
I think a lot about how much I am not the target customer for Softr. There are a bunch of features I want in Softr that I know I am never going to get, because they are so far outside the target customer. So while I know I would really use the hell out of a feature to publish at a finer granularity, my best guess is that when you look at the whole customer base and specifically where Softr wants to grow, a fine-grained publishing feature is not in the cards. Not only because relatively few customers would use it, but because it would add enough complexity to the product that I suspect relatively few customers would be likely to take the time and effort to understand it well enough to trust it.
Put another way, the virtue of the current publish-all-at-once model is that it is extremely simple and easy to understand. And the virtue of the revert feature that is under construction is that it’s a model that can be found in other apps (Google Docs, virtual machine software like VMware and Parallels, Dropbox, etc.) and that users are also likely to “get” easily.
So while I really want fine-grained publishing, I’d rather Softr work on features that will increase conversion rates and reduce churn.
Maybe I’m not the target. I do come from an enterprise software background which makes me more sensitive to release management and QA issues than probably most here. As we move into a model where people can use other data sources (including real DBMSs), folks with my perspective may be more prevalent than in the past.
I don’t envy the product team and their need to prioritize different capabilities. I’d prefer better forms over granular release management any day - maybe I should say that
