@archon810
Thanks for your input and suggestion. I do definitely agree with you that being able to tweak how the settings screen is displayed according to user role would be useful.
Depending on how one uses the plugin, I can see some different variations of how you’d like users with non admin privileges see the settings page. So I was thinking of maybe adding filters to the settings page to control how you’d like to see the settings in other scenarios like a read-only mode that only displays shortcodes for instance.
In other words, by using a filter, you get the access to remodel the settings page. Would that work for you?
Cheers,
Johan
I’m not sure exactly what you mean by “by using a filter” but if you mean a setting that says show read-only list of shortcodes page to users with less than OPTION1 and greater than OPTION2 privilege, or something like that, then yes, that’s perfect.
I am also using svn trunk of this, so you can push in changes and let me test them before releasing the tagged version. What do you think?
With a filter I meant, if I put the basics into the plugin for different views depending on role, you can then for specific tweaks for a site add a filter to for instance the theme’s functions.php like this pseudo-code.
function ps_admin( $admin )
{
// Set some admin view customization options for different roles
}
add_filter( 'post_snippets_admin', 'ps_admin' );
Anyway, that put aside and looking at an initial implementation to begin with, I was wondering where did you have in mind that the list of shortcodes would show up for the user? If you login as a user with the role of Editor or Author for instance, you don’t have access to the settings part of WordPress and by that can’t see the Post Snippets option screen. So the read only view would have to be located somewhere else for users with read-only/no-settings-access capabilities. Any ideas?
Cheers,
Johan
Don’t think you need a filter at all. I think the confusion stems from you thinking users without admin privs can’t view settings, which doesn’t seem to be true.
Here’s an example of what happens when I log in as a low-priv user: http://farm8.staticflickr.com/7261/7000076879_856cea0602_z.jpg
I think you can freely add menus, and as long as the user has privs to access them, they’ll show up. Look into the respective WP API.
Does that sound good?
To clarify “Subscribe to comments” is a plugin.
Ah, yes, I did a few tests here with setting different capabilities to access the menu and you’re correct.
I’ll make an overview page for roles without manage_options capabilites but still have edit_posts capability and commit it to trunk, and you can take a look at it if you want to.
Cheers,
Johan
An initial implementation is now in the trunk.
Cheers,
Johan
Johan,
The initial implementation works. Here are some things that would be great to see in the final version:
– rather than output pure escaped html, output unescaped one, so that you can see exactly what the output looks like (with all the html processed). This is especially valuable for contributors who aren’t tech savvy and don’t want to see HTML. In fact, I’d like to see this in the admin version as well, under the edit textareas – bonus points if it’s updated live via ajax after getting parsed by the server (to resolve other shortcodes and filters, more on that below). Maybe even an ability to switch between processed and raw HTML for contributors – then they could see both if they want to.
– for the processed HTML mode, it’d be ideal to resolve other shortcodes. For example, I have a shortcode called [note] that’s part of another plugin (wp-note) – it’d be perfect to see it do_shortcode()’ed in this processed view so that it looks exactly like the final output
– there seems to be an issue with UTF8 somewhere. Here’s what I see in one of my shortcodes: “This article deals with a couple of advanced topics. If youâ��re unfamiliar with some of the terms, hit up our primers here.” What it reads in the edit mode is: “This article deals with a couple of advanced topics. If you’re unfamiliar with some of the terms, hit up our primers here:”
As you can see, the quote is special, not regular, and it’s probably double encoded by mistake or not decoded correctly. Not sure, but here’s your test case.
Rendered Output:
I’m a bit unsure of how to handle this one. For simpler snippets containing just text/html it’s no problem, but for ones depending on having variables defined, they will not render correctly when there is no variables set in this view as when entering them in a post. So for some snippets it will work fine, and for others it can look very strange or even break the page.
One could have an admin setting for snippets where it makes sense to have them display rendered, and if not checked they displays as-is. I want to avoid adding to much options to cluttering the snippets editors though, so I’d have to think about this one a bit.
UTF-8:
Fixed.
UTF-8 fix confirmed.
Think about the others. This is already a great start. Thank you.
Okay, I made a little test with the latest version in trunk. By using a global definition you can decide per site if you want the overview to have rendered snippets or displayed as code.
Default is displayed as code, to avoid any breakage of the page, but if you have snippets that your want to have them rendered instead you can add this definition somewhere. Preferably just put it at the top of your functions.php for the theme.
define( 'POST_SNIPPETS_RENDERED_OVERVIEW', true );
That could perhaps work as a solution to decide how to display them without adding extra options to the main admin screen.
I just checked in a small modification to trunk where do_shortcode() is enabled as well if you have set render output to true. So shortcodes in snippets are executed in the overview.
This seems to work! Some styling is missing because some other plugin’s css is missing, but that’s up to the plugin author to fix (oh wait, I rewrote that plugin from scratch, so I can fix it too :-]).
I’d still like to give the option to the contributor, so that they can flip between raw html and processed – if at least to see if there are any other shortcodes embedded within any given post snippet. Could be a simple 2-part radio button that defaults to raw html.
Btw, is displaying as text instead of a single space. This is unrelated to this ticket, but I’m going to tack it on.
Using POST_SNIPPETS_RENDERED_OVERVIEW variable isn’t set in stone. Perhaps it should be a per user setting instead. I can store it in the user meta data. So each user have a toggle as you suggested. I’ll give it a go.
I believe the character displaying as text instead of a space got displayed as space here :), which character is the problematic one?
