The Foxy forums are on the move!

We're in the process of moving our forums over to a new system, and so these forums are now read-only.
If you have a question about your store in the meantime, please don't hesitate to reach out to us via email.

AutoMagiCache + canonical link tag handling

pixelchutespixelchutes Member
in General edited April 2015
Just a thought, AutoMagiCache automatically strips the <base> tag (understandably so), perhaps it should be stripping <link rel="canonical">, too?

Example:
<link rel="canonical" href="http://domain.com/path.to.custom.twig.template.html">
Not sure it does any good having it on the FC Checkout markup, and ideally would not reveal the location of the custom Twig URL. One could argue to simply remove from the cacheable template, but figured I'd throw out the idea of automatically stripping it from the HTML since I know other things are currently being stripped, too.
«1
Comments
  • brettbrett FoxyCart Team
    Thanks, @pixelchutes.
    I've ticketed that up. We'll try to get to it the next time we make a round of improvements on the caching functionality.
  • Thanks @brett!

    Will that include the ability to cache https pages, too? ;) Would LOVE to see that support added.
  • fc_adamfc_adam FoxyCart Team
    @pixelchutes,

    What issue are you running into caching a https page?
  • @fc_adam,

    I have never been able to successfully cache an https page. It always returns invalid 404 errors when attempting to cache. Over the years I have only ever been able to cache via http. Not sure if it has anything to do with use of https + <base href> tag?
  • fc_adamfc_adam FoxyCart Team
    @pixelchutes,

    Perhaps if you can get us a URL we can replicate it on our side? Feel free to whisper if it's private.
  • Thanks, @fc_adam. I've whispered you a few sample URLs.
  • fc_adamfc_adam FoxyCart Team
    @pixelchutes,

    Thanks, I was able to replicate what you're describing. We'll take a look and get back to you as soon as possible.
  • Thanks, Adam. I always just presumed caching via https was not supported. Interested to know what you find, and if it's anything specific to my setup?
  • brettbrett FoxyCart Team
    Thanks @pixelchutes. I've got that ticketed, and we'll get it fixed with the next batch of caching improvements. Sorry about that!
  • Sounds good, @brett. Looking forward to it, as https caching support will actually help simplify some of our setup where we've had to implement workarounds in our templates exclusively made available via http.
  • Following up to check on the status of https template caching support? As it stands, we aim to serve 100% https only, however exceptions must be put in place to allow for successful AutoMagiCache. Further, we cannot fully leverage HSTS until template caching over TLS is added.
  • fc_adamfc_adam FoxyCart Team
    @pixelchutes,

    Unfortunately we haven't made any progress on this issue just yet - but as Brett mentioned it is ticketed and we'll update you with any progress as it happens. Thanks for checking in!
  • Thanks for the update, Adam. Appreciate it!
  • brettbrett FoxyCart Team
    @pixelchutes: We've got a PR for the canonical issue, but the https js issue I think we need to discuss.

    The intended behavior is to say "If a file's already https, don't cache it at all." If you've got your js (or CSS or images or whatever) at https already, we don't see a benefit to caching it on our end, as the caching is really only intended to get things secure.

    Can you clarify the approach and the benefit? Or is it that you use the base href with https, and then the assets are relative? Even in that case, it should still work based on the domain we're caching from. So I'm a little confused. Thanks!
  • @brett @fc_adam -- sorry, I did not see this post, I had attempted to move this topic to: https://forum.foxycart.com/discussion/10465/add-automagicache-support-for-https-tls-hsts

    Is AutoMagiCache support for HTTPS still not supported?

    Yes, I would say <base href> with https (via relative paths) is a perfect example. At the end of the day, if a site is running on a HTTPS website it should still by cacheable by FoxyCart (without errors or requiring exceptions to HSTS or forced TLS rules.) Today, the only way to reliably cache a template is allow both http (for foxycart.com caching) and https (for everyone else.)

    If the update on your end simply would NOT cache files that are already secure, I think that would be sufficient. I'm not sure if there are any cross-domain loading concerns to consider? They may not benefit from loading inline to the page source -- requiring addition request(s) -- but they would hopefully 304 anyway
  • fc_adamfc_adam FoxyCart Team
    @pixelchutes,

    Thanks for the update. Can you still replicate the issue you were experiencing with the https template? It's caching fine for me now in testing
  • @fc_adam,

    No, it does not error, but something seems broken...

    For example:
    <script type="text/javascript" charset="utf-8">
    /* <![CDATA[ */
    /* Pulled from _assets/js/foxycart.checkout.js */


    /* ]]> */
    </script>

    ^^ I'm not sure where that underscore in the path above came from, but it's not part of the source template. Further, the JavaScript is not present (just loads an empty block).

    Here's how it actually looks in the source template:
    <!DOCTYPE html>
    <html>
    <head>
    <base href="https://www.domain.com/">
    ...
    </head>
    <body>
    ...
    <script src="assets/js/foxycart.checkout.js"></script>
    ...
    <pre>
    NOTE: I'm also not sure why your forum's code formatting is showing that semi-colon above, but it's not part of what I've actually pasted into this post.
  • fc_adamfc_adam FoxyCart Team
    @pixelchutes,

    The underscore is added as part of the caching system - it's just a reference point for the URL that the cached content came from. You'll see that for any file that we pull inline. The semicolon is also a small bug with our forum system - it tries to be smart and make it into a link I think - but it's just getting in the way :)

    I can see what you mean about the caching not pulling in that file though - it does have contents, and it's secured so our caching system shouldn't even be bothering with it.

    I'm going to touch base with one of our developers who was working on our caching system recently and ask him to take a look at this. In the meantime - could you try creating a new template file on your side, and switching from relative to absolute links - and seeing if it respects the links then? We'll work on debugging the issue with the template you whispered - but I'd love to confirm if absolute URL's work as expected.
  • Good to hear, @fc_adam.

    I've had to use https absolute links as a workaround in the past (when automagicache couldn't handle some tricky JS... Modernizr, IIRC) -- so I'm almost certain that piece is solid.
  • fc_adamfc_adam FoxyCart Team
    @pixelchutes,

    Thanks for that. We have a fix pending for the relative HTTPS files being cached incorrectly - once that's gone through QA and pushed live we'll let you know!
  • @fc_adam, what is the ETA for this fix?

    I thought I should also mention that I noticed another oddity (perhaps related?)

    TEMPLATE:
    <!--[if lt IE 10 ]>
    <script src="//{{ config.store_domain }}/static/scripts/placeholder/placeholder_polyfill.jquery.js" charset="utf-8"></script>
    <![endif]-->
    CACHED:
    <!--[if lt IE 10 ]>

    <![endif]-->
  • fc_adamfc_adam FoxyCart Team
    @pixelchutes,

    Not ETA unfortunately, but it does appear to have passed through QA so it should be fairly soon.

    That latest issue you spotted may be related - let's see if the upcoming fix corrects that, and if not we can take a closer look.
  • @fc_adam,

    Has the pending fix been rolled out?

    I just tested this again now, and my "foxycart.checkout.js" example above appears to be pulling down as expected!

    However, the "[if lt IE 10 ]" example (linking to placeholder_polyfill.jquery.js) is still empty, perhaps unrelated?
  • fc_adamfc_adam FoxyCart Team
    @pixelchutes,

    Sorry for not updating you sooner - the fix for the https issue was rolled out in February, not long after my previous post.

    I'll create a new ticket for the polyfill one - I was able to replicate that too - we'll update this thread as we roll out a fix for that.
  • fc_jedfc_jed FoxyCart Team
    @pixelchutes

    A fix for the polyfill issue has just been deployed. Test it out and let us know if the issue still persists for you.
  • @fc_jed @fc_adam,

    Was the https automagicache issue only applied to specific versions of FoxyCart?

    I just tested this against some v0.7.2 stores, with no success:

    <style type="text/css" >
    /* <![CDATA[ */
    /* Pulled from _/assets/css/reset.css */

    /* ]]> */
    </style>

    <style type="text/css" >
    /* <![CDATA[ */
    /* Pulled from _/assets/css/styles.css */

    /* ]]> */
    </style>
  • fc_adamfc_adam FoxyCart Team
    @pixelchutes,

    It was just fixed in 2.0 currently. I'll see if we can roll that fix back to earlier versions as well.
  • pixelchutespixelchutes Member
    edited March 2016
    Thank you! I do think it's an important fix for all versions, hopefully it's not overly complex to achieve.
  • fc_adamfc_adam FoxyCart Team
    @pixelchutes,

    Unfortunately this isn't a fix that we'll be rolling back to older versions. Is there any chance the 0.7.2 store could be upgraded to 2.0? We can assist with looking over what might be involved in that upgrade if you'd like?
  • pixelchutespixelchutes Member
    edited April 2016
    @fc_adam,

    I'm sorry to hear that. Unfortunately, the FC v2.0 Twig syntax: {{ and }} conflict with the built-in interpolation of the legacy version of the CMS the v0.7.2 sites are using. They cannot be upgraded to FC2.0 and maintain custom templates as needed without first upgrading the site / CMS, which adds a lot of scope just to properly cache our templates over TLS / HTTPS.
Sign In or Register to comment.