That’s interesting. If I’m reading the error right, you’ve added a German translation to Content Progress, but have placed it in the wrong directory. Translation files should be in the ‘lang’ directory.
This could also indicate a file permissions issue, where your uploaded translation file has different permissions than the default installed files.
Either way, there’s nothing I can do about this, since it relates to a file I didn’t provide. If you want to provide me with your translation file, I would love to add it to the plugin so that others can benefit from it.
Thread Starter
BeeCee
(@csigncsign)
No, I haven’t made anything at all (no file changes, no translations) – just activate your plugin “as is”.
And then at the top of my backend appears this error.
I deactivated all other plugins – without success.
Using HUEMAN theme from http://alxmedia.se/themes/hueman/
It seems as if the network path is not right?
Does the plugin try to add a content-progress-de_DE.mo file?
I have no such file in my ftp plugin’s folder, only your .pot:
http://screencloud.net/v/EIw1
and the “lang” folder:
http://screencloud.net/v/bLnP
No, it doesn’t add that file, or attempt to. It seems like your installation is looking for it, and throwing an error on failing to find it.
Looking for the file is a normal part of what WordPress does, in checking for translations, but is don’t know why it would throw an error on failing to find it.
Looking at the path, it looks like an invalid path, which could be the source of the problem. It doesn’t look like Content Progress is registering an invalid path for languages, however, so I’m not sure why that would be.
Is this a stand alone install or a multisite network?
Thread Starter
BeeCee
(@csigncsign)
it’s a multisite installation with sub-blogs in sub-directories. I’ve never seen this error with no matter what plugin … very strange …
I’ve never seen this either, but I’ll see if I can reproduce this in that type of environment.
Thread Starter
BeeCee
(@csigncsign)
Thanks a lot, appreciate your help!
I haven’t been able to reproduce this; I’ve set up a multisite installation in German, added Content Progress – but can’t reproduce the error.
An open_basedir restriction means that your server is restricting access to directories, so you may want to talk to your host or server manager to see if they have a suggestion; a change to your httpd configuration file may be what you need.
Does this happen if you install other new plug-ins?
Thread Starter
BeeCee
(@csigncsign)
No, I haven’t seen this at all
I add to this issue, since I face it as well.
My current setup is:
Latest WordPress Version
Latest Content Progress Version
OS: Ubuntu 12.04 LTS
Plesk 11
open_basedir on for security reasons
I have a single WordPress Installation and so far only Timthumb (fixed it) had issues and Content Progress.
There seems to be an issue with reading the lang files properly, because the path “…/wp-content/plugins/content-progress/content-progress.php/content-progress-de_DE.mo” seems to be invalid. It causes high loading times :/
I surely am not a PHP Coder, but I think it comes down to this line (and what is attached to it):
load_plugin_textdomain( ‘content-progress’, false, dirname( plugin_basename( __FILE__ ) . ‘/lang’ ) );
I fixed it.
Change:
load_plugin_textdomain( ‘content-progress’, false, dirname( plugin_basename( __FILE__ ) . ‘/lang’ ) );
to
load_plugin_textdomain( ‘content-progress’, false, dirname( plugin_basename( __FILE__ ) . ‘./lang’ ) );
The dot is missing before /lang. This results in a directory resolving issue on Linux Machines.
That sounds like plugin_basename( __FILE__ ) isn’t returning a result. Can you verify that?
I added the dot to ‘/lang’ to have it read ‘./lang’ and since then I have no further issues and also error_log from Apache2 no longer spits out anything regarding Content Press having an issue with open_basedir.
Yes, I understand that. Can you confirm whether plugin_basename( __FILE__ ) returns a result in your installation?
How do I check that? I am sadly not that highly experienced with WordPress nor with debugging something :/
You’d need to be able to add a line of code to echo the value of plugin_basename( __FILE__ ) into the plug-in; would you be comfortable doing that?
Somewhere in an HTML context, you’d add:
<?php echo "Plugin Basename: ".plugin_basename( __FILE__ ); ?>
