Ben Balter
Forum Replies Created
-
Forum: Plugins
In reply to: [WP Document Revisions] WP Document Revisions & Edit FlowDid you toggle on the document post type from the list of post types on the settings page for Edit Flow’s custom statuses module?
Also, latest version of both plugins + WordPress?
I believe I have a working version of an add-on plugin that should do exactly what you’re looking for. The file is here ( https://github.com/benbalter/WP-Document-Revisions-Code-Cookbook/blob/master/taxonomy-permissions.php ) and would be installed like any other plugin.
A bit more information is listed on the last question of the FAQ ( https://github.com/benbalter/WP-Document-Revisions/wiki/Frequently-Asked-Questions ), but in short, out of the box it will make a “departments” taxonomy, and will create capabilities based on any departments added. You would then install and activate Members, if you have not already, and use the interface members provides to add roles and assign capabilities.
You can tell the plugin to create and use any different taxonomy (e.g., “company” instead of “departments”), as described within the file.
It may not be 100% stable as it hasn’t been tested in the wild yet, but it should work. Please let me know if it works for you, or if you’d prefer to have me set it up, etc.
You should be able to override the default of 5 by passing the additional argument
numberposts="10"e.g.,[documents monthnum="4" numberposts="10"].(hint: -1 would be all).Please see this duplicate thread. Looking forward to resolving the issue quickly with your help.
A few things here. When you say searching by FTP, what do you mean? The file should be renamed on upload to a random hash, so you may not be able to detect the filename, but should be (by default) in
wp-content/uploads/YYYY/MM/.Same size but corrupted is a good thing. It means it’s finding the file, something else is just getting in the way of serving it. Does the problem happen consistently across file types or only PPTs (testing, and have no troubling downloading PPTs)?
Last, latest version of plugin and latest version of WordPress? What other plugins are activated? Any strange caching, etc. that may be causing it.
If the site’s public, if you could either post or send me a link to a troubled file, it would be helpful to be able to look at the headers being served.
You’re not the first to describe a similar issue, and it would be good to get to the bottom of this if possible.
Forum: Plugins
In reply to: [WP Document Revisions] [Plugin: WP Document Revisions] Document expirationNo, it does not, but a plugin could be written to do this.
I’m actually thinking about releasing an add on which would provide this functionality out of the box. Is this something you would be interested in? If so, would you consider making a small donation to support its development?
Sure. And valid question. My Sorry for the ambiguity.
In order to better integrate with the look-and-feel of sites, the plugin passes an argument on the embed code to remove the standard border and the “description” text at the top of the story (usually grey/italic below the title).
Realizing that the description was being stripped, starting with 1.0.4, on save, the plugin grabs the description, and sticks it in the post as normal in-post text directly above the story. Put another way, 1.0.4+ pulls the description out of the story and inserts it into the post.
Problem being then, from a UX standpoint, what happens if I had a story in a post previously, noticed the problem, and manually corrected it. I wouldn’t want the plugin to now start double adding the description. So to err on the side of caution, it loops through prior posts, and if they have a story in them, sticks on a meta flag to indicate not to add the description.
The actual loop itself, in hindsight, does not scale well, and could have been done a lot smarter (e.g., just running an SQL query directly for
post_content LIKE %storify.com%).Incrementing the DB version flag should prevent the loop from running, and assuming you don’t have 20,000 Storify posts, you should be fine. Even if so, the description would only be inserted on save.
Hope that clears things up?
The smarter way to prevent the error would be to manually bump the
storify_versionvalue in the database, to ,1.0.5, which would bypass the upgrade procedure on subsequent updates.Normally, storify pulls the description out of the story and places it into the body of the post, and stores a post_meta to indicate it has done so (so it doesn’t do it on subsequent saves). The upgrade procedure marks existing posts with storify urls in them as already having the description added, preventing the plugin from breaking existing posts.
May make more sense to search specifically for those posts, or to move it to a sub-loop which wouldn’t hit the memory limit like that.
If you could please give the development version (zip), I believe it should fix your problem.
here’s a zip of the patched version. Let me know if this works for you? (If you could test on multiple browsers, if possible, would be greatly appreciated!)
https://github.com/benbalter/WP-Document-Revisions/zipball/inline-patch
So I’m going to want to test this a bit more before I look into making the change in the core plugin, but it’s actually a really simple fix:
If you’re comfortable, on line 725 of the main plugin file, simply change the word “attachment” to “inline” and you should be all set.
https://github.com/benbalter/WP-Document-Revisions/blob/master/wp-document-revisions.php#L725
Also, I assume this is IE / Windows?
Let me look into that. It looks like it should just be a matter of passing a setting to the browser when the file is served in most cases, but obviously has a lot to do with the user’s browser/settings.
I opened up an “issue” over on github if you want to track the progress and hope to have an answer soon.
Make sense. Concern was more with the link breaking. Either way, the latest version resolves the issue. Thanks for the quick turn around, and for your time in contributing a great plugin.