Forum Replies Created

Viewing 9 replies - 1 through 9 (of 9 total)
  • Thread Starter darkdaze

    (@darkdaze)

    Yes, I think this has run its course. I’ve been floundering around at the edge of my knowledge here, so I want to thank you for your patient help. I’ll keep an eye out for further developments. In the meantime I need to decide whether to be brave and update the live site to 4.9! Best wishes.

    Thread Starter darkdaze

    (@darkdaze)

    No I’m not trying to make any changes at present, Jim – I apologise if I inadvertently gave you that impression. Everything is working as I want on the live site. The only errors are those related to the loopback timeout and the WP 4.9 editor on my development installation.

    I can’t even recall now why I tried editing functions.php – I was probably looking at the new syntax highlighting in the editor and decided to tweak a comment, then the timeout and error message prompted me to look further, eventually leading via that other long topic to here, since the evidence indicated that Pods was the cause. As well as trying to help myself, I hoped the info I was able to provide (meagre though it was) might help in working towards a general solution. I should just add how useful Pods has been in implementing my needs for the website (a series of articles with author, topic, source, date, etc).

    Thanks for your help – I don’t suppose there’s much else we can do here?

    Thread Starter darkdaze

    (@darkdaze)

    OK, I’ve added the recommended debug lines from https://codex.wordpress.org/Debugging_in_WordPress to wp-config.php. No errors appear in debug.log when I try editing functions.php, either with or without Pods enabled, or by browsing round the site etc. I can force a white screen by wrecking functions.php by editing it externally using ftp (I removed a closing bracket), and an error then appears in debug.log, so I know the debug system is working.

    Thanks for trying to replicate with a similar setup – it occurs to me that it’s entirely possible that I wouldn’t get this loopback timeout error if I upgraded my live server to WP 4.9: it’s a difficult bug to pin down.

    Thread Starter darkdaze

    (@darkdaze)

    Thanks again for the fast response, Jim. I am working on a development installation – my live site is still running WP 4.8.4.

    I hope I’m not misleading you in what the problem is. To help clarify things, I’ve now done the following:

    (1) Installed the Twenty Sixteen theme and enabled it
    (2) Manually deactivated *all* plugins
    (3) Edited line 2 of functions.php from /** to /** test. Almost immediately after clicking the “Update file” button I’m told File edited successfully.
    (4) Reactivated the Pods plugin.
    (5) Edited line 2 of functions.php again to /** test2. About 100 seconds after clicking “Update file” I get:
    Unable to communicate back with site to check for fatal errors, so the PHP change was reverted. You will need to upload your PHP file change by some other means, such as by using SFTP.

    I think that gets to the core of the problem. It’s nothing to do with the code in PHP files, and there are no other errors at all. As far as Pods itself goes, I’ve just got one CPT with 4 fields, a simple template, and 3 custom taxonomies.

    To me, the evidence indicates a conflict between Pods and the WP 4.9+ editor which, I read, now makes loopback requests (which I don’t understand). It obviously only occurs in certain circumstances, since not everyone is having this problem.

    What should I try next?

    Thread Starter darkdaze

    (@darkdaze)

    Thanks for the fast response, Jim – much appreciated.
    I’m using a child of the Hueman theme. But I get the same error with the parent or with Bootstrap Basic (the only other theme installed).

    I don’t think that what I’m trying to do with functions.php matters. I get the error when trying to edit a comment, or even trying to remove all its contents. I also get the error when trying to edit any other php file. It’s not an instant error message, it appears after about 2 minutes – a timeout. CSS files can be edited OK.

    There’s a long topic about this problem on that first link I provided. No-one seems to be sure what’s causing the loopback timeouts that were introduced with WP 4.9. I was following the topic, hoping for a resolution, but it has now been closed due to all the “me too” posts and a stated certainty that it’s not a problem in WP core code.

    So I ran the Health Check plugin as recommended and it’s pointed at Pods.

    I’m sure you’re right. For responsive themes the same cached file served to mobiles demonstrably works perfectly.

    Font size is being forced to 18px inline by

    <div class="entry themeform fittexted_for_entry" style="font-size: 18px;" >

    which must be unintentional!

    Thanks Rocco. Yes, it still occurs here with all plugins disabled. And per that github issue, it does only occur in the boxed layout.

    I’ve noticed that as well as scrolling, adjusting the width of the page quickly enough will also cause the topbar menu to render fully.

    It doesn’t seem to be browser dependent: recent versions of FF, IE and Opera all exhibit the same effect.

    I’m seeing the same problem. It affects only the topbar menu when it’s set to “always visible” or “Reveal on scroll up” (not if “not visible when scrolling page”) and only when using a header banner image. Interestingly it’s necessary to scroll faster than a certain speed to make the menu bar fully expand. As shown above, if the search field is set to display, the magnifying glass overlaps the last menu entry.
    Hueman 3.3.11 doesn’t show this behaviour, it started with update 3.3.12.

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