wegerl

Hello, I would like to apologize for the error in the previous CSS code. Here is the corrected version, which now works flawlessly:

/* --- Heading with line break --- */

@media (min-width: 700px) {
  .long-heading .nowrap {
    white-space: nowrap;
  }
}

And here is the corresponding HTML:

<h2 class="long-heading">If headings are long, <span class="nowrap">they reach the right margin</span></h2>

Best regards

Dear Support Team,

I hope this message finds you well. A few days ago, I submitted a request regarding the display problems of SVGs as cover images in the Twenty Fourteen theme in the Safari browser. Since I have not received a reply so far, I would like to share my own findings and the solution I found in order to be able to close the ticket.

• The solution is to ensure that the background of the SVG protrudes slightly beyond the four sides of the viewbox when creating the SVG.

I hope this information is helpful and can assist other users with similar issues. If there are any further questions or comments, please do not hesitate to contact me.

• This reply was modified 9 months ago by wegerl.

Hello @properlypurple,

I’m sorry for asking again. The other problem that has occurred here is purely specific to my website wegerl.at. It is only directly related to the read mode here and is only sporadic in nature.

Thank you very much for your support so far and I apologize for the inconvenience.

Thank you very much for your time and patience!

With kind regards

• This reply was modified 1 year ago by wegerl.
• This reply was modified 1 year ago by wegerl. Reason: readermode
• This reply was modified 1 year ago by wegerl.

Thank you very much, @properlypurple! Your suggested CSS adjustments have successfully fixed the problem. Your support was extremely helpful, and I really appreciate your expertise. If any further questions or concerns arise in that regard, I know who to contact. Thanks again for your help!

Best regards

I can confirm that the problem here occurs on the operating system (OS), and the latest version of Safari is installed.

Addendum, and I apologize for the confusion. In summary the following should work:

/* Browser-Specific Handling for Firefox */
add_action('wp_footer', function() { 
  ?>
  <script>
    (function($) {
      // Check if it's the Firefox browser
      var isFirefox = typeof InstallTrigger !== 'undefined';

      if (isFirefox) {
        // Add a class to hide the website
        $('body').addClass('hidden-site');

        // Remove the class after a fixed delay before the page is fully loaded
        setTimeout(function() {
          // Remove the class to display the page
          $('body').removeClass('hidden-site');
        }, 500); // Change the delay time here as needed (in milliseconds)
      }
    })(jQuery);
  </script>
  <?php
});

The delay time is set to 500 milliseconds by default, but can be adjusted as needed.

With the previous code and this CSS it should work:

/* CSS code to hide the page */
.hidden-site {
  visibility: hidden !important;
  opacity: 0 !important;
}

Thanks a lot!

• This reply was modified 1 year, 3 months ago by wegerl.

Hello for the feedback ?? Here is another approach that seems to be a bit more robust:

add_action('wp_footer', function() { 
  ?>
  <script>
    (function($) {
      // Check if it's the Firefox browser
      var isFirefox = typeof InstallTrigger !== 'undefined';

      if (isFirefox) {
        // Hide the website by default
        $('body').css('visibility', 'hidden');

        // When the page is almost fully loaded, make the website visible again
        $(window).on('load', function() {
          // Set a minimal delay to ensure the page is fully loaded
          setTimeout(function() {
            // Set the visibility of the website back to "visible"
            $('body').css('visibility', 'visible');
          }, 100); // Adjust the delay time as needed (in milliseconds)
        });
      }
    })(jQuery);
  </script>
  <?php
});

Adjust the delay time: Try different times to find the best setting for your website. However, please note that it can be challenging to find a perfect solution. In some cases, the preloader may not be visible at all, but this will eliminate the flickering. Thank you.

Hello,

I would like to apologize for my previous attempts to prevent the website from flashing before the preloader in the Firefox browser. Unfortunately, I was not able to solve the problem completely.

Thank you for your understanding.

The posted code from (@carlosatfongo) helped our website a lot by fixing the endless loading issue in Firefox. However, there was still an annoying flashing of the website before the preloader (The problem in Firefox is, reload > flash website > preloader > website visual).

To prevent this blinking and to find an even more reliable solution, I developed the following code for functions.php:

add_action('wp_footer', function() { 
  ?>
  <script>
    (function($) {
      // Check if it is the Firefox browser
      var isFirefox = typeof InstallTrigger !== 'undefined';

      if (isFirefox) {
        // Add a class to hide the website
        $('body').addClass('hidden-site');

        // Remove the class after a fixed delay before the page is fully loaded
        setTimeout(function() {
          // Remove the class to show the page
          $('body').removeClass('hidden-site');
        }, 500); // Change the delay time here as needed (in milliseconds)
      }
    })(jQuery);
  </script>
  <?php
});

This code should be placed below the code provided by (@carlosatfongo). The success of this solution was particularly evident when used in conjunction with Dark Mode.

The code couldn’t be effectively combined into a single action because the two actions need to be executed separately within wp_footer, which helps reduce timing conflicts. First, the preloader is hidden, and then the website’s visibility is controlled based on the browser type. This approach minimizes the likelihood of timing-related issues.

Thanks to (@carlosatfongo) for the original code, and thanks to everyone for the support and solution finding.

Hello Loft.Ocean team,

thank you very much for your quick reply. A screencast video would probably not be that helpful, as the error occurs in the order of loading content. Instead, I would like to invite you to view the error directly on my website.

Please visit my website, there you can see the preloader (LoftLoader) loading before the dark mode (WP Dark Mode). Please see the note about the header bar: If the dark mode is not active and to activate the dark mode, you can use the header bar to turn on the dark mode. My goal is to have dark mode load first and then display the preloader.

If you need more information or assistance accessing my website, I’m happy to help.

Thank you very much for your help.

Yours sincerely

Dear support team,

thank you very much for solving the problem. I appreciate your prompt support and providing the updated version of the plugin.

Thank you and have a nice day!

Sincerely

Hello Support Team,

In this case I have reduced the SCROLL DIRECTION from three ticks to one tick to the left, and so the problem is solved for the time being.

Regards

• This reply was modified 1 year, 5 months ago by wegerl.

Thank you for the information. The desired reading mode is in the template at https://wegerl.at/lesemodus-website/.

I created a new ticker and set the scrolling direction to “left”. Unfortunately, the same problem continues to occur. Both tickers are now available online, and the upper ticker works fine when switching between normal mode and reading mode in the scroll direction on the right. However, the error affects the lower ticker, where the scroll direction is to the left. When switching to reading mode, the ticker is either invisible or has visual glitches.

Please let me know more information or support to solve the problem.

I have also noticed a problem with the “RNG Ajax Like” plugin on my WordPress website. Before each excerpt on my https://wegerl.at/beitrags-blogseite/ the text “it works” is displayed. I could only fix the problem by disabling the plugin.

I am not sure if you, as the plugin author, are still interested in developing the plugin further. If this is not the case, I would like to withdraw my previous request. However, I would like to thank you for your attention so far.

The problem has been solved. The solution is to override the ruleset .hide { display: none; } in the Twenty Fourteen theme with .ez-toc-sticky-fixed.hide { display: block; }. This can be done either in the child theme or in the customizer.

• This reply was modified 1 year, 7 months ago by wegerl. Reason: Resolved