"Add Files" not working

mkoenen – Check the source of the page. See if the following scripts is being loaded: buddypress-docs/includes/js/bp-docs.js. If so, see whether it’s being loaded *before* or *after* edit-validation.js and attachments.js. This is a starting point for figuring this out.

It’s possible that wpengine is auto-concatenating your scripts for you, and it’s being done out of order due to improper enqueuing on my part.

Another quick question – are you running SSL/https on this production site?

You are right, bp-docs.js is not loading.

We also had difficulties with activity stream commenting not working. To make commenting work I started enqueuing the necessary scripts from my child theme functions file. It worked for comments.

So I tried enqueueing bp-docs.js from my functions file. After doing so it loaded after attachments.js and before edit-validation.js and the button was still not working. I commented the line out again in order not to confuse things.

We are not running SSL/https.

I am giving you access to our staging environment.

*Bump. Having the same problem.

Experiencing the same issue. Seems to be specifically related to WPEngine.

If you are running Buddypress Docs 1.8.4, FTP into your server, go to your plugins folder open buddypress-docs > includes > attachments.php.

Find the line that reads wp_enqueue_script( 'bp-docs-attachments', plugins_url( BP_DOCS_PLUGIN_SLUG . '/includes/js/attachments.js' ), array( 'media-editor', 'media-views', 'bp-docs-js' ), false, true );

Change this line to `wp_enqueue_script( ‘bp-docs-attachments’, plugins_url( BP_DOCS_PLUGIN_SLUG . ‘/includes/js/attachments.js’ ), array( ‘media-editor’, ‘media-views’ ), false, true );

I’ve made another attempt at fixing this in 1.8.5. Please test.

I am sorry to say, it is not working for me.

Again, and even in this new version, if I go to attachments.php and change the line wp_enqueue_script( 'bp-docs-attachments', plugins_url( BP_DOCS_PLUGIN_SLUG . '/includes/js/attachments.js' ), array( 'media-editor', 'media-views', 'bp-docs-js' ), false, true );

to

wp_enqueue_script( 'bp-docs-attachments', plugins_url( BP_DOCS_PLUGIN_SLUG . '/includes/js/attachments.js' ), array( 'media-editor', 'media-views' ), false, true );

it works. Thus, just taking out , 'bp-docs-js' makes it work for me.

I did realize just now that 1.8.4 gave me a 404 when opening “child” docs (I was not aware of that issue before). 1.8.5 fixes this issue.

Thank you so much for that.

Sorry to hear it’s still not working. I’m afraid I’m a bit at the end of my ability to guess at the cause of the problem. Removing ‘bp-docs-js’ from that line is *not* really a general fix for the problem. You may want to reach out to WP Engine to ask whether there’s anything specific that developers should know about the way they enqueue/concatenate scripts.

After many hours of hair pulling and tears when this issue cropped up in a client project, I came across the answer, and it’s ugly.

WPEngine has, at some point, started loading an action via their wpengine-common mu-plugin. They call this the “Heartbeat Throttle” which is a very nice way of saying “disable the WordPress Heartbeat API by default for everything except the post editor in the dashboard.”

There is a filter available to add dashboard pages to the list of allowed pages called ‘wpe_heartbeat_allowed_pages’ but it only applies to pages that might be set as the global $pagenow variable, so it’s useless for the front end in the context of sane workarounds.

The only way to completely disable it, is to have WPEngine toggle off the WPE_HEARTBEAT_AUTOSAVE_ONLY environmental var (yes, you read that correctly, an ENV var).

As a side note, this also breaks the BuddyPress activity heartbeat feature.

I have a ticket open with WPEngine asking where this “performance feature” is documented, because surely disabling a core WordPress API would be useful information for developers and customers alike.

Thank you, @mrmaz for the information. We contacted WPEngine again about this issue, gave them the information you provided and this time they were able to help us. They enabled heartbeat and everything is working for us now.

@boone, thanks again for all your help with getting BuddyPress Docs working for us. In the end it was a combination of enqueuing scripts differently, getting Transposh to make a code change as not to create a conflict and getting WPEngine to enable heartbeat. Phew! So happy docs are working like a charm now!

@mkoenen Can you document what you did to get up and running? I am also working on a client project on our wpengine server. I have already had them make @mrmaz change to the WPE_HEARTBEAT_AUTOSAVE_ONLY environmental var and still have no button functionality… Any help much appreciated.

@kdagnall you can test to make sure they disabled it by running this code

var_dump(getenv('WPE_HEARTBEAT_AUTOSAVE_ONLY'));

If that returns “on” then whatever they changed didn’t work for the install you are testing.

If its definitely NOT “on” then view the source of the page and make sure that the heartbeat.js is being loaded, as well as bp-docs.js. If those aren’t loading you will definitely see some errors in your browser’s JS console.

Ignore the code change I recommended at the top of the page. Make sure you have updated BuddyPress Docs to 1.8.5.

If heartbeat is running you should have no further problems.

We had an additional issue due to a conflict with the Transposh translation plugin which the developer fixed for us. So make sure you have no other plugin conflicts by turning all other plugins off.

Thanks everyone, the problem is that WpEngine seems to be unable to turn off WPE_HEARTBEAT_AUTOSAVE_ONLY

They claim to have it off, but var_dump(getenv(‘WPE_HEARTBEAT_AUTOSAVE_ONLY’)); still returns: string(2) “on”

@mkoenen – I’m wondering how they managed to do it for you? My support guy was telling me he’s sure it was off but I’m seeing no change?

EDIT: After nearly 2hours of them trying I gave up for the day. Will try again tomorrow. This is the third client I’ve had a problem with WPE heartbeat, though usually it’s in the dashboard where I have a workaround.