Matt Gibson

Great! Thanks for the help.

Yes, that’s correct, I’m using Ubuntu 20.04 LTS (Long-term support) which alleges that its PHP version is 7.4.3 but (I believe) backports hand-picked fixes from later versions to maximise stability and security. If your plugin works in PHP 7.4.30 the chances are excellent that it’ll work in 7.4.3 as the semantic versioning is basically meant to guarantee no breaking changes, API-wise.

Personally I’d risk it and declare that you support 7.4.3 (but of course, I would say that, as it would mean my automatic WordPress plugin updates would start working again!)

I’m a little confused — does this plugin now require php 7.4.30, rather than 7.4.3? It won’t update on my server (Ubuntu 20.04 running its latest available version, php 7.4.3).

Mine is a multisite install created before WordPress 3.5 (I think!). I have:

* No symlinks
* The WordFence diagnostics page suggests UPLOADS is “wp-content/blogs.dir/1/files/”. That location doesn’t exist. I have a wp-content/blogs.dir directory, but the numbers in there start from 3 (I think I probably deleted blog ID 2 at some point in the past.)
* No mention of UPLOADS in wp-config.php
* The main site’s Settings page in the Network Admin sites list says Upload Path is “/var/www/sites/wordpress/html/wp-content/uploads”.
* If I actually upload a media file to my “main” site (site_id 1, blog_id 1) today it ends up in …/wp-content/uploads/2022/05/

I’ve just emailed in diagnostics and scan logs. Hope that helps!

Matt

• This reply was modified 2 years, 6 months ago by Matt Gibson.

@staze Out of interest, is yours also a Multisite WP install? That’s about the only major thing that’s different about mine to most installations.

I’m seeing the same thing here—absolutely tons of errors saying things like “Unknown file in WordPress core: wp-content/uploads/admin-ajax.php”. There’s not an admin-ajax.php there, but it reports this error even on a new scan.

A “find” from the root of my WP install finds admin-ajax.php only in “wp-admin/admin-ajax.php”, as expected.

• This reply was modified 2 years, 6 months ago by Matt Gibson.

I don’t want to change to FS-based update rather than FTP—my setup is FTP for a reason—so I’m hoping there’s another solution apart from “don’t use FTP any more”…

Yup, seeing the same thing here, but only on one particular site. Nothing in the server error logs. Plugins went fine *before* I tried to update core, but reproducibly I just get a “blank” page after attempting an (FTP) update of core from 4.1 to 4.1.1. (Screenshot.)

Ah! Thanks; I’d searched the functions reference, but not the filter reference. Got it working perfectly now.

Ah, gotcha. I got confused because in the plugin directory, the big title is “Latest Tweets”. (I found it in the Plugin Directory with a Google search, thought it looked good, then went to my WP Admin Console and searched for “Latest Tweets” to find it from there and install it, at which point I found the similarly-named other plugin first in the result list.)

Ah — found my problem! I installed too quickly the first hit for a search for “Latest Tweets” in the admin “install new plugin” page. I installed the “Latest tweets” plugin, as opposed to the “Latest Tweets” plugin, which is from a different author, and doesn’t have that settings menu entry.

Sorry, it’s late and I’m clearly too tired to be configuring things ??

I’m having the same problem — bobdobbs, are you running a multi-site install, too? (I’ve activated the plugin on my single, main site, rather than network-activated it…)

Maybe it’s just something particularly weird with my setup, though it should be fairly “stock”. As long as you’re not getting complaints from all over the place, I guess you don’t need to worry ??

Cheers,

Matt

Nope, I followed the standard WordPress upgrade procedure through the admin interface.

I just reproduced the problem on my staging site. This is exactly what I did:

* Visit site homepage. No errors.
* Log in to admin interface
* Click the spinny-arrows icon in the admin bar to go to the WordPress Updates page
* Select Polylang to update, and click “Update Plugins”
* (Receive “Polylang updated successfully” message)
* Click on site name in admin bar

…and that took me to the home page, but with the $home_url errors on it.

I then headed to Polylang settings in the admin interface and hit the “Save Changes” button on the Strings translation page — when I went back to the home page, everything was fine.

Screen shots here, just in case you can spot anything odd that I’m doing:

* https://www.evernote.com/shard/s1/sh/08f4a71e-ecbb-4d11-9cd9-986d417f4245/79c75be820a7444f2b4333551070d0df
* https://www.evernote.com/shard/s1/sh/0218837b-c7c1-4ddd-8fb0-343af29774c9/4c930c1b77dbb6b10adc99fc51cf3a80
* https://www.evernote.com/shard/s1/sh/23dc97a7-5a53-44b5-b9af-8c481e317d4f/14a681636044dcbf6b83845a089971e2
* https://www.evernote.com/shard/s1/sh/ada1ab4c-c580-4d71-8d1b-8db5ab4cfd55/6dfa9b5dfc6fe0ecbcf4fee69a4567c3
* https://www.evernote.com/shard/s1/sh/a5b6af19-1d03-4281-8380-3ed16e9026f1/ad91c50579a46dbd2315ceb54a44b42d

(This isn’t a problem for me, by the way, now that I know the workaround; I just figured you might want to know what I’m seeing in case it affects anyone else…)

Cheers,

Matt

Sadly, I can’t reproduce this now. I’d rolled back the plugin to version 1.2 (I reverted the change in source control) and carried on working. When I re-updated to 1.3, I didn’t get the problem.

Let me know if you want me to test anything or try to reproduce the problem again. I’ve got a staging site that’ll still be on the original 1.2 that I can try upgrading…

Thanks,

Matt