cojennin

Very strange. I would say this might be a permalinks related issue, but the fact that you can download files that end in .doc but not .docx seems a bit odd…

Sorry for all the questions, but the more info the better chance there is of figuring this out. Do you have the most recent version of WP Document Revisions? Are you using the WP Document Revisions ‘document_extension’ filter in any way? Did you change the WP permalinks recently? Do you have any other plugins (seo especially) installed?

I have been unable to recreate this issue in the following scenarios, using Google Chrome, Firefox, Safari, IE9, IE8, and Google Docs (to create and save files in .xlsx and .docx), WP 3.5.1, :

Scenario 1:
1. Create and save a document (file.docx) in Google Docs in .docx format
2. In WordPress, create a new document
3. Upload file.docx to WordPress
4. Download file.docx from the backend by clicking the “download” link
5. Download file.docx after being inserted in a published post
6. File correctly displays the .docx file format without the addition of .doc

Scenario 2:
1. Create and save a document (file.xlsx) in Google Docs in .xlsx format
2. In WordPress, create a new document
3. Upload file.xlsx to WordPress
4. Download file.xlsx from the backend by clicking the “download” link
5. Download file.xlsx after being inserted in a published post
6. File correctly displays the .xlsx file format without the addition of .xls

Maybe IE 7 is the issue? If anyone is still encountering this issue and could give some more information on what version of WordPress, WP Document Revisions, and what browser they’re using, that would great.

Try using the global $wpdr class.

So let’s say I did:
$posts = get_posts ( array( 'post_type' => 'document' ) );

And it returned an array with one document in it, I could do:
$wpdr->get_file_type( $posts[0] );

And that would return the file type of that post. Feel free to post back here if you’re still having issues implementing it.

I don’t have a WAMP environment set up at the moment, but I can do so in a few. Do you have anymore information on this issue before I get around to it? Is it giving you any sort of error? Do you have an odd WAMP setup (something very non-standard, etc.)?

There might be an easier way to do this that Daniel could point to, but off the top of my head I would probably start with the following:

add_filter('views_edit-post', 'add_custom_post_types');

function add_custom_post_types($views) {
	$views['assigned'] = '<a href="?post_status=assigned&post_type=post">test</a>';
	return $views;
}

Mind you, this is nowhere near complete. You’ll need to add some more code to have it show how many posts there are of that post type, to show as selected, etc. But ‘views_edit-post’ should be the filter you need to take advantage of.

If you need anymore help with the code, just post back here.

Yea, there’s an issue with changing this, and I’ll point you to the original reason for why this filter was created. Here’s the original issue a user was encountering. Given that you use the Editorial Calendar you might no end up running into this issue very often, in order to see this problem in action do the following:
1) Make a post on todays date from Editorial Calendar
2) Give it a time before the current time
3) Edit that post
4) Publish it

You might notice that when you publish it, the “published time” doesn’t update to the current time. That’s the problem that EditFlow tries to navigate around with this filter. Nonetheless, I’ll continue to look into this to see if there’s anything that can be done.

If you made “Syndicated” a custom post status, I believe then that yes, it would be the case that you could have posts continue to show up on the site. Just make sure to alter your loops to include it.

This is the line you probably want to base the changes to your loop(s) off of:

$query = new WP_Query( array( ‘post_status’ => array( ‘pending’, ‘draft’, ‘future’ ) ) );