Wt

Hi Nikita,

It is impossible to know the screen size of the client on the first rendering of your website when using progressive bootstrap. When progressive bootstrap is disable, Wt will first send small page with a script that will take information about the browser (like the screen size) and will then send those information to the server, which will then create the application. But when progressive bootstrap is enable, the application is first created in HTML mode when the first request is receive, and the script that collects information about the browser is send with that first HTML page. This means that when the application is created, the application cannot access those information this it was not yet collected.

It is possible to override the WWidget::enableAjax() function to adapt your widgets once those information are received by your application, so I suppose you could add a widget that constructs your website in WWidget::enableAjax(). But this would mean that user with JavaScript disable will not see your page and would be very similar to what Wt does by default.

Another option is to always create the same version of the website and completely recreate it in WWidget::enableAjax() if the wrong version was built. You could also try to guess whether it is a mobile user using information that are already available, like the WEnvironment::userAgent().

Your last suggestion appears to have the best solution with what is available.

Still nonetheless, it looks like the default bootstrap method is much more convenient from the perspective of what I'm doing here. Is this Progressive bootstrap mode worth the hassle? The library overview page lists some advantages and disadvantages of both, but they seem to be negligible, at least from the point of my inexperience with these kind of details. What interests me most at the moment is the search engine optimization. Is Progressive bootstrap any better for that, or they both do an equally acceptable job letting the web crawlers analyze the page?

Normally, this should not have any impacts as long as web crawlers are recognized as bots. This is because bots are always served on their first request, even without progressive bootstrap. The way a bot is recognize as such is if the user-agent is matched by one of the regular expression in the bot user agent list. That bot user agent list can be configured inside of the wt-config.xml file. You can see an example of what the list could look like in the wt_config.xml.in file that is already in Wt. Keep in mind that the user agents considered to be bots will only receive an HTML page and will therefor always have their screenWidth and screenHeight set to -1.

As for the impact it would have on search engine optimization if you don't have a good bot user agent list, I don't know.

So as far as I understand, these two bootstrap methods are there entirely for the browsers used by the human readers, and irrelevant for the web crawlers because they are served just the plain HTML file anyway, without any of the ECMAScript code. And because the bots receive the page devoid of any ECMAScript code, Wt does not get to execute the code needed to obtain the screen width and height, thus leaving the crawler session with the screenWidth value of -1. Which in my case, lands them on the path of the mobile version of the website, which is desirable, because it has the same data as the desktop version, but is much simpler. Are my assumptions correct?

And one other thing, given that the crawlers do not have the luxury of having the ECMAScript code, I can not rely on it at all in order for the page to be indexed properly by the bots, can I? Because I have some clickable widgets that spawn a WDialog instance when pressed, and that dialog has information that is supposed to be read by the crawlers as well. And since the bot has no opportunity to "click" anything, given the lack of ECMAScript, it can not spawn the dialog and reach that data, which is bad for indexing of course. Are these assumptions correct as well?

So at this point I suppose I might as well pack the website's information into an additional third version specifically for the bots (calling WEnvironment::agentIsSpiderBot to choose the third path) and maybe that occasional odd user who has the ECMAScript disabled. It won't have any of the bells and whistles or styling that I came up with, but pretty much just the plain HTML text.

Your assumptions are correct.

Just one precision: WEnvironment::agentIsSpiderBot() being false does not mean that the user has JavaScript enabled. Those occasional odd user with JavaScript disabled would therefor still access your mobile website.

Thank you very much, that clears it all up!