Wow ! are the menu items not showing only or also missing in the source code ?
And as you see it’s not affecting buddypress, but WordPress.
Suggest you ask on their forum.
When all the plugins are disabled, the dashboard is 100% visible. It is only when we reactivate BP that this happens (with all the other plugins disabled).
This leads us to believe it is not a WP issue but a BP one.
This is also affecting coding on the front end of the site that users need for interaction.
Thank you for your help….
Themes can also interfere with the admin area. Which theme are you using? Does the problem happen with Twenty Thirteen activated?
@henrywright, yes we have activated multiple themes including the parent and twenty fourteen and the problem persists.
I’ve checked the wp-config.php to see if something looks screwy in there but everything seems to check out. Could this be some corruption in the database or is it more likely something on the front-end?
What makes you think the db is corrupted? In theory what you see in the screenshot could simply be caused by some rogue front-end CSS.
@henrywright
- CSS isn’t hiding this missing text. It’s simply not loading. I inspected it to see if it was hidden. It is not.
- This is only happening when with the BP plugin. I’ve tested it with every other plugin and nothing else is doing this
I can’t explain it otherwise. If it’s not any other plugin, it’s not a theme, then either it’s a virus/trojan that’s made its way onto the server or it’s DB corruption.
If only the text strings are affected, language files spring to mind. Are you using any of these to translate strings? Looks like BP strings only are affected. Could your buddypress .mo file be corrupt? (If you have one?)
We do have one in /wp-content/languages/buddypress-en_US.mo and it looks like this:
fiï 4L 'aâê°
2>%1$s posted an update in the group %2$sMembers <span>%s</span>Project-Id-Version: BuddyPress
Report-Msgid-Bugs-To: http://wppolyglots.wordpress.com
POT-Creation-Date: 2013-12-17 18:35:37+00:00
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
PO-Revision-Date: 2014-02-26 17:12-0800
Last-Translator:
Language-Team: LANGUAGE <LL@li.org>
X-Generator: Poedit 1.6.4
Plural-Forms: nplurals=2; plural=(n != 1);
Language: en_US
%1$s postedFriends <span>%s</span>
The mo file is a compiled file.
If you want to use it, you have to edit the po file with poEdit or similar software.
You say
This is also affecting coding on the front end of the site that users need for interaction.
Which coding are you telling about ? Are your user allowed to publish code on front-end ?
@danbp
We have previously edited the .po file with poEdit but I was just pasting the contents of the .mo file for @henrywright.
As for front-end users interaction, I think we solved that problem. The way in which it is affecting the front-end is that button text is not appearing in some places. It doesn’t make sense.
@micasuh the .mo file is most likely being loaded from your theme’s functions.php file. Alternatively, it may be loaded from a plugin. Or, maybe even bp-custom.php (if you have one of those).
Look for something such as the following and try removing it to see if it resolves the issue:
if ( file_exists( WP_LANG_DIR . '/buddypress-en_US.mo' ) ) {
load_textdomain( 'buddypress', WP_LANG_DIR . '/buddypress-en_US.mo' );
}
If it doesn’t resolve the problem then we know your translation file is OK.
If you still believe the issue is a virus in your database then you could try rolling back. Do you keep database backups? But, to be honest, I’m more inclined to think this is occurring as a result of some rogue theme or plugin code.
@henrywright the only plugin activated is BP. We have switched out to different themes, including Twenty Fourteen which has no reference to BP, and the problem persists. I understand what you’re saying but this can’t be a problem with every theme we’ve tried.
I said corrupt database because I can’t find any other explanation but I know that there’s often some rogue file that’s causing these types of problems. I just wish I knew how to locate it.
@micasuh humm. Perhaps try grabbing a fresh copy of the BP plugin code? https://wordpress.org/plugins/buddypress/
Something may have become corrupted in the actual plugin.
@henrywright i already did this and same problem persists. :/
If you’re using BuddyPress 2.0.2 with WordPress 3.9.2 with no plugins activated or even installed in the plugin folder and the Twenty Fourteen theme enabled then everything should work fine as this is a tried and tested combo. The only variables left are a) your server and b) your database.
Perhaps try rolling back your database? And also make sure there has been no changes on your server since you noticed the issue.
@henrywright I think I found a pattern in that text that doesn’t render always has <?php _e( at the beginning, which is in relation to the translation file, right?
@micasuh _e( $text ) will search for the translation of $text and print it to screen. If a translation doesn’t exist, it’ll print $text. You might also come across __( $text ). This does the same but it returns instead of printing.
So yeah, these functions are definitely related to translating.
@henrywright Okay, I can verify that this problem is happening for both _e( $text ) and __( $text ). I can’t verify that it’s every single instance of this (are the Dashboard menu dropdowns also using these functions, such as Add New, Categories, etc.?)
What does it mean that these functions render properly when I deactivate BP plugin?
Figured it out. There’s a function in bp-custom.php trying to filter gettext and the domain is incorrect so it was causing all these problems. What a headache!
@micasuh great stuff, glad you found the problem in the end!
