ZachMatthews

I should also mention, my host recently underwent a total meltdown and had to restore my site from a backup server.

I originally installed (I think) WordPress 3.4.8 or something around that – just before 3.5 came out. I’ve been upgrading as normal along the way.

I’ve just noticed that the new images I upload are being placed in a /blog/wp-content/blogs.dir/2/files/2018/11/ subdirectory, whereas all my older site content (which is still accessible) is located in, for example, /blog/wp-content/uploads/2018/05. Right now I can see the stuff in the blogs.dir subdirectory tree but my site cannot access the materials in the /uploads/ subdirectories (although I can FTP it and it is all still there).

I feel like this site is close to my issue but I am not sure exactly how to check “compatibility mode” for pre-3.5 era multi-site installs.

https://updraftplus.com/faqs/i-am-restoring-a-pre-wordpress-3-5-multisite-into-a-3-5-or-later-multisite-what-happened-to-my-blogs-dir/

Note: upgrading to latest version of my theme fixed it.

That’s my site. The short version is, you can make it work in onecol layout if you’re willing to go through and edit a whole bunch of CSS to make the board fit. I copied in my entire stylesheet in the link to give you a headstart.

All I do is use Chrome’s Web Developer extension to individually ‘inspect element’ on each piece of layout that I need to change, then go copy that element’s CSS tag into the Theme Options/Layout section of Pinboard. Pinboard’s stylesheet there will load last and therefore override all earlier CSS, allowing you to make changes which stay consistent after updates, for the most part.

As far as I’m aware I’m the only one who’s taken the time to make bbPress work with Pinboard. I also used a Multisite setup so I can use Pinboard’s core functions on other parts of my site.

You can see it here:

itinerantangler.com

Right now I am working on trying to figure out how to make the slider scroll on every sub page instead of just home pages.

Note: upgrading to latest version of my theme fixed it.

I have the same problem and forcing that code to load didn’t work for me either. This issue seemed to crop up after the last update based on my site’s log of the last time a user was successfully able to upload a photo.

Not sure I would call this one resolved man. I have simply had to quit using the plug in now. I was hoping with the most recent update it would be fixed, but it wasn’t.

They were working together before the recent update, no problem at all.

That’s a really substantial change to what was a pretty primary feature.

I implemented the change. It returned functionality to one of my two instances of WP Ultimate Search, but not to both. I am using a multisite. In one instance I have the WP Ultimate Search widget running in the right hand sidebar and it works fine:

https://www.itinerantangler.com/blog/

However on the other instance of the multisite I have the search bar in the footer, and it is not functioning:

https://www.itinerantangler.com/blog/podcasts/category/podcasts/

I have tried disabling/enabling the plug in on the broken multisite. I have removed all custom CSS for now as well, and I have made sure the settings for the plug in mirror each other. I can’t figure out why the version of the plug in running in the footer just isn’t doing anything. It isn’t returning a ‘No Results Found’ response; it simply returns no response whatsoever.

I was using a custom results template. However I can’t find any information on the updates I need to make. Can you link me to the release notes? Thanks,

Zach

It’s a timing thing rubious. I think you need to browse around long enough to trigger a 302 unchanged response from the server when you refresh a page you visited earlier. On my server I think the trigger time is 5 minutes, so you would just need to spend some time on one of these sites to start triggering it.

Zach

No fix, rubious, and it’s still happening for me in Chrome Vanilla but not Chrome Canary.

It’s clearly a Chrome bug.

Hey, some good news. If you download Google Chrome Canary, which is their Beta build, the problem has been resolved. This is pretty clearly a Chrome issue with its current build.

The fix didn’t work. It appeared to with Chrome OS x but the problem remains in Chrome for Windows (on a completely different computer).

Sorry guys, it doesn’t sound like we’re going to get help on this from WordPress and I am out of ideas.

Zach

Ok people, here’s a potential temporary fix for you.

This issue seems to be a problem with Chrome’s handing of browser cacheing, specifically related to 304 responses from your server, which tell Chrome nothing has changed with a file.

Until Chrome fixes this problem, one thing you can do is turn off browser cacheing, which may slow your site down somewhat. (My server was fast enough not to cause too many issues but this is probably not a good long-term fix).

To turn off browser caching, modify the header.php file in your theme, adding the following adjacent to the other < meta > tags:

<meta http-equiv="cache-control" content="max-age=0" />
<meta http-equiv="cache-control" content="no-cache" />
<meta http-equiv="expires" content="0" />
<meta http-equiv="expires" content="Tue, 01 Jan 1980 1:00:00 GMT" />
<meta http-equiv="pragma" content="no-cache" />

That will instruct the browser not to cache the files, but instead to re-load all files (200 Request) with each refresh. Again, this may slow your site some but at least your users will see the content.

If anyone has any suggestions on making this Chrome-only so that non-Chrome users don’t lose cacheing, I am all ears.

Zach

https://code.google.com/p/chromium/issues/detail?id=246875

That’s the chrome issue report page.