rlamb2

Apologies, I haven’t been in my email all weekend.

It was happening with my client’s remote site as well as on my local homebrew setup with almost no adjustment, so I don’t think it has anything to do with server configuration, though I will check out that Github repo to see if there’s anything in there that can help.

What I ended up doing was manually fixing the dozen or so _wp_attachment_metadata serialized values that had strings where numbers should be and (educatedly stupid, I already know) adding (int) to those lines in the Elementor plugin, hoping a fix was coming in the next update.

Seems as though it didn’t, so I’ll need to apply that fix again.

As for steps to reproduce it, it seems to be from using a custom image size. That’s it. Elementor stashes the custom image size as part of the available sizes for that attachment, and because the regex pulls them out of the elementor_custom_###x### image size name as strings that get sent directly into that serialized array, when WordPress functions try to compare requested sizes (being actual numbers) with known sizes (now sometimes being strings), it throws type errors.

I see the Repo already has an issue open for this too, so I’ll probably end up dropping some of these notes over there as well.

Same issues here — plugins are installed, configuration is set, but the actions in the page don’t run to load in the CSS/JS. I’ve added error_log statements into every function and the only one that seems to do anything is the adhs_init function and anything defined for the admin area.

Tracking that a bit more, I started realizing that the functions stopped working as soon as the server would encounter a closing PHP tag in your script — I changed the add2homecustom function to a series of echo commands instead of closing and reopening PHP and suddenly the CSS and JS files were enqueued. Probably something there to work with. Maybe WordPress only reads the main plugin file until it encounters one of those?

I’m running PHP 7.2 locally on my Mac, and having the same issues running PHP 7.0 on Ubuntu. Both systems using Nginx and PHP-FPM.

Side note: the code in the plugin is kind of messy. Difficult to follow through. Good for N years ago, so I’m glad to hear you’ve revisited the plugin and are working to improve it.

Might I recommend some refactoring: use wp_localize_script, don’t wrap everything in an if statement, use consistent indentation, and maybe split the code into a couple separate files (admin and frontend, at least).

Or, to resurrect a dead thread and correct myself a bit, how can I help write this functionality that I think would be useful for other people?

I’m having the same problem.

After a little debugging, I found that the Facebook autoloader is trying to load /wp-content/plugins/wordpress-social-login/hybridauth/Hybrid/Providers/Facebook.php but my production site has the file as /wp-content/plugins/wordpress-social-login/hybridauth/Hybrid/Providers/facebook.php, with a lowercase F.

Renaming the file makes it work again.

As for why that’s the case, it looks like the older version of the Facebook PHP SDK had a file named facebook.php. The newer SDK has a file named Facebook.php that the WSL plugin upgrade will have dropped into that same place, replacing the facebook.php file from before. Could just be that git or the file system or something decided not to change the case on that filename.

As for my configuration, in case it helps debug further—MacBook Pro, plugins updated locally using wp-cli, changes pushed through git to gitlab, merged, and pulled onto Ubuntu server.

Yeah, that’s a solution for right now…

Doesn’t help what I can only assume are a not-small number of people who have both W3TC (with 1+ million installs) and TEC (500,000+) or WooCommerce (3+ million) installed, but are missing out the speed enhancements of minifying some or all their CSS because it breaks how the other plugins look on their computers (that’s assuming they notice at all—I missed it since activating it yesterday).

I know it’s not a simple two lines of code fix, but I’d definitely suggest it somehow gets added either here or to that w3-total-cache-fixed project over on GitHub. Need an issue there? I’ll write one. ??

I have the same issue.

What I’ve found is that because the videos are protected, the dimensions can’t be pulled out of the Vimeo API that the plugin uses to determine the aspect ratio of the video. It outputs the video player embed code, but places it inside of the responsive container with no height set.

The option to force the 16:9 ratio doesn’t seem to work either, since that condition happens inside of a block that requires the API to return valid embed information.

@jamie3d, is there any way to have it where if the API can’t get the information, but the embed code works, it can just use a default 16:9 ratio on that responsive container? Even better, if you’re determined to have that ratio, would be to regex out the width/height out of the iframe code and calculate from that.

Just some ideas….

Strange…. only seems to happen locally. Must have some screwy setting somewhere then.

I’ll mark as resolved, but I still wouldn’t mind hearing if anyone else has come across this themselves.

(Or that’s way off because I see it’s been like that since it went in well over a year ago. ?? )

Scratch that. (If I could html strike it out, I would.)

Even better, y’all are already on it!

I can verify it. Not working right for me either.

I believe I’ve traced it back into paypal-wp-button-manager-admin.js, where the onselect is using _value, but shorcodeValues has options using value without the underscore.

Haven’t fully tested the fix, but that should be enough for an update or a place to start, at least. Hope that helps!

Speedy update! ??

Looks like there’s a period that should be a comma. Fixed it for my site, but an update will probably be necessary pretty quick. ??

Same here. Turned on the debug log for a bit and found that when I filled out the CAPTCHA and submitted the form, I got two PHP warnings:

• file_get_contents(): https:// wrapper is disabled in the server configuration by allow_url_fopen=0
• file_get_contents(https://www.google.com/recaptcha/api/siteverify): failed to open stream: no suitable wrapper could be found in…

Might just need to be rewritten with cURL?

Or switch plugins… That works just as well. Sorry. ??

Finally, it looks like they’ve been made aware and fixed it. We’re all just waiting on a plugin update. ??

https://github.com/Yoast/wordpress-seo/commit/af26999e07d7635422545aaaf224be4a5b9b8d1e

Looks like they already knew and partially fixed it. We’re all just waiting on a plugin update. ??

https://github.com/Yoast/wordpress-seo/commit/af26999e07d7635422545aaaf224be4a5b9b8d1e

What it doesn’t do yet though is save the “empty” or default values (and by save, I mean delete the chosen values) for the fields in the advanced tab. Already let them know. Hopefully a fix will come through soon.

For the description, try setting it to a space. Yoast currently has a check in place for various empty values, but a space will get through. This I found yesterday when testing some things.

WordPress seems to handle single space meta fields as needing to be emptied and just saves it without that space, or at the very least, doesn’t output the space in the backend.

I haven’t tested, so I can’t guarantee that Yoast won’t just try to give an empty meta description for those pages though. If it works the way I think it will though, it’ll determine the description you entered to be empty and generate one for you again.

Hope that helped!