pikamander2

Interestingly, it breaks some of our PHP 8 sites but not others. Weird.

Here are the two lines in \app\Common\Utils\Filesystem.php that are causing the TypeError:

public function exists( $filename )
{
...
return $this->fs->exists( $filename );
}

public function getContents( $filename )
{
...
return $this->fs->get_contents( $filename );
}

It appears that these two functions are supposed to fall back to using @file_exists and @file_get_contents if $this->isWpfsValid() returns false, but for some reason that’s not happening here.

A workaround that I found is to modify the two functions to always use the fallback code:

public function exists( $filename ) {
    return @file_exists( $filename );
}

public function getContents( $filename )
{
    if ( ! $this->exists( $filename ) ) {
        return false;
    }
    return @file_get_contents( $filename );
}

But I’m not sure what the underlying issue is.

• This reply was modified 3 years ago by pikamander2.
• This reply was modified 3 years ago by pikamander2.
• This reply was modified 3 years ago by pikamander2.
• This reply was modified 3 years ago by pikamander2.
• This reply was modified 3 years ago by pikamander2.
• This reply was modified 3 years ago by pikamander2.

Although, interestingly, we’re on PHP 8.0.17, not PHP 8.1.

Regardless, the plugin is currently broken.

We’re on PHP 8, by the way.

Looking at the documentation for ftp_nlist, it seems that the behavior of the first parameter was changed. Perhaps the first parameter was allowed to be null in PHP <8 but not in PHP >8?

• This reply was modified 3 years ago by pikamander2.

I just checked and it looks like 4.1.9.1 is also bugged.

As a workaround, I went to https://www.ads-software.com/plugins/all-in-one-seo-pack/advanced/ and downloaded 4.1.8 and uploaded it via FTP, then disabled automatic plugin updates.

Hopefully the plugin will be fixed soon.

Same here, the update broke our site with the same error message.

We’re on PHP 8 if that matters. What’s your PHP version @tinkerjet?

Here’s a workaround that I found:

1. Rename the “wps-hide-login” folder via FTP/CPanel, which will force the plugin to deactivate.
2. Log in to wp-admin like you would normally.
3. Go to your wp-admin > Settings > Permalinks page.
4. Click “Save Changes”. Wait for the page to refresh.
5. Click “Save Changes” again. Wait for the page to refresh again.
6. Change the plugin’s folder name back to “wp-hide-login”.
7. Reactivate the plugin via the Plugins page.

WordPress has a lot of random issues that can be fixed using this method, so I’m not sure if this is a problem with the plugin itself or something involving WordPress’s core.

Here’s a workaround that I found:

1. Rename the “wps-hide-login” folder via FTP/CPanel, which will force the plugin to deactivate.
2. Log in to wp-admin like you would normally.
3. Go to your wp-admin > Settings > Permalinks page.
4. Click “Save Changes”. Wait for the page to refresh.
5. Click “Save Changes” again. Wait for the page to refresh again.
6. Change the plugin’s folder name back to “wp-hide-login”.
7. Reactivate the plugin via the Plugins page.

WordPress has a lot of random issues that can be fixed using this method, so I’m not sure if this is a problem with the plugin itself or something involving WordPress’s core.

It looks like we’re using a “legacy pricing table”, so I’m not sure if that’s related to the PHP warning at all.

Hi @gavinohanlon – It looks like this warning is occasionally appearing in the error log now:

PHP Warning: count(): Parameter must be an array or an object that implements Countable in /home/public_html/wp-content/plugins/easy-pricing-tables/includes/settings.php on line 9

Here’s the relevant line, which is part of the dh_ptp_settings_menu function:

$position = count( $submenu_list ) -1;

editor_script also seems to expect a single string. I haven’t seen any warnings/errors there yet, but I don’t think you’re supposed to be passing it an array either.

Based on this page, it looks like you’re supposed to pass style a single string and then you can use styles to pass additional styles via an array.

Based on this page, maybe it’s supposed to be named ‘styles’ instead?

@brainstormteam – Any updates on this?

Thanks @arnaudbroes – That option seems to work on all but one of our sites.

Strangely, there’s still one site where the search pages refuse to show the noindex meta tag. We’ve cleared all forms of caching (and tried a cache busting string) and tried toggling that setting on and off a few times, but nothing seems to help.

Do you have any idea what might be causing that to happen? If you know where the relevant code is located, I could try debugging it myself.

@arnaudbroes – Sorry, I just realized that I had originally posted about feeds.

For my last comment, I was talking about search results. WordPress now noindexes those by default, but it seems like they aren’t being noindexed if AIOSEO is active.

I tried the setting you mentioned above, but it doesn’t seem to have an effect on search pages. We need those to be noindexed due to the spam problem.

Example URL: https://example.com/?search=test