I'm looking for a way to support SEO for content which is loading via AJAX. My site handles urls for example: www.example.com/part/{number}. Then on a homepage JS executes AJAX request and receives a content. Inside the AJAX callback the pushState is used.
Will the Googlebot respect dynamic content (without duplicate) if the homepage has always the same content? If not, are there ways to do that?
Will the Googlebot respect dynamic content (without duplicate) if the homepage has always the same content?
Probably not (although they do pay some attention to JS these days).
If not, are there ways to do that?
Use pushState properly. When you change the URL with it, have the JS change the DOM to reflect what the server would deliver if the URL was requested.
Don't load the default content, then examine the URL with client side code, then modify it. That defeats the object of pushState and you might as well go back to the bad old days of hashbangs.
Related
Thanks to HTML5's extension to the Javascript's History API, Javascript developers now enjoy greater control over the browser's history and can even change the state of a given page and provide a bookmarkable address to their users without having to reload the page.
On the PHP (or server-) side, however, things are a little bit different. Take the following URL as an example:
http://somesite.com/?user=8796&fname=john&lname=doe.
When the user first navigates to this page, using PHP, a PHP developer could access the information passed in the URL on the server-side using the GET super-global, e.g:
$user_id = $_GET['user'];
$user_firstname = $_GET['fname'];
$user_lastname = $_GET['lname'];
Now, upon the click of a button, or any other user-initiated event, Javascript code kicks in, using the History.PushState method and changes the query string parameters, so that we now have the URL like so
http://somesite.com/?user=7647&fname=jane&lname=doe.
For a Javascript developer, they can retrieve the query string parameters by parsing the URL and updating the page's content accordingly via AJAX. Not so, however, for PHP. The page has to be reloaded for the PHP script to have access to the just-updated query string parameters.
Is there a way it is possible, even if remotely or theoretically, for PHP to gain access to a URL/query string created with Javascript's History.PushState method without having to reload the page, and without the intermediary of AJAX?
The History.pushState() JavaScript API runs in the browser. PHP runs on the server. So there is no way for PHP to know about the new URL and query string without JavaScript letting it know over the network somehow. The obvious ways this might happen are for the user to reload the page or for the web page to send an XHR/AJAX request to the server.
#Pointy mentions WebSockets, and there may be other ways to send information to the server, but without knowing why you want to avoid AJAX (which seems perfectly suited to this task), it's impossible to say if something else would meet your needs.
If you call History.PushState you are manipulating the browser history. Nothing is sent to the server.
Using history.pushState() changes the referrer that gets used in the HTTP header for XMLHttpRequest objects created after you change the state.
[Mozilla Developer Network]
The server will not know that you appended anything. It is like changing the background-color with JavaScript. You have to make a request to the server to let it know about what you did in the browser.
It seems right to make an AJAX request at the same time that you History.PushState the browser.
If you are doing navigation by History.PushState and AJAX calls, I would encourage you to read AJAX Navigation Example at Mozilla Developer Network which is written with JavaScript and PHP.
Make sure to remember about the limited support for History.PushState.
So what the title says. Can I check a website's server/database (Or whatever it is called, sorry I'm new to coding) for changes made to the website so I can implement a reload and then implement my code.
In your site's JavaScript you can make small requests back to your web server without reloading the whole page, then take some action; e.g. change the content on part of your page, or maybe navigate somewhere else. You can choose a specific URL to request data from. The common way to structure things is using REST and JSON.
The regular part of your site would live at www.example.com/myaccount, etc., and your REST API would live at www.example.com/api/account/posts?dateafter=blah. You can use client-side JS libraries like JQuery to send requests up to your REST API, deserialize the resulting JSON into JS objects, then take action.
On the server side, various frameworks will help you build APIs, with appropriate routing. It depends what kind of hosting, language expertise, etc. that you have.
I wanted to load HTML contents dynamically, such as updating a Bootstrap's modal dialog contents via AJAX call (because refreshing the page and showing the modal again is weird), but before I do that, I want to know what risks that I will need to concern when doing so, and possible solutions.
The main reason to do this is that I'm developing a portlet for Liferay, and I wished to update the content of my portlet dynamically without refreshing the whole page.
Of course I could return data in JSON from my server to client, but I will have to write complex client side logic to update the DOM, which the logic is probably done easier in, say, JSP
Assume the webapp is HTTPS only, not sure if this will help with anything.
Based on the assumption that the webapp is HTTPS only, it would be very good to let all AJAX calls also use that. This will not create a breach of mixing unsecure and secure connections, and the warning dialogs, which browsers give.
The only risk can be caused by cross-site scripting, if parts of the HTML is generated elsewhere or if parts of it is based on unvalidated user input.
Solutions for that is to always validate ans sanitize the input from other sources. More information about this can be found here: https://www.owasp.org/index.php/Data_Validation
Perhaps you chosen the wrong framework for the job and would have consider something like an client side rendering where you would bind json data to the view (eg: angular, ember, backbone or knockout)
Consider using Element.innerText or $(Elm).text() instead of Element.innerHTML or $(elm).html() when possible
Perhaps it will be a good idea to encode everything that a user can change before you save it to the database or when you are rendering the view
However if you do allow some html you would need a sanitize plugin with a witelist approtch to strict the allowed tag & attributes
the only diffrence with http and https is that it will be much harder for a man-in-the-middle attack to read/intercept/change the content of the request & the response
I'm going to be creating a widget style tool that will work as follows:
It can be included in any page by putting a script/button combo on that page.
The button, when clicked, will load a form from my site, which can be filled out and submitted.
Depending on the submitted information, there may be another form displayed - for example, a second page with a captcha, or a confirmation page with some action required, or maybe just have the form close, or some other action I add later.
If I was to open a popup window, this would be easy, just build it as a regular page. However, including this in a calling page, presents a few issues.
If I actually load the form content into a local div on the calling page, it becomes part of the page content. I know I can manipulate that content to some extent using the script (it will load a script from my site for that particular version of the widget), repost forms and load them into the same div, hide the div when I'm done with it, etc. But it seems like it would complicate things.
My other option is to make it all happen in an iframe, so it's not really part of the loading page calling page. This way I sort of feel like I'm losing some functionality I may need later. This is probably the way I will go anyway.
However, before I start down that road, I thought I would ask if anyone has any tips on the best way to include a complex series of pages in another page?
Whatever I do, I want to be sure I don't close doors on my ability to change the way the widget functions, I will definitely be adding functionality later - so keeping my options open for change is important.
Thanks!
Edit
Regarding JotaBe's question, on the server side, I will be using PHP.
However, I'm pretty sure that doesn't matter, as the PHP processing will (as always) happen on the server. All the client (requesting page), will know is that it requested, and then received JS/HTML/CSS/JSON/ETC assets via HTTP. It won't know, or care, how the server generated those resources.
If it helps you to picture it though, this is the basic idea of how the client and server will (if I don't think of a better way) work together:
The client page will (at load) request a .js file from my site. This file will be generated dynamically based on the requested URL. For example, account #74 would request http://mysite.com/widget/js/74.js and receive JavaScript assets customized for that account.
When the "widget button" is clicked, it will use the JavaScript to request an HTML form from my site, and include it in the page, one way or another (which way is best is the whole question). The HTML form will be generated dynamically and customized for account # 74 based on the request (ie: http://mysite.com/widget/form/74.php).
Once filled by the user, the form will be submitted to my site. The post will be processed and stuff will happen, again based on the requesting account (ie: action=http://mysite.com/widget/post/74.php). At this point, I may need to reject the form and request a re-post for failed validation, captcha verification, etc., or I may need to serve a confirmation page, or simply close the form, or some other action.
Any way you do this (language / platform / etc), the best practice is to use mvc, or hmvc, to keep the various logical components of the application separate. You can create popups by having some view templates which don't render their containing tags, designed for javascript / jquery .load() statements. You could then design a series of components designed to be loaded with arguments passed over the uri.
here is an article that might help explain one possible design pattern for what you are going for:
http://www.phpied.com/ajax-mvc/
Looking at turning my ASP MVC app into pure JS/Html however its not just a 1 page app, it has a couple of pages, but each one has alot of ajax and events.
Anyway currently my urls on ASP MVC are like:
/login
/admin/{action}/{adminId}
/posts/{posterId}
/picture/{pictureId}
So that is all nice and simple and easy to see what you are doing in the url, you also get correct back button behaviour. So trying to adopt this sort of thing to a pure JS/Html approach seems to bit either very tough or impossible. I dont need an exact match but I was hoping to do something like:
http://localhost/myapp/posts/10
Then that would somehow be able to route the actual request to http://localhost/myapp/posts.html with the variable exposed. Now I am pretty sure this is impossible as when the above is entered into the browser it is going to attempt to look in a directory called posts and look for 10, which wont exist.
Now I have seen Crossroads and LeviRoutes and a few other similar technologies, however they seem to rely upon the hashbang method, which some people like others hate. Is there any way around this? If not can anyone point to any good tutorials on how to use these frameworks, as each seems fairly light on documentation.
There's no workaround for not using hash. HTML5 History API isn't available on IE and Opera yet. If your application is targeting very specific platform, then you can use History API instead of hash. However, History API is inconsistent across browsers. You can read it here: http://www.battlehorse.net/page/2011/02/12/html5history.htm
If you choose to use History API, it would be easy. You can use whatever routing strategy you want in ASP.NET MVC, then just match this strategy in JavaScript. You can read more about History API here: https://developer.mozilla.org/en/DOM/Manipulating_the_browser_history
If you choose to use hash, you need to do make some requests into AJAX requests:
Determine if a request is done via AJAX:
if GET/posts/{action}/{id} is by AJAX, serve the original content
if it's not by AJAX, redirect the user to /#!/posts/{action}/{id}.
Handle client side hash by requesting for the right content:
When the hash is changed to #!/posts/{action}/{id}, GET /posts/{action}/{id} via AJAX and replace the content with the new one from the server.
Intercept form.onsubmit event:
Whenever a form is trying to submit to /posts/{action}/{id}, cancel it and use AJAX to post and then replace the content with the new one from the server.
Now your app should work like a one page app.
There is no real way around hashbangs if you wish to keep it clientside and cross browser compatible.