Cameron Barrett

I had this issue recently. I solved it by making sure all the caches were purged at your hosting provider: page cache, object cache, etc.

I did more digging on this. Clearing all of the WP Engine caches apparently fixes this. It’s unclear to me why.

The way I discovered this fix was I was only experiencing this issue on production and not Staging, so I started looking at the differences between the two environments and Googled and found a thread talking about WPE cacheing regarding another plugin.

If you are using WP Engine as your host, go into the WP Engine settings via the WP Engine Admin Bar and click the blue button that says “Purge All Caches. This clears the page-cache, the CDN cache and the object cache (if enabled).

This is a conflict with Bootstrap. There are some previous threads that explain how to solve this.

Yes, confirming that 3.0.12 has fixed this bug. Thanks for the fast bug fixes.

Not a bug but good info to know; marking as [resolved].

Yes, 3.0.11 fixes this issue. Thanks for the quick fix!

@chisss – The workaround for this bug is to manually change the date of the timestamp int eh File Upload overlay to European format.

22-10-2015 11:21

See the highlighted field input in this screenshot.

?https://www.dropbox.com/s/po5z62tng7x98m2/Screen%20Shot%202015-10-22%20at%2011.19.30%20AM.png?dl=0

Yes, that is the issue. We have set the date format to American formatting via Settings.

m-d-Y G:i

When you upload a document, it properly inserts the following date:

10-21-2015 11:22

And this causes the upload to throw that error.

When I manually change the date format to European formatting:

21-10-2015 11:22

The upload works correctly.

So, your upload code is assuming European formatting and is ignoring the date formatting defined in Settings.

As an addendum, I do notice that the files *are* added to the /wp-content/uploads/mdocs directory on the server (when I browse via SFTP or File Manager, I see them).

We’ll keep them in our stylesheet. Other plugins and themes are using Bootstrap, so adding them to your plugin CSS might cause other issues.

This is why we asked you for the .mdocs class somewhere in the beginning of the document HTML (body, head, etc) so that we can key off it for pages that load Memphis Documents bootstrap CSS, and over-ride it.

This is fixed with recent changes he made to .mdocs-modal in 3.0.7 and 3.0.8

We had this issue previously and it went away with recent updates.

We’ve finally pushed this to Production and all is well. Here’s the custom CS we had to add so there’s less Boostrap CSS conflicts:

.mdocs .row {
	margin-left: inherit;
	margin-right: inherit;
}

.mdocs .container {
	width: inherit;
}

#page .row {
	margin: auto;
}

Yes, adding those two lines of CSS to the bottom of mdocs-style.css fixes this issue.

Note: this bootstrap conflict is only happening in our Staging and production environments due to the CSS being loaded 9and required) at our hosting provider:

/wp-content/mu-plugins/wpengine-common/css/wpe-common.css

Please update your plugin and I’ll do some further testing in Staging before I update on Production.

Note: the updates to Memphis Docs work flawlessly in my local dev, which does not load the wpe-common.css file.

This doesn’t help me. I have no way to over-ride the CSS from:

/wp-content/mu-plugins/wpengine-common/css/wpe-common.css

You will need to create an exception in your plugin so that the conflicting bootstrap CSS classes do not conflict.

Yes, adding it to your mdocs admin CSS would solve this issue.

Here’s a screenshot of the left and bottom positioning declarations in your CSS turned off in Firebug.

https://www.dropbox.com/s/t7hj3e32u01zzfp/Screen%20Shot%202015-09-21%20at%201.18.23%20PM.png?dl=0