Distinguishing an AMP request from a non-AMP request

Does the amp spec allow for redirects based on other parameters. So a combination of 1 and 2, where the inculcation of 1 redirects to 2. This would lead to a better adaptive approach.

What about using the _formatproperty Drupal 8 uses as well?

/node/1?_format=amp

Should the requested entity be rendered as an 'amp' view mode so we can apply filters to replace img/video tags etc? (edit: I guess I'm thinking field formatters here)

One thing I'm seeing from the examples is that the focus is very much on the articles. No use of navigation, just a little header with the site logo. Sometimes there's category links, a list with related articles, or a very basic footer, but not much more. I wonder how difficult it would be for a site builder to include or exclude certain blocks on URLs with a &amp=1 parameter. I'm almost wondering if rendering a different (sub-) theme could be helpful.

At the time this was filed, how to even identify where an AMP version resides was in flux. Since then it's been standardized as incorporating this tag on the canonical version of the page (assuming your AMP version isn't the canonical):

<link rel="amphtml" href="https://www.example.com/url/to/amp/document.html">

Source: https://github.com/ampproject/amphtml/blob/master/spec/amp-html-format.m...

The easiest approach is certainly #1, but I'm a bit hesitant about how that would/n't play nice with other URL query params. Granted, forms are not supported by the AMP spec so I guess we don't need to worry about those in particular.

That's a really good point/question. I would sure assume we'd want to link to AMP pages internally.

On the D7 side we could use something like:

/**
 * Implements hook_url_outbound_alter().
 */
function amp_url_outbound_alter(&$path, &$options, $original_path) {
  // Only rewrite URLs to add $_GET variable if this $_GET variable is set in
  // the current URL and an AMP version exists for the destination content type.
  // TODO - actually define and refine amp_is_amp_page()
  if (!$options['external'] && !empty($_GET['_format']) && $_GET['_format'] == 'amp' && amp_is_amp_page($path)) {
    $options['query']['_format'] = $_GET['_format'];
  }
}

I know this particular project is dead and moved to https://www.drupal.org/project/ampproject but according to the documentation redirecting is not part of the spec. Google Search will detect your mobile user agent and then send you to your AMP version of you page directly from the serp page.

This project is far from dead. :)

Not sure why you would think this project is dead. I have opened an issue in the other project to try and consolidate effort. https://www.drupal.org/node/2678988

Addressing the original request; we're currently appending `/amp` to urls which we detect and switch the theme to the chosen amp theme. We have a default theme at http://drupal.org/project/amptheme which provides a base theme and some reasonable defaults and can be customized by site owners by creating a subtheme.

As for the project being dead, no it's not dead. It was for a while but Lullabot was contacted by Google a while back to spearhead getting this open source project up and running again. We have. We worked on GitHub for the D8 version, but moved over to developing directly on drupal.org for the D7 version to help ensure transparency and to hopefully gain traction with the community.

So as far as duplicate projects, yes there are some, and yes we would welcome contributions from those maintainers. We're currently working on the D7 port of this module. Those issues which are considered to be part of our main deliverables have the following tags:

• AMP: 3/4 (D7)
• AMP: 3/11 (D7)
• AMP: 3/18 (D7 complete)

Help is welcome on these but not required. Any issue outside of these tags should be considered something that may be worked on by anyone as well, but are simply not part of our initial work on this module. After the 3/18 milestone, we're hoping to continue with maintenance and work even closer with the community on some of the various other architecture changes that are now coming to light.

I agree with #3 on this one. I also think `amp_create_amp_alias` is overkill and not needed.

I am going to close this issue as a duplicate of #2676922: Is there a need for AMP pages to have a nice alias? Possible to switch to query string? and #2687255: Switch to amp using a query string. We're leaning toward switching to the querystring approach, and it seems like it's working. Reviews welcome!