Autoptimize cache size issues w/Honeypot

  • Resolved roderickgadellaabsl

    (@roderickgadellaabsl)


    1 year, 7 months ago

    Hi,

    We ran into an issue where the Autoptimize (AO) cache was growing very large. After some investigation, I noticed that AO generates a separate cache file for each page that includes a form (w/Honeypot).

    It turned out that the inline css snippet that Honeypot adds to hide the input field uses a ‘random’ css selector (#wpcf7-{ hash }-wrapper). We had AO configured to aggregate inline css, but due to the Honeypot css selector changing, it resulted in separate css cache files for each variant. AFAIK, the ‘hash’ is different for each page but maybe even per user session, ip, …?

    We’ve disabled aggregation of inline css for now (which solves the immediate issue) but maybe you could look into making this work nice(r) with Autoptimize?

    For reference: we ran into this issue on a careers site (https://careers.keylane.com/jobs/) where each vacancy has a separate page with a simple apply form. Each of those vacancy pages would include a Honeypot css snippet with a different hash.

    Thanks!

    The page I need help with: [log in to see the link]

Viewing 4 replies - 1 through 4 (of 4 total)

  • Thanks for the heads up. I’ve added this issue to my tracker, and will address it in the next update. Am a bit inundated with things at the moment, so I’m not 100% sure when that will get out, but asap. I’ll update this thread when I add it.

    • This reply was modified 1 year, 7 months ago by Ryan.
    Thread Starter roderickgadellaabsl

    (@roderickgadellaabsl)

    Sorry for the late reply, I was on a short break. Anyway, just wanted to say thanks!

    Hi @roderickgadellaabsl – I finally had a chance to dig into this a bit and unfortunately I don’t think I can fix this at the moment. But there may be a solution for you.

    Basically, the random wrapper ID isn’t very essential, and I could probably get rid of that. However, the issue is the honeypot field has a label associated with it – this is largely for accessibility purposes – so in scenarios where the field is “displayed” in some way, there is descriptive text to let a person know not to fill in the field. Standards dictate that this requires the honeypot field must have an ID to associate it with the label element.

    Both the wrapper ID and the field ID can be set, as shown here:

    [honeypot website id:some-field-id wrapper-id:some-wrapper-id]

    When they are not set, a random ID is created to assure the field has an ID to associate with its label. So, I could get rid of the wrapper part, but the field part would still trip up the Autoptimize cache.

    Two (admittedly not perfect) solutions:

    1. When creating/inserting the honeypot field, add the ID and Wrapper ID values, which will then override the random value and allow the new static values to be cached.
    2. Use the output override functionality here to rewrite the field’s HTML. Recipe here. It’s the last of the 3 example functions.
    Thread Starter roderickgadellaabsl

    (@roderickgadellaabsl)

    I’ll have a look next week! Thanks for the help, Ryan!

Viewing 4 replies - 1 through 4 (of 4 total)
  • The topic ‘Autoptimize cache size issues w/Honeypot’ is closed to new replies.