Forum Replies Created

Viewing 15 replies - 16 through 30 (of 53 total)
  • Thread Starter born2excite

    (@born2excite)

    Hey threadi ( @threadi )

    Thanks for your help!

    For the most part, I generate product pages manually, adding raw HTML as needed.

    I want to simulate the share by email button found on a large number of websites, clicking an envelope button to launch the visitors email client. In my case, I’ll use text instead of an icon for the mail to link.

    I’m mostly there, I just need a little help to improve what I’ve got already. Below is the working code snippet and mail to link I’m using.

    The problem with it is that the email body is populated with the product title but there is no URL. I need to also add the product page URL to the email body.

    Code Snippet

    add_shortcode( 'custom_mailto_title', 'custom_mailto_title' );
    
    function custom_mailto_title( $atts ) {
        return esc_attr( get_the_title( get_the_ID() ) );
    }

    Mail to Link

    <a class="external-email" target="_blank" href="mailto:?subject=[custom_mailto_title]&amp;body=I would like to know more about [custom_mailto_title]" rel="noopener noreferrer">Email this Zouk T-shirt to me</a>

    What do you think, is it possible to auto add the product page URL to the email body?

    Thread Starter born2excite

    (@born2excite)

    Hey Kasia, @wpmudev-support2

    I spent 6 days in hospital for a procedure, all good now, I survived. Sorry for my late reply!

    I switched settings to “Page Reload” instead of “Ajax” and then?“Validation” To “server side”. Processing the request was still slow.

    Then came the nuclear option… the conflict test, disabled plugins and activated the Twenty Twenty-Three theme as you described. Again, processing the request improved but was still slow.

    Siteground assures me their servers are not to blame. I guess they would say that.

    Thanks, Kasia, I appreciate your help.
    Julian

    Thread Starter born2excite

    (@born2excite)

    Hey Joshua @wfjoshc

    Thanks for your help, I appreciate your time.

    Can you please confirm, by LSAPI, do you mean the Microsoft product, Licensing Service API?

    My hosting is on a Siteground shared server.

    Thanks,
    Julian

    Thread Starter born2excite

    (@born2excite)

    Hey Kasia @wpmudev-support2

    Here’s a link to the form, exported and copied to Pastebin as requested.

    Thanks for your help!
    Julian

    Thread Starter born2excite

    (@born2excite)

    G’day Ben,

    I’ve sent you an email as requested.

    You may now wish to edit your previous message, removing your email address so you don’t get spammed.

    Cheers!

    Thread Starter born2excite

    (@born2excite)

    Hey Ben,

    I setup the staging site, disabled plugins then run GTmetrix tests after activating each plugin one by one.

    Search request from Independent Analytics loading time increased incrementally after each successive plugin activation, with a little fluctuation up and down. That is, each plugin activation caused longer Independent Analytics loading time. Nothing popped up as a clear cause of the excessive loading time.

    Analysing the REST API request itself, typically, it’s taking 4.3 seconds waiting and 1ms receiving.

    There doesn’t seem to be a clear answer, unfortunately. As for my hosting with SiteGround, I’m on the GoGeek plan which is their top/best shared hosting plan with pretty good resources.

    Independent Analytics plugin is pretty darn good so I’m disappointed to have to let it go.

    Thread Starter born2excite

    (@born2excite)

    Hey Ben,

    Thanks for your detailed explanation, I appreciate your time and help.

    I troubleshoot the plugins as you described, disabled all plugins except for the Cloudflare, Jetpack, SiteGround Optimizer, WooCommerce, WooCommerce PayPal Payments, WooCommerce Shipping & Tax, WooCommerce Stripe Gateway, Wordfence Security and WPBAkery Page Builder plugins. I don’t want to mess with these plugins so I won’t disable them for any reason.

    Running performance tests through GTmetrics and in the browsers developer tools still yielded long search request from Independent Analytics with all the above plugins disabled.

    My site is hosted with SiteGround and I’m using their SiteGround Optimizer plugin with settings to combine CSS and JavaScript, etc. I suspect the SiteGround Optimizer plugin may be the cause of this excessive loading time issue.

    The Request Initiator Chain is:

    cloudflare-static/rocket-loader.mini.js
      siteground-optimizer-combined-js.js
        wp-json/iawp/search

    I can exclude assets from combination in the SG Optimiser plugin. The effect would be to allow Independent Analytics search requests to initiate normally. What do you think, Ben? Can you advise which Independent Analytics assets I can exclude from combination?

    Thread Starter born2excite

    (@born2excite)

    Hey Josiah ( @colewebdev )

    Thanks for clarifying the difference between the Jetpack Protect plugin and the “original” Jetpack plugin.

    I am using the “original” Jetpack plugin. So, does that mean all features offered in the Jetpack Protect plugin are included in the “original” Jetpack plugin and I can ignore the Jetpack Protect plugin?

    Thanks for your advice!

    Thread Starter born2excite

    (@born2excite)

    Hi Adam ( @wpmudev-support8 )

    Thanks for your reply, I appreciate your detailed explanation. I’ll disable AJAX loading to test and see what happens.

    That’s all for now, please close this support ticket.

    Kind Regards,
    Julian

    Thread Starter born2excite

    (@born2excite)

    Hello Pawel ( @wpmudev-support9 )

    Thanks for your detailed reply.

    I understand the benefits of caching and the issue of ajax calls not being cached. There is nothing I can do about server resources. So, are you telling me that there is nothing you or I can do to improve the loading of Forminator forms?

    Alternatively, must the form be loaded using ajax? I can’t see the benefit really! Why does a Forminator form need ajax to load on the homepage? Are there any negative consequence from disabling loading a forminator form with ajax?

    Warm regards,
    Julian

    Thread Starter born2excite

    (@born2excite)

    Thanks Dan @drawmyface

    I appreciate your detailed reply.

    Have a GREAT day!

    Thread Starter born2excite

    (@born2excite)

    Hey Shea ( @bungeshea )

    Great, thank you! All good now, please close this support ticket.

    Cheers,
    Julian

    Thread Starter born2excite

    (@born2excite)

    Hey Adam @wpmudev-support8

    Sorry for the late reply! I was trying to remove GDPR field from the NEW form. Thanks for your explanation, I now understand a form copy is not “connected” to original form and deleting the new form GDPR field will not delete the original form submissions.

    I appreciate your detailed explanation, Adam, and your effort to produce clear instructions demonstrates the high quality and value you provide.

    Much thanks,
    Julian

    Thread Starter born2excite

    (@born2excite)

    Hi Kasia @wpmudev-support2

    When trying to replace GDPR field on the duplicated form as you suggested, I still get the same warning:

    • Field can’t be deleted
    • Deleting this field {gdprcheckbox-1} will remove its value from the existing submissions

    This is obviously a problem all users will experience, not just me. Please consider fixing this problem in the Forminator coding so deleting/replacing the GDPR field does NOT delete its values from the existing submissions.

    Thank you,
    Julian

    Thread Starter born2excite

    (@born2excite)

    Hi Adam @wpmudev-support8

    I understand the workaround you suggest, thanks for following up my issue. My concern is, since the GDPR field is now depreciated and will not be supported going forward, the GDPR field may eventually cause unexpected form functional issues, conflict or even a security vulnerability.

    I can hide the GDPR field with CSS but it is still there in the HTML for hackers to exploit. I guess other people in my situation will want to preserve previously submitted GDPR data and will also implement this workaround, increasing the possibility hackers will notice and exploit.

    May I suggest a safer workaround by coding Forminator to offer preserving the GDPR submissions instead of deleting them? So, the previously submitted GDPRs will stay in submissions when deleting the GDPR field. This is a low priority issue so the developers can put this fix on the backburner to address whenever they can. The GDPR field still works so I’m happy to wait.

    What do you think, Adam?

    Best Regards,
    Julian

Viewing 15 replies - 16 through 30 (of 53 total)