Forum Replies Created

Viewing 15 replies - 1 through 15 (of 22 total)
  • Thread Starter kinghill

    (@kinghill)

    It’s fixed! THANK YOU SO MUCH!
    For others, I post your solution here as well. Turns out it has been the lazy load setting, after all.
    Only on my case that didn’t work initially, because I had use_shortcode_attributes_only=”true” in the shortcode and so the setting “didn’t get through”.
    If one inlcudes loading=”false” in the shortcode it works perfectly and the JavaScript gets executed in Chrome as well!

    Thank you again, Michael!
    ????

    Thread Starter kinghill

    (@kinghill)

    That would be awesome, if you could check. But like I said, if it’s too much trouble, I’m OK with staying on version 2021.9.

    If you still want to invest some time, you will need an user account to access the page in question, so I would need to DM you the credentials. Please let me know where to send those to.

    THANK YOU!

    Thread Starter kinghill

    (@kinghill)

    Thank you – but, alas, that was not it.

    No matter what I select for the lazy load setting – tried them all: never works. Tested with versions 2022 and 2022.2
    Back to 2021.9 works again, and I’m a happy camper.

    Weird.

    Thread Starter kinghill

    (@kinghill)

    Hello Michael,

    great news! Rollback to 2021.9 did the trick! It now consistently works in Chrome and Edge again. ??
    With Version 2022, no luck. So for my use case, there must have been a change that is causing this.

    So unless you advise against it, I’d be happy to stay on 2019.9 for the time being.
    Meaning, I don’t expect you to any more time resolving this. I’m happy that my users can use the page in question again.

    Should you still like to take a look at my site, you are welcome to do so, of course. You will need both a user and an admin login for this, though. And I’d rather not share those here publicly. Just give a email where I can send the credentials to, in that case.

    Thank you again for your time and your support!
    Andreas

    Thread Starter kinghill

    (@kinghill)

    OK, this turns out to be a real tough nut to crack.

    With the suggested shortcode I still get the same result. ??

    I did some more experimenting on my own, also all fruitless:
    – deactivated all plugins but the ones I need for the page to load: Events Made Easy, Ultimate Member, Advanced iFrame
    – I’m using the Divi Theme, so a deactivated all performance optimizations there – same result.
    – put a frontend page as “src=” in the shortcode. Same result
    – Deactivated cache in Chrome Dev tools and even throttled the loading speed to 3G. Same result

    So, let me try an older version of yours – can you please send me the one that’s closest to 17 January 2022. That’s the date we started using the page in question.

    After that, we’ll know more, perhaps.
    Also, would it help if I gave you admin access to our site?

    Thanks again for your support.

    Thread Starter kinghill

    (@kinghill)

    Thank you for your response, and sorry for my late reaction. Have been on the road the last couple of days…

    So I tried this shortcode with the only onload command is a console log:

    [advanced_iframe use_shortcode_attributes_only="true" src="/wp-admin/admin.php?page=eme-manager" width="100%" height="1200" scrolling="no" id="eme_iframe" url_forward_parameter="ALL" hide_page_until_loaded="true" iframe_content_id="body" iframe_content_styles="background: white" onload="console.log('iFrame check')" onload_resize="true" onload_resize_delay="200"]

    And again, yes, it almost never gets executed on Chrome, while it consistently does in Firefox and Chromium.
    Again, No console error messages whatsoever.

    You say the loading of the WP administration does not work? In my – admittedly limited research there – I have not come across such a hint. But perhaps this is the issue on Chrome? And Edge, too. Did a test there now. But then again, why does it work sometimes? And consistently in Chromium and Firefox? For 4 months now… Very strange…

    Unfortunately, I’m stuck trying to export older versions from the repository. I’m afraid I’m not familiar at all with SVN…
    I installed TurtoiseSVN. But when I put it the URL you gave https://plugins.trac.www.ads-software.com/log/advanced-iframe I get this error message: “unable to connect to a repository at URL https://plugins.trac.www.ads-software.com/log/advanced-iframe. The server does not support the HTTP/DAV protocol”
    Could you perhaps give me some pointers what to do?

    Sorry to be a bother, and thanks for your support!

    Thread Starter kinghill

    (@kinghill)

    Hi Michael,
    thanks for your quick response. I, too, figured it must be a timing issue. Unfortunately, I can set whatever I like for the delays – even up to something ridiculous like 2000ms – it still happens on Chrome. Most of the time, that is, and not on every machine. A real bitch to figure out.
    I also tried to add a timeout function directly to the onload call – same results. ??
    onload="setTimeout( () => { emeFrameLoaded() },1000)"

    Can I perhaps ask you for older versions of the plugin, just to make sure? We use this shortcode since December 2021, and I seem to remember that it ran OK back then (but I might be misremembering).

    Could it also have something to do with PHP settings or other WordPress settings, perhaps?

    This is the shortcode I’m using at the moment:
    [advanced_iframe iframe_content_id="body|#div_event_customfields :is(tr:nth-last-of-type(3), tr:nth-last-of-type(4))" iframe_content_styles="background:white|display:none"]
    The rest is coming from settings

    Full generated shortcode would be this – also tried it on the page, same result:
    [advanced_iframe use_shortcode_attributes_only="true" src="/wp-admin/admin.php?page=eme-manager" width="100%" height="1200" scrolling="no" id="eme_iframe" url_forward_parameter="ALL" hide_page_until_loaded="true" iframe_content_id="body" iframe_content_styles="background: white" onload="emeFrameLoaded()" onload_resize="true" onload_resize_delay="200"]
    Or onload_resize_delay="2000"– doesn’t seem to matter.

    • This reply was modified 2 years, 7 months ago by kinghill.

    Hello,

    I’m having a similar issue, only in my case the onload JavaScript is not firing on Chrome for Windows. As with you, no errors, no messages whatsoever in the console. The script is just not being called.
    Which plugin caused the issue for you?

    And to make it even worse. it does work in roughly 1 out of 10 page loads.
    And: the backup of my site on another server always works in Chrome, with the same plugins and settings.

    I’m at loss here – any other ideas?
    Thanks!

    • This reply was modified 2 years, 7 months ago by kinghill.
    Thread Starter kinghill

    (@kinghill)

    OK, thanks.
    It seems we are still miscommunicating. The other plugin is not the issue. In fact, It corrects the problem that EWWW is causing.

    But never mind, I contacted you directly on your website now. Hope they can shine a light on this…

    Thread Starter kinghill

    (@kinghill)

    Hello and thanks for your reply!
    But unfortunately, adding define( 'EWWWIO_EDITOR_OVERWRITE', true ); to my wp_config.php didn’t do the trick.

    
    define( 'WP_DEBUG', false );
    
    define( 'EWWWIO_EDITOR_OVERWRITE', true );
    
    /* That's all, stop editing! Happy publishing. */
    

    Perhaps I described my issue not fully or correctly, so I decided to make screenshots for you. They are numbered and can all be found here:
    https://1drv.ms/u/s!AqyHmqxK9rN_uthKld-_Dr086WnXIg?e=8bVNAR

    1. Divi Gallery after first EWWW optimization (=my problem)
    2. Image Details Media Library
    3. Force Regenerate Thumbnail in Media Library
    5. Divi Gallery after Force Regenerate – EWWW deactivated (=all OK)
    6. Force Regenerate Plugin Result EWWW activated
    7. Divi Gallery with activated EWWW (problem returned)

    I hope you can help – I’m really at a loss what is happening here.

    Same here, update installed. And everything is great!

    Thank you, Franky, for your prompt reaction and fix!

    First one is that a <br> is generated after heading tags in templates.
    I have an <h4> which gets a <br> rendered after it.

    Ah, yeah, you’re right, just noticed this with me, too.
    <h3>
    is definitely affected, too.

    Hi Franky,

    I just ran across the issue, too.
    Unfortunately, the problem still persists for me, even after uploading the modified eme_functions.php

    As you mentioned you code is “greedy” and inserts <br> tags not only after div and p but also after other tags, too. In my case, <dt> and <dd> tags, as I’m using defintion lists for my event listings for semantic reasons..

    Here’s an excerpt of my template code:

    <div class="now-eventList-event">
        <dt class="now-eventName">#_LINKEDNAME</dt>
        <dd>
            <div class="now-presenterColumn">
                <p><span class="now-presenterImage">#_CONTACTIMAGETHUMB</span></p>
            </div>

    By the way – I’m using the standard event template under EME settings -> Events. And there’s no setting about converting newlines to br as there is for templates created in the templates section, is there?

    Thanks!

    • This reply was modified 3 years, 2 months ago by kinghill.
    Thread Starter kinghill

    (@kinghill)

    PS: The px issue is resolved, thank you!

    Thread Starter kinghill

    (@kinghill)

    Hi sorry for not responding, for some reason WP didn’t notify me of your reply from a week ago. Only now did I receive the resolved message…

    Since I’m not a PHP or WP developer, I’m a little overwhelmed by your suggestions. What ecaxtly do I put where if I want my button texts in the Login and Registration forms to allow for a <br> tag?

    Thanks for clarifying!

Viewing 15 replies - 1 through 15 (of 22 total)