Forum Replies Created

Viewing 15 replies - 16 through 30 (of 68 total)
  • The sitemap should automatically list only real URLs, posts and pages that are allowed to be indexed. Canonical URLs should automatically match with the correct URLs.

    Do you have an idea how the redirect to home could be caused? (New Plugin? Template Error or missing template? Page is offline? Page was manually redirected to home?)

    I do not think that it is a caching problem (sitemap not excluded from caching) as the page seems to have been generated in May, but your latest update on that domain was written into the sitemap yesterday.

    I could imagine that files will be renamed if you (a) make changes to the original files or (b) update the plugin to a new version.

    Perhaps you need to refresh the WP Super Page Cache then. But the plugin shall have an “option to automatically clean up the cache on website changes”. Did you address that problem to the caching providers (https://www.ads-software.com/support/plugin/wp-cloudflare-page-cache/) already? (May be they want to make some tests to ensure better compatibility?)

    Another thought on this: Did you try to play with the global options of FVM to delete or not delete cache files directly? May be it can help even on Cloudflare connections to leave it unchecked?

    • This reply was modified 2 years, 10 months ago by fob.

    Played around with it, finally excluded (js) blocksy paths from additional optimizations, deleted and regenerated caching files.

    Works like a charme!
    Lighthouse tests still okay, too (results impacted by client stuff to be loaded but measured over all its excellent).

    Thanks very much for the hint, this should simplify the update management and works very well now.

    Thanks Eduard. I deactivated the caching plugins for testing purposes and deleted their results before posting the problem I have seen on that page and the other one above. There also is a depency manager included in the caching plugin (files to be loaded). Will play around with it an see if something was changed in the latest updates.

    The funny thing I saw was that it uses another SVG for showing the changing direction for unfolded sub menues. This new behavior is something I could not see in any theme options. So I wondered where it comes from.

    • This reply was modified 3 years, 1 month ago by fob.
    • This reply was modified 3 years, 1 month ago by fob.

    Just had a look at the page above having the same problem here:
    https://www.online-pkv.de/ using 1.8.6.1 or 1.8.6.2 – no issues after rollback to 1.8.6 (before). Problem comes up even with no caches. (Tested with clean browsers.)

    Small screen sizes work as usual, on full size (10 main navigation entry points on desktop view) sub navigation levels are put to wrong places (at the end of the menu), not reachable for users.

    – If a user is logged in it works fine (all screen sizes).
    – If you open things in a small window and enlarge that window it still works.
    – If you load or reload a page directly in a large window (logged out) the navigation is broken as explained above.

    I will have to rollback things again, but leave it online for a while, so that the issue can be reviewed.

    It is possible that the bug was introduced earlier but not recognized yet as it seems to come up only on larger views for users without an active admin session.

    • This reply was modified 3 years, 1 month ago by fob.
    Thread Starter fob

    (@fob)

    Thanks,

    looks like the problem has gone in the meantime. Perhaps a caching issue after updating the plugin? However – the plugin now works as usual on home, posts, pages, … issues only show up on the blog page (if is_home(), !front_page()). Should be no problem anymore as editing works again, everywhere where it may be needed.

    fob

    (@fob)

    @visualdental14

    There is no images folder anymore. The ajax-loader.gif can now be found in a folder for assets. So there could be something wrong in your stylesheet.

    You can try to renew caches or the link within your stylesheets.

    (Perhaps your theme is using its own styles for some plugins but needs to be updated to address the latest change in “div.wpcf7 .ajax-loader” which is using “background-image: url(‘../../assets/ajax-loader.gif’);” now.)

    Thread Starter fob

    (@fob)

    Found the bug. It has to do with plugin options for statistics. The banner works if you say no to those options. (Should be explained why you insist on its usage then.)

    Thread Starter fob

    (@fob)

    Hmmm… okay.

    I checked out a few most recent themes, deactivated plugins one by one, deactivated code in Analytics (to be done by Complianz) … still get browser debugging issues with your cookieconfig.min.js file (complianz not defined) – tested with 3 browsers (Edge, Firefox, Chrome). Will reinstall caching and optimizing now.

    Thread Starter fob

    (@fob)

    Thank you for supporting this question.

    I played a bit with it yesterday but this did not help:
    – clearing the Cache
    – deactivating the Cache Tool
    – downgrading PHP version (7.x -> 5.6)
    – switching to Apache only (temp. no Nginx Cache))

    That is the reason why I installed another tool (in order to make sure jQuery is loaded early, then the Cookie tool.

    Cleared the browser cache and reconfigured it as well.
    (Just wondered why it seems to work for everyone else. :-))

    Right now I deactivated the caching and optimizing tools. Perhaps I will make a short test with a modern theme as well as the client is running on a very old one…

    I thought your plugin should be fully compatible with Analytify. Is it?

    Thread Starter fob

    (@fob)

    I seem to be able to turn off this feature in 8.1.2. (Looks like having 301 browser caching issues left, from earlier tests on earlier tested images.)

    If I do so I can make use of attachment pages as usual (get back and use WordPress standard behaviour).

    So instead of simply saying “yes” (use attachments) I now have to choose the following settings to bring back attachments and stop unwanted redirects:

    “Anhangs-URLs auf die Anhangs-Datei weiterleiten? NO”
    (IGNORE THE TEXT, ITS NONSENSE – just say NO.)

    “By enabling this option, attachment URLs become visible to both your visitors and Google. To add value to your website, they should contain useful information, or they might have a negative impact on your ranking. Please carefully consider this and read this post if you want more information about the impact of showing media in search results.” (IGNORE THIS TEXT, IT`S NONSENSE.)

    “Zeige Medien in den Suchergebnissen? YES” (Allow indexing.)

    “Datum in der Snippet-Vorschau Ausblenden”
    (Turn off the date in snippets, if you like.)

    “Yoast SEO Meta-Box Zeigen”? YES (Show the meta box).

    – Looks like having heavy translation issues here (for German versions).
    – Select button seems to work again (with 8.1.2).

    Hopefully users will recognize that their attachment pages are gone with one of the updates so that they have to reconfigure things like explained avove to get them back.

    • This reply was modified 6 years, 2 months ago by fob.
    • This reply was modified 6 years, 2 months ago by fob.
    Thread Starter fob

    (@fob)

    No. That one is a big bug.

    The button says (translated): “Want to redirect attachment urls to your attachment file?” That definitely must be the default setting but now it changes the WordPress default to a nonsense-feature that can not be repaired without removing the plugin.

    Thankfully I remembered where I have to search for problems like this first. Others may only wonder what the hell is going on that removes their attachment pages. “Did WordPress remove the feature or is it a Core bug?” No it is not…

    I did not change anything. Stats for yesterday seem to work again (all hours shown now, organic and total page views, since midnight, GADWP Version 4.9.6.2).

    • This reply was modified 7 years, 9 months ago by fob.

    Data was gone after midnight (impressions were cut 7 hours before in the graph). As predicted before it meanwhile came back. It was necessary to delete the cache again to refresh the graph.

    It looks like a ‘7 hour time lag problem’. (US time vs. German time?) Not sure if it takes exactly 7 hours (here) until the data can be refreshed.

    Hmmm… New day, new plugin version, same problem: 7 hours missing (deleting the cache doesn’t help). But I guess the data will be updated within the next 7 hours. ??

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