Ben Balter
Forum Replies Created
-
Marking the post as resolved (development version) and look for a stable release soon.
1) the quick solution would be to hide the media menu, but they could theoretically still access it directly by the URL. You’d have to use the
map_meta_capfilter (perhaps adding another capability and simply checking the current screen) to distinguish between the two contexts. Out of the box, neither core nor the plugin make the distinction.2) If the documents can be public, try making them public? If they cannot be public, I believe draft may solve this problem (and remove the capability). Again, you could also use
map_meta_capto add additional capability checks, specifically within the post list table, to prevent them from displaying at all.3) To clarify, so you can see the documents on the list, the document edit screen, or (download) the document itself?
Also, there are a handful of other permissions plugins out there which may be worth trying out and experimenting with, which should work with the plugin.
Per the FAQ, you’re going to want to take a look at either Edit Flow or Advanced Custom Fields.
If you could please give the development version a try, the problem should be fixed there, but there’s also a bigger change to make the fix a bit more elegant, that I’m hoping doesn’t break anything… it passed all the (unit) tests at least 🙂
https://github.com/benbalter/WP-Document-Revisions/tree/develop
zip: https://github.com/benbalter/WP-Document-Revisions/zipball/developForum: Plugins
In reply to: [WP Document Revisions] Customize Theme and WP Document Revisions ConflictAs for the theme previewer, look for a fix soon. It is duplicative of this forum post; look for updates there.
As for WordPress SEO, the upload dialog is there (may need to scroll)… Yoast’s metabox just seems to be taking priority. Will get a fix in the next version (you can drag and drop to reorder in the mean time).
Ticket for SEO (to track progress): https://github.com/benbalter/WP-Document-Revisions/issues/16
Closing this issue as resolved (duplicate) and look for a fix on the theme issue very soon.
Sorry for the trouble, and look for a fix to this very soon.
I’ve opened a ticket on GitHub if you’d like to follow the fix’s progress.
Thanks for taking the time to report and diagnose the problem.
I believe if you deactivate and reactivate the plugin, it should reschedule the refresh job?
Could I trouble you to give the development version (zip) a try? I believe the issue should be resolved.
Yes. It will need to be slightly customized to meet your needs, but take a look at the Bulk Import Script in the code cookbook.
https://github.com/benbalter/WP-Document-Revisions-Code-Cookbook/blob/master/bulk-import.php
Unfortunately, the Custom Taxonomy generator is no longer supported, in favor of dedicating more time to the core plugin functionality.
Lots of great plugins already exist that do the same job much better than the custom taxonomy generator ever could.
I would recommend taking a look at Advanced Custom Fields or Edit Flow, both great plugins that work well with Document Revisions.
Sorry for the trouble there. That should be a relatively, recent problem as I know that code was changed to make automated testing easier.
I have to test it, but I suspect that moving the
serve_filefilter fromsingle_templatetotemplate_includeshould fix the problem.Although template single would in theory be a bit more efficient, depending on the set up, I realize now it could in theory trip one of the other conditions in
wp-includes/template-loader.php.Exiting isn’t explicitly necessary, as
template-loadershould be the last file executed.I’ve opened up a bug ticket and hope to follow up with a fix.
So to confirm, you upload a file, but they don’t appear in your uploads folder?
You said you set the upload folder to
/wp-content/uploads… that should be the *PATH* to the folder, not the URL (e.g.,/var/www/wp-content/uploads/</code.).Ahh, I see. If you change
get_documentstoWP_Query, and add'post_type' => 'document'to the$argsarray, the above code should work as expected, I believe.get_documentsbehaves likeget_posts, notWP_Query(returning an array versus a query object which you can iterate through like you are above).Can you write out (in psuedo-code if need be) what you’re trying to do?
Because documents are just posts, you should be able to query it normally, such as using
wp_queryorget_posts, if need be.