[UPDATED v2.2.0] 😃 Sudsy Page router for SEO-friendly clean URLs! (by Tech-Tonic)

[sudsy]

@boston85719

wouldn’t this mean that the sudsy plugin does essentially work for IE as long as the link structure is set up as “external url”?

No. Forget about the word “external”. Think only about the actual resulting URL - i.e. what you would see as the value of the hyperlink’s (<a> tag’s) href attribute if you examined the page using the browser dev tools. If that URL points to the same page on which that URL resides, it won’t work in IE.

For instance, if I’m on the following Bubble page…

https://my-cool-app.bubbleapps.io/**users**

…where users is an actual Bubble page displaying a list of users, and I click the following link on one of the items in that list because I want to view detail about user Johnny…

https://my-cool-app.bubbleapps.io/**users**/johnny

…then nothing will happen in IE.

What will happen in supported browsers is that the page will be “notified” that the URL has changed, and that can be used in a conditional or workflow to, for instance, display an initially-hidden group with detail about “Johnny” - i.e. the list would disappear, and user details would be shown.

(As I said, though, no IE behavior is guaranteed moving forward, as IE is simply not supported. With regard to IE, I’m just relating what I’ve observed empirically with the current version of the plug-in.)

[boston85719]

Thanks for taking the time to explain it in detail. I will probably be making a purchase for the plugin soon as I want to enable a user to use the browsers back button to show a previously displayed group during an on-boarding flow.

I’m also planning to use it for pages with tabs that hide/show different groups, in case a user presses the back button it doesn’t go to a different page, but just shows the previously displayed group.

I think it could also be utilized for a search results page. I use custom states for the filters to narrow down search results on business listings which are lost when a user navigates to a listings page, so if a user presses back button on browser the search filters are “reset”. In my mind I may be able to find a way to eliminate the need to have the listing page open in a new window to save the search filters.

[sudsy]

@boston85719

I want to enable a user to use the browsers back button to show a previously displayed group during an on-boarding flow.

Absolutely.

@boston85719

I’m also planning to use it for pages with tabs that hide/show different groups, in case a user presses the back button it doesn’t go to a different page

That should work no problem. I’m doing it in an app I’m developing. Aside from the friendly URL and SEO benefits, it also improves the mobile (i.e. low bandwidth) experience since data aren’t re-fetched during browser navigation.

@boston85719

I think it could also be utilized for a search results page.

Absolutely. Query string parameter support was added in v2 for just that reason. For instance, here are a couple deep links to the results for various search terms in the blog demo…

• All blog posts containing “jedi”
• All blog posts containing “money”

Also, type any word into the search box and press return to see the results. Then, use the browser forward/back buttons to see that the page does not reload (server is not hit again).

[boston85719]

Awesome…definitely seems like a must buy

Appreciate all the explanations

[nicedwar]

Hi @sudsy.

Any update on the Users Demo?

Currently I’m working from social examples on the forums here, but seeing some issues with the back button that it seems your plugin might solve. Just wanted to make sure there aren’t any major hurdles to using Sudsy to navigate to user-created profiles. Thanks!

[sudsy]

@nicedwar

Any update on the Users Demo?

Thanks for pinging me about this, @nicedwar. The lack of a demo is due solely to my not yet having taken the time to create it - not to any technical “hurdles”. (Been focused on other projects for the past 3 weeks or so.)

In fact, I’m using it that way in my own Bubble app. That was one of the motivations for creating the plugin in the first place. I know there’s at least one other Sudsy user making use of it that way as well.

That said, I’ll try to get a demo up over the holidays. Plus, I’ll post to this thread tomorrow with an outline describing the basic approach.

[petter]

Hey @sudsy,

Thanks for a great plugin!

One question. I think I know the answer, but just wanted it to be “definite” the IE incompatibility is caused by ‘core’ functionality in the plugin, meaning that it will never work for IE, even in future updates?

For most projects that’s not a huge thing, but for some, like eCommerce projects (where a big enough percentage of users still cling on to stoneage technology…) it may be worth thinking about.

[sudsy]

Thanks very much for the feedback, @petter. I appreciate it!

As for IE, it simply lacks an underlying browser API being leveraged by the plug-in. I did identify a way to possibly make it work (effectively patching the missing functionality), but implementing it would be non-trivial.

So, unless plug-in sales justifies it or a prospective customer is interested in funding the development, it probably won’t happen.

In short, it might be technically possible, but
there are no plans to pursue it, and it seems unlikely. With each passing year, IE becomes less and less relevant anyway. (Thank goodness!)

[sudsy]

@sudsy

I’ll post to this thread tomorrow with an outline describing the basic approach.

As I was starting to do this, it occurred to me that the Quick Start portion of the Sudsy docs already steps through the process quite well. Be sure to carefully read the sub-sections:

• Summary of Steps
• Important Points
• Path Params Note

The only thing I would emphasize in the context of a social sharing URL is that the onus of ensuring valid and unique usernames is entirely on you, the Bubble developer. In other words, when someone signs up on your site, you’ll need to make sure they choose a username that is not already in the database and which consists only of characters that are valid within a URL. That will ensure that the username can be used to retrieve user-specific data from the DB.

As for browser back-button functionality, that should work just fine while navigating your site if you either use hyperlinks or make sure that the Preserve history option is enabled when using workflows for navigation. (Using hyperlinks has SEO benefits, so that approach is generally preferred.)

If you have any other questions, let me know.

[nicedwar]

@sudsy,

If I’m not totally single-page with my app, what is the best way to keep Sudsy playing nice with data coming in across pages?

For example, if I have a blog posts/ page, I might click on a writer’s name to and navigate to a totally different page, like users/. My "Data to send" from the posts/ page is a specific user, and my users/ page’s "Type of content" is User.
I then might have a text field that dynamically displays "Current Page User's email", or maybe all that users blog posts, which might navigate back to posts/ page.

Once I’m on the users/ page, I get how I can search users, display their info, and modify the URL path, but it doesn’t look like Sudsy is able to modify the Current Page User? So once I come in this way, would the initial Current Page User be stuck while Sudsy is doing SPA stuff, displaying different user info over the top?

Or should I be coming in a different way, with a URL query and custom states?

I’d like to avoid going totally SPA with lots of tabs and hidden content on one page, if possible.

[sudsy]

Hi, @nicedwar. My app is not a SPA either. Like you, I created different “sections” of the site - e.g. account, users, etc. - where each section is a Bubble page implementing multiple unique “endpoints”.

As you know, Sudsy works per-page. You can be selective about which pages use it. You needn’t add it to a page if you’d rather use Bubble’s built-in mechanisms.

@nicedwar

My "Data to send" from the posts/ page is a specific user, and my users/ page’s "Type of content" is User .

@nicedwar

it doesn’t look like Sudsy is able to modify the Current Page User ?

I don’t think that has anything to do with the Sudsy plugin. I believe Bubble simply treats pages with a defined Type of content in a special way. The data for such pages can’t be set by the Bubble developer; rather, Bubble attempts to handle it internally. (Technically, Sudsy doesn’t “modify” anything anyway. It simply posts events and publishes states, enabling you to implement workflows based on that data.)

That said, following are a couple ways to deal with the scenario you describe. The first allows you to keep Bubble’s “data-passing URL” on the referring page - i.e. the page with the link which passes the User object - whereas the second approach enables you to choose the URL you’d like to use to pass the user. I would recommend the second approach, as it’s just simpler since you have explicit control over the URL used to “pass the User object” to the target page.

• 1st Approach: On the destination (User) page, instead of defining the Type of content for the page itself, create a “Page Content” group which contains all the page elements, and then set Type of content for that group to User, and then initialize that group’s data like so…
  

  
  
  Note that the condition on the event ensures the workflow runs only when the plugin is initialized, which (if the plug-in is at the page level) is basically on page load.

• 2nd Approach: Design your own URL - perhaps utilizing a unique username (instead of Bubble’s internal unique ID). So for instance, if you implement the following URL…
   
  https://mydomain.com/users/johndoe
   
  …then the data on the target (User) page would be initialized in much the same way as above, except that the DB constraint might be something like…
   
  Username = This SudsyPage's Path Params:item #2

Does that make sense? If you have further questions, let me know.

(p.s. If you are working with the plug-in, I’d prefer support requests be posted to the plugin help / support forum. Otherwise, this product announcement thread starts growing with content not directly related to the product announcement. Plus, it’s easier for others to find help if posts are topic-specific. Putting “Sudsy” somewhere in the subject line of your post will help bring it to my attention.)

[philippe1]

Thank you!

Is it possible to have first level folders used to switch the language of the page ?

like app.co/en/page - app.co/fr/page ?

Thanks

[sudsy]

@philippe1

Is it possible to have first level folders used to switch the language of the page ?

like app.co/en/page - app.co/fr/page ?

Hi @philippe1, that’s a great question. Let me preface my remarks by saying that I have not created a multilingual site myself, so I’m not up to speed on best practices.

That said, what you’re asking is certainly possible, but I’m not sure it would be the best way to proceed. Why? Well, the first “folder/level” following the domain name MUST be an actual Bubble page, so you’d have to create a separate page for each language you plan to support, and that might or might not make sense for your app.

An alternative approach might be to have the language identifier be the 2nd URL parameter instead. So, considering a non-multilingual user profile page like the following…

• app.co/users/janedoe/profile

…instead of…

• app.co/fr/users/janedoe/profile

…it might be something like…

• app.co/users/fr/janedoe/profile

In this example, “users” would be the actual Bubble page. The rest of the URL could then be used to determine what to show, including which language. So, the above would display Jane’s profile, and the following might display a contact form to message Jane…

• app.co/users/fr/janedoe/contact

And the following could display a list of users…

• app.co/users/fr/

That might not be desirable. I don’t know. Plus, you might have specific requirements and/or preferences for your URL structure, but I wanted to make sure you understood how things work.

So, in brief, what you’re asking is technically possible, but it means a separate Bubble page for each supported language would have to be maintained.

I don’t know if that helps, but if you have any other questions, let me know.

EDIT: BTW, a page in Bubble can have a single character name, so the following is a valid URL as well…

• app.co/-/fr/janedoe/contact

So, the URL structure is entirely up to you and limited only by the fact that the 1st URL parameter must be an actual Bubble page. So you should work out the desired URL structure first, and that might be guided, in part, by whether you’re creating a single page app (SPA) or not.

[philippe1]

Hey Thank you !

This one was indeed out of the table as I have MANY pages.

So either I use a querystring (meh but “normal”), either I use a very unorthodox path like

app.co/product/product-name/fr

[sudsy]

Yeah, that’s all that comes to mind. If something else occurs to me, I’ll let you know.

I’ve not delved very deeply into Google Translate, but might that or a similar service be an option? Seems like it might have the potential to make page maintenance easier.

[philippe1]

For good SEO I need clear urls for the localised versions of each page

[sudsy]

Sure, but I don’t know if that necessarily precludes the use of a translation service. Again, I have not experience with a multilingual site, but I’m just thinking in terms of ease of maintaining the content.

[philippe1]

I realise we didnt discuss subdomains, but I guess there wont be a great solution there either. I’ll probably go with querystrings until something better is available…

[di_lucena]

Hey Shot

I Have been considering using the power of sudsy page plugin but thinking of how to keep the IE users included…
I have my app configured to navigate within the page based on custom states that show/hide elements.
So, if I keep these workflows and implement the sudsy page URLs navigation, would that be a possible strategy to let IE users still have a functioning app?
I am guessing the sudsy actions wont work but the states will be doing the job in this case.

Am I wright?

[di_lucena]

@sudsy