Lee

Open_basedir is a PHP security restriction added to either php.ini or a site’s virtual hosts file on the server. It prevents PHP from accessing directories above the directory specified by the open_basedir directive. Not sure the solution in this case but I wouldn’t lift the restriction. There’s a little more about this here.

As a basic explanation,

if the path to your site relative to the server is

/var/www/your-site/

and WordPress is installed in the site’s root directory (/your-site/) then the path to wp-content would be

/var/www/your-site/wp-content/

and the plugin would be stored in

/var/www/your-site/wp-content/plugins/wpsearch/

Open_basedir would normally be configured in the virtual host file for the site to prevent PHP scripts from looking outside of the site’s root directory. That’s to say

php_admin_value open_basedir "/var/www/your-site/"

This keeps hackers from making a mess of all sites on the server if they manage to upload a PHP shell below the ‘/your-site/’ directory.

Are you running WordPress on a home or dedicated server?

Hi Joo-Joo, I developed the plugin. I am sorry for replying so late but I completely missed your support request. I’m glad you resolved the issue you had and definitely glad to know it wasn’t caused by TinyMCE span.

Thanks for keeping us up-to-date ??

Same issue. You can get the images here

https://github.com/chipbennett/cbnet-ping-optimizer/tree/master/include/images

In fact, it looks like a more recent plugin version.

You’re welcome and I’m glad it’s fixed for you too.

The latest version released overnight has fixed the issue for me. The new version is 1.2.1.

For those with connection/authentication issue, either whitelist the WordPress servers in your .htaccess file rewrite/firewall directives using the rules in my above post OR temporarily remove any directives in your .htaccess file that are not essential for WordPress to function e.g keep “DirectoryIndex index.php” at the top and keep “## BEGIN WORDPRESS”, “## END WORDPRESS” and the bits between the WordPress block then authenticate then replace the bits removed from your .htaccess file (put them back where you found them).

I think we’ll need an update before we can again view the stats page. The final bar in the little graph in my admin bar still seems to be growing so the plugin’s probably working even though I can’t view the admin page.

Place these whitelist rules above your .htaccess rewrites to whitelist the wordpress.com servers:

RewriteCond %{REMOTE_ADDR} !74\.200\.244\.
RewriteCond %{REMOTE_ADDR} !76\.74\.248\.
RewriteCond %{REMOTE_ADDR} !66\.135\.48\.
RewriteCond %{REMOTE_ADDR} !69\.170\.134\.

There might be other IP addresses too. If there are, I’d love to know.

You need to disable and re-enable the plugin then reconnect with WordPress. However, though the stats menu will again be visible, you might still suffer the permissions issue when trying to view stats. I know this because I’m suffering the same problem since today’s update.

If you have strong rewrite rules in your htaccess file you might need to whitelist the WordPress servers to permit the plugin to connect with wordpress.com for registration. I’ll give you the details if you need them.

Prior to installing BuddyPress the site worked perfectly – new sites registered without fault.

I will do, thanks esmi.

Fantastic! ‘Cause you wouldn’t have liked the next option – creating an English language file for it. Glad it worked.

You’re welcome. Good luck with your plugin ??

I suspect you have a plugin installed that’s preventing Jetpack from properly detecting the language used by WP. Try temporarily disabling all plugins then re-enabling Jetpack before authorizing it to connect to wordpress.com. Please let me know the result.

Hi Bjornat, I posted this in response to your question at my blog, it should help:

Explicitly set a language for WordPress. Browse the directory that contains all of files used by WordPress. Edit wp-config.php to change the bit that reads

/**
 * WordPress Localized Language, defaults to English.
 *
 * Change this to localize WordPress.  A corresponding MO file for the chosen
 * language must be installed to wp-content/languages. For example, install
 * de.mo to wp-content/languages and set WPLANG to 'de' to enable German
 * language support.
 */
define ('WPLANG', '');

Change the bottom line to

define ('WPLANG', 'en');

or

define ('WPLANG', 'es');

or to reflect whatever language files you have installed in “wp-content/languages”. The bit that specifies the language used by WP is ‘en’ (for English) or ‘es’ (Spanish).

If wp-content/languages doesn’t exit (which it will do because you’ve correctly installed Kau Boy’s Backend Localization), create it. Get your language packs from https://svn.automattic.com/wordpress-i18n.

Now try to install Jetpack again. It’s safe to revert “define (‘WPLANG’, ‘es’);” back to “define (‘WPLANG’, ”);” once Jetpack is installed. Make sure it correctly reflects the backend language chosen for Kau Boy’s plugin.

I had this issue. Solved it by changing the backend language to Spanish , connecting Jetpack to WordPress then reverting back to English.

My site is a WP MS installation running in English. Always has been in English. I used kau-boys-backend-localisation plugin to change the language.

Thanks for pointing that out, Esmi.