Peter
Forum Replies Created
-
Good question(s).
I haven’t used Revisionary, but I don’t think that would be causing the issue.
If your user cannot edit a custom taxonomy, does that mean that they wouldn’t be able to specify ANY value? Then for initial versions your taxonomy-based rule wouldn’t be able to apply, unless you can set a default value. I do remember looking into alternatives to checking $_POST[‘tax_input’] (I don’t like having to check that POST variable directly) for the first version of a post, and couldn’t find any, because capturing the post transition happened too early in the workflow. Any tips are welcome!
As for subsequent revisions on a post, I could envision having a fallback check to see what the existing taxonomy values are for edits to existing content (when there is no $_POST[‘tax_input’] value) — something to add for a future version!
Hi,
It is in the tax_input (which looks at the taxonomy rules) and post_category sections where moderators are added to the $post_type_moderators variable. The section of code above that, which builds $post_type_moderator_rules, is only supposed to “re-format” the rules for the tax_input and post_category sections to check against. The reason why I don’t wholesale add to $post_type_moderators in the section that you are referring to is so that I can match against a category or other taxonomy rules; otherwise ALL rules for a particular post type will apply in all cases. That is why your code addition works as you intend it to, but that means that if other terms are selected, they would also match against the “Meta” rule (which they shouldn’t). In other words, if you have two rules such as this:
Post type: Page
Taxonomy: Section
Term: MetaPost type: Page
Taxonomy: Section
Term: Sidebar… the pce_get_post_type_moderators() function looks up ALL rules for the “Page” post type, and then only applies those rules to those pages that match on the “Meta” Section and/or the “Sidebar” Section. If you are not getting the expected list of moderators, then either the rule didn’t actually match the submitted page or the code that is trying to make the match (the tax_input and post_category sections) is flawed (which I’m still trying to reproduce).
Version 2.6.0 of the plugin now supports [variable]http_referer[/variable] as a redirect URL in order to redirect the user back to the same page. Please see the note in the changelog (http://wordpress.org/extend/plugins/peters-login-redirect/changelog/) or implement one of the other suggested solutions if you need to support more than the basic use case.
If $post_type_moderators isn’t being filled without your suggested edit, that means that it’s not matching on the term “Meta” for some reason. Unless you’ve somehow forgotten to check the “Meta” term in the “Section” taxonomy or you’re using a completely separate editorial interface, it should be matching based on the values in $_POST[‘tax_input’] variable. If that’s not the case, unfortunately I’m stumped on this one 🙁
Sorry about that and thanks for clarifying. I think I was reading 1.6.2 as line 162 instead of line 415 as you said.
Unfortunately I still can’t reproduce the problem, but that doesn’t mean the problem doesn’t exist. What does your rule look like after you’ve added it? Is it something like this?
Post type: section
Taxonomy: all
Term: *** n/a ***In pce_get_post_type_moderators(), $post_type_rule isn’t intended to directly add to $post_type_moderators because it might not apply (if it’s supposed to match on a specific tag, for example). At the end of the function, the “all” rule is added, but based on the assumption that the term for the “all” rule is an empty string. That might not actually be the case in all database setups and I suspect that to be the case if your rule is as outlined above. To help troubleshoot, could you please paste a var_dump or export of $post_type_moderator_rules just before the end of pce_get_post_type_moderators()?
Update: version 1.7.0 of the plugin now sends an e-mail at the “private-to-published” post transition.
Hi, that shouldn’t be the case, because lines 163-169 are what add the moderators to the list. What is the exact case you are trying to capture? Is it a post being submitted for review? What taxonomy rule are you testing (category, tag, post type, other)?
Forum: Plugins
In reply to: [Peter's Post Notes] [Plugin: Peter's Post Notes] Unable to Export notesHi,
This is the expected behavior — there is not any current logic to hook the notes into any post import or export. What import/export process are you using? You could write an extension to that process or a separate process to also take the notes along.
Hi, you could actually use built-in WordPress functionality to achieve this by making the Events page link to the login page via a URL such as:
http://yoursite.com/wp-login.php?redirect_to=http://yoursite.com/eventspageIn short, you can use a “redirect_to” GET variable to specify an exact redirect URL.
There are many other ways to approach this, as outlined here:
The plugin captures the “pending-to-future” transition, but you could use similar logic to capture the transition to “future” post status from any post status. You can check out the pce_pending() function in the plugin for examples.
Do the posts go directly to published? This plugin only captures post status transitions, so you’d have to write a slightly different workflow to capture the case where posts go directly to published by certain user groups. Or, perhaps the theme is publishing posts by a non-standard method?
Yes, near the top of the plugin file you’ll see a $pce_emails_to_send settings array where you can turn on / off certain e-mails.
The plugin currently captures the “pending-to-future”, “future-to-publish”, and “pending-to-publish” post transitions, but you could also extend it to go “private-to-publish” using the same logic as you see in the pce_pending() function in the plugin.
Forum: Plugins
In reply to: [Peter's Post Notes] [Plugin: Peter's Post Notes] Any chance on a update?I’ve tested it on a fresh 3.4.1 install and the appropriate windows show up on the dashboard and on post/page edit screens. Are you using any plugins that override any of these interfaces?
Looks like this would definitely be possible, on a couple of hooks:
Trashing a post: you can hook in to the same post status hook as the collaboration e-mails plugin, but with the new status of “trash”
Deleting a post (bypassing trash or moving from trash to delete): You cannot use the post status hook, but there is a special hook “before_delete_post”
Adding a reason for deletion would be more difficult, however, since there are multiple ways to delete a post (not just from the post screen) and even on the post screen, the “Move to trash” action is triggered via a link, not a form button.