I know I know… but I don’t want to pay for that feature at this point. Sorry @gaimed maybe one day if Bubble can’t get it done.
2 Likes
@aj11 @grace.hong @manasi
It is not worth much of anything in my opinion just reading what it does.
It sounds like it is a way to ‘cut down’ on the number of conditional workflows used in a reusable element to navigate to a specific page, based on some variable used in the reusable element that previously would have been put into the conditional expression of the ‘go to page’ navigation action. So, instead of having to set up say 5 different go to page actions with a conditional expression on each to determine when to go to what page, you can now have a single go to page action with your variable being placed into a dynamic expression for the page to go to. But of course, with the limitation of not being able to send data to a page when using the dynamic page expression, this feature falls flat on it’s face and is unable to deliver any conceivable benefit to a developer.
IF the feature was focused on a larger pain point of clean URLs for SEO purposes, to address issues of data to send and appending values to the URL path list so that we could say ‘go to page’ and use the send data to page input and have a NEW function to send URL path list items so that we could more easily create navigation functions that can send in the page data as Slug with trailing path list items, then that would be beneficial.
Also, if there was an ability to use the URL get data function to extract values from the URL (whether parameters or path list items) and have Bubble recognize the SLUG value automatically, rather than the current limitation of only recognizing the unique ID value, that would be a beneficial feature too. This should not be a heavy lift as Bubble already does that for the path list item when using the page content type. You can when using a page content type send in the value as a SLUG or Unique ID and Bubble can automatically serve up the corresponding database entry. It should work that same way when using the Get data from URL function if we specify the type of data as a custom data type…the reason this would be helpful is that we can more easily add path item lists as human readable (unique IDs are not human readable which led to the implementation of Slugs back in late 2020/early 2021) and would not need to rely on doing searches to capture the correct content if we don’t use the unique ID in the URL path list item.
Some areas that need attention from my experience and fools errands of attempting to get my pages to be more performant when working with URLs from SEO purposes, which in my limited understanding of real code and complete lack of experience of how Bubble is actually setup, I feel may not be very heavy lifts to implement.
- Greater control over the creation of URL parameters and the REMOVAL of URL parameters in the Go to Page Action.
- Greater ability to append URL path list items in the Go to Page Action.
- Ability to use the Get Data from URL function and have slugs recognized to retrieve the stated data type of the parameter/path/path list item without a need to do a database search (much like how unique IDs are automatically recognized and serve up the correct database entry)
- Ability to use the Get Data from URL function everywhere a datasource is require for dynamic data…there are areas in workflows where the Get Data from URL is not available and we have to setup the expression somewhere else and then copy and paste it. Also, it is not possible to use it in the page SEO areas such as Meta Title, Meta Description, Page Headers.
- Enable URL path list items to be automatically URL decoded the same way URL parameters are automatically decoded. It is not possible to use URL path list items in dynamic conditional expressions if you do not provide the URL encoded value, because when you use the Get data from URL and select the path or a path list item, it is not URL decoded upon extraction, so any dynamic expression in a conditional that refers to that path or path list item is not recognized if you the developer have utilized the URL decoded value in the expression.
Another area that could be improved that may be a bit more of a heavy lift to implement, but would have beneficial impacts, especially for multi language apps, is the ability to move the position of the page name in the URL path list so that we can have a language identifier in the beginning of the path list.
www.myapp.com/en/page-name
www.myapp.com/sp/page-name
7 Likes
Hey all - Thank you for all the feedback on the feature! The original problem we intended to solve here was to allow for users to change URL params from reusables without reloading page or using multiple conditionals, and the ability to dynamically specify the page became an add-on we thought to include. However, these ideas around being able to more dynamically manage/send URL paths provide helpful context on how we want to refine this feature. Will make sure to clearly understand this problem and provide an update when I have a solution!
9 Likes
Please take inspiration from this plugin. It’s the most comprehensive plugin in Bubble that solves all issues related to dynamic URL changes and other features for SPA apps: Sudsy Page Plugin | Bubble
4 Likes
That makes sense, always appreciate your perspective on things!
Sudsy is great, this is what I currently use.
1 Like
Could you please make a very simple example on what you mean when saying “The original problem we intended to solve here was to allow for users to change URL params from reusables without reloading page or using multiple conditionals”?
I really don’t understand it and an example would be help me to visualize what you meant. Thanks a lot!
It was always possible to change URl parameters from reusable elements without reloading the page…all that was needed was a go to page action. I suppose what others might have done is used link elements which would cause the page to reload.
What this new feature does is allows you to dynamically set the page to go to…which you could have done anyway with just a series of workflow go to page actions and conditions; so basically instead of multiple go to pages, you can now just have one. BUT, the major issue is the new feature when using a dynamic page name doesn’t allow for the use of the Data to Send value.
Personally, I don’t have any intention of using this feature and will just stick with the old way of doing the same thing ( I personally don’t care about setting up multiple go to page actions since I often need to send data to the page ).
6 Likes
At last! That’s amazing, thanks 
@grace.hong Is it possible we could get the “Replace entry in browser history” option available when referencing “Current page”? A URL parameter could be used for on-page navigation (like different tabs, etc) and the UX is a little weird because pressing back on the browser would be going back to previous different tabs on screen. By enabling the browser history replace we could control it so going to a previous page would ignore all those tabs being pressed. 
2 Likes
@grace.hong Also could we have the option to append some arbitrary text in case we need to do an anchor at the end of the URL? (Without refreshing the page by using the External Page option). Or if the Current Page does have a datatype we can just append /[uid of something]. Maybe options to add text between the domain and the parameters, then another box for after parameters?
Also it seems when copying an action referencing “Current page” and pasting it in a different workflow on a different page, it invalidates the page selection and you have to reselect “Current page”.
Thanks 
2 Likes
yes yes yes yes yes yes (obviously?)
Like others have said, this feature NEEDS to have the ability to pass data in. Anyone with a SPA is passing path as Arbitrary text to do routing and that’s the only time where I need this. Would help reduce tons of conditionals if you added this option - pretty please!
@manasi When can we expect the feature to be fully realized and add in the much needed ability to use ‘current page’ or ‘dynamic page’ while sending in data?
I was just putting together bottom navigation for an SPA and need the go to page to set the view through URL path manipulation…wanted to use ‘current page’ because that would be awesome to actually be able to use it, and realize it is unusable because it doesn’t allow for sending in data, which is needed to manipulate the URL path.
OR, is there going to be a release of the ability to not only manipulate parameters but also path list?
Would really like to see this new feature do what most experienced users have requested over the years and more recently in this thread.
1 Like
This may not address the SEO issues, but this is really useful for people like me who make heavy use of URL params. I have a lot of reusable modals which are opened via URL params and communicate with the page in this way. Previously the page selector was a dropdown so you couldn’t dynamically say “Add these url parameters but stay on this page”. You needed a list of conditional actions for every page on your app. And if you added a page you needed to change that. Totally sucked. This is a very welcome improvement even if it’s relatively niche!
1 Like
Hey all - just wanted to provide a quick update. We’re currently shaping out the feature for modifying URL paths (and broadly thinking about how this would work with sending URL params too)!
6 Likes
It would be greatly appreciated if you can figure out how to allow us to have URL.com/[path like username] on the index page without displaying index in the URL (currently it always shows URL.com/index/[path...]
Here you can see many others requesting the same
http://forum.bubble.io/search?context=topic&context_id=253759&q=Remove%20index%20from%20url&skip_context=true
1 Like
When the native app option is enabled, could the system be modified so that if the “Go to page” action’s destination is the current page, the error message “Go to page … - Change page actions should not be used in a native app page” does not appear?