[jpadvo]

This is really nifty. One nit that I'd pick, however. The urls break without the hash.

With the demo, for example, these urls produce two different results:

http://cmpolis.github.com/Pagify/#about http://cmpolis.github.com/Pagify/about

The first url has the full content and structure of the page, while the second url only has part of the content of the page.

I realize that this is partially what makes the plugin so simple, and maybe it's fine for most applications. But this would be extra cool if the urls were more consistent. :)

[ByteMuse]

Good point. The first URL is really how the page is intended to be accessed.

I'm going to work on an option to enable using pushState for navigation which would use hashless URLs. The only downside is that users would have to enter the site through the base URL or some JS would have to be included in each content page.

Thanks for the feedback, really got me thinking about how to add pushState support!

[huhtenberg]

This should really be handled on a server side with a set of redirects, and Twitter would be a good example to follow. Their redirect setup is this:

  http://.../_escaped_fragment_=PAGE  ->  http://.../PAGE

The _escaped_fragment_ URL is what is crawled by Google as per [0] and the redirect ensures that PAGE gets recorded in Google as /PAGE. Then they also do this:

  http://.../PAGE   ->   http://.../#!/PAGE

but only for logged in users and, I would assume, NOT for requests that have _escaped_fragment_ in the Referer (sic). This ensures that regular URLs work as expected, including those picked up by the users from Google.

[0] http://code.google.com/web/ajaxcrawling/docs/specification.h...

[shaggyfrog]

Using the hash allows for all the content to exist within a single resource -- in this case, a single HTML page using jQuery to hide/show content based on the fragment identifier. What you want can't really be achieved without something on the server-side (rewrite rules with Apache, routes with Rails) and it outside the scope of what this plugin is trying to do.

[voyou]

> What you want can't really be achieved without something on the server-side (rewrite rules with Apache, routes with Rails)

That's true, but the rewrite rule could be very simple. Have all pages of the form http://site.example/* serve up the entry page (which then uses JS to parse the URI and load the appropriate page content), and special case http://site.example/pages-directory/* or something to serve the content for specific pages.