CUNY Academic Commons

I like it. Formatting on the left and editing on the right. I'm looking forward to Chris' thoughts.

Added myself and Chris as watchers.

• This ticket should be merged with http://redmine.gc.cuny.edu/issues/1662, they're the same.
• Dominic, when you add a ticket that you think might be related to me in any way don't hesitate to add me as a watcher. I don't just look through redmine so if I'm not on a ticket I don't usually see it.

On to the toolbar, generally I think we're all on the same track. Matt, yours especially is close to what I had. I think the main idea is to group the like functions together.

Both of you removed the show/hide kitchen sink button. I think that's fine.

You added in superscript, subscript, cut and paste. I also think those are good. I have to admit I haven't had time to look at all the options so I can't comment on other possibilities

I do want to push back against the font-family and font-size additions. It could just be the web developer in me but I have two concerns with that. One is that those are really supposed to be the job of the theme. Presumably the theme designer spent a good deal of time figuring out what size and font to make the paragraphs, headings etc. This is opening the designs up to the possibility of people adding in some really ugly font combinations and awkward large or small sizes. Two, is that the only way to change those things is to add in really ugly inline styles that bloat the HTML. Modern web design is based on the separation of content into HTML and styling into CSS, preferably in a separate stylesheet, and this would break that (allowing the color also breaks this but I'm willing to give that smaller concession). If people aren't clamoring to do those things then I don't think we should let them.

Here is a link to my version: http://www.teachingmultimedia.com/commons/tinyMCE/
The extra line at the top is what they see in HTML mode. I only did minor reordering and didn't put a lot of thought into it.
The top line is mostly formatting with the last icon, one I didn't understand by looking at it, the Remove Formatting
The second line adds lists and links and other general stuff.

Looking at it again you could probably make the argument the blockquote should be down by the lists and indent as it is similar to them.

I want to push back on adding in

Also: your demo rocks. Thanks for putting it together with such care!

I do think your message above got cut off, though (Redmine word limit?)

When you click the help button a modal window pops up over the page with some instructions on editing. I don't know if we have any control over what is there.

I don't know if anyone uses the RSS button inside of posts. I suppose some might use it on a page where they want to show feeds. I'm OK either way. I'm also ambivalent about the cut button. It goes fine with all of the pastes but not sure if people actually will use it much.

Matt, when does that admin bar show up? And does it depend on the browser? I'm not seeing those links right now.

I think I cut myself off in the last post. I moved some text around and left a straggler.

Including them at all or not a good question. There are too many services out there to include all of them but it makes sense to make it easy to embed media from some of the most popular ones. Which ones is still a question.

I guess if I had my way those would be options in the new Upload/Insert link but I don't think that's possible (or at least not without a lot of code).

Maybe we can make the reordering changes to tinyMCE and then do a new ticket to hash out what media embeds we want to do?

I also agree with Chris on the formatting. I only included them because I was trying to replicate the Word formatting bar as closely as possible for a starting reference point. The help, RSS and Remove Formatting buttons can probably go as well. I've never used them and don't know anyone who has. I'm ambivalent about the cut button too, we're attempting to help users who probably don't fully understand cut/copy/paste anyways. :-)

I'm not familiar with that toolbar of media insert buttons either. If you tell me what plugin provides that functionality I'll try and replicate it on my end to see if my code interferes with them.

I haven't done anything with the formatting of the html editor toolbar buttons. I don't think we should do anything to the toolbar used by someone advanced enough to change to html editor mode. Will probably cause more confusion than benefit.

I may be wrong (if so, Boone can correct), but I think that the media buttons are provided by the Viper's Media Quicktags plugin, which (I think) is activated on a sitewide basis (ie., in mu-plugins). Boone, can you confirm?

Yes, I think the buttons are from Viper. No, I don't think it's activated sitewide.

More generally, any plugin has the power to add items to the TinyMCE toolbar. So it'll be futile to spend too much time trying to control where/whether to place all of the added buttons. My advice is to turn off all plugins, make your best configuration based on WP's default buttons, and be satisfied with that.

On a related note, I do not think that we should be removing any buttons that are being added by plugins (though it would be possible to do so using Dom's method). We aren't really in a position to know whether anyone is using this buttons, and in any case it has the potential to confuse users when buttons intended to be there by a plugin (and possibly mentioned in documentation) are not there.

Thanks for the clarifications on the video buttons. I also agree that it is best to make our configuration on the default buttons and then to allow individual blog users to modify those with plugins as they see fit.

I'll be integrating all these ideas into my code tonight, will post an updated screenshot for review once the changes have been made.

Sounds good Dominic.

About the videos, do you think we should have a link or any kind of help that explains to people if they have a YouTube or Vimeo video they can just paste in the URL in Visual Mode? Scott has a nice post on this http://codex.commons.gc.cuny.edu/2012/02/05/embedding-video-using-wordpress-3-3/

but I'm not sure if many of our users are aware that it can be just that simple. Perhaps when we do the writeup on this change we can add something about that.

An explanation of how to get embedded content into the editor definitely belongs in the documentation (codex). I am unsure if we can add anything to the editor to help with this. I will investigate while adjusting my current custom button code. Maybe I can get into that help button and customize the content that gets displayed in the modal window. However, I don't think many people click help buttons, so I don't know how beneficial it would end up being. In my experience, if a user doesn't know what a button does, then they never click on it. And I also believe, personally, that when a user comes from a windows background (as most users do) they tend not to use "help" functionality since the help functionality in windows really isn't all that helpful. To be fair Apple's "help" isn't that much better. :-)

Getting the average Commons user to become more familiar with WordPress/BuddyPress/Commons functionality is probably the job of an outreach program. I believe getting users to the proper documentation is a UX issue. I'm just not sure where/how to get that help into the admin UX. I'll be investigating the new WordPress Screen API (which provides a new way to create content under the admin section's help tab) for a future article. Although, getting helpful information into that section of the admin will suffer from the same failing of a user not clicking the help tab! LOL

Chicken and egg my friends, chicken and egg...

I think that looks really great, Dom! Nice job!

Question: will your alterations to Viper be undone when/if we update that plugin?

I didn't do anything to viper. I changed how I was customizing the buttons because my technique was preventing viper from displaying its buttons (and I assume any other plugin that creates custom buttons in the same way). I altered my code to work with viper, not the other way around.

If you're talking about viper being displayed on the second row I don't think an update to the plugin would alter that setting. However, the attached screenshot shows viper on my local environment. You will not see viper on the second row in the live site's TinyMCE, I only changed that setting on my machine to make sure the code I added to show the kitchen sink by default didn't break viper's ability to be moved to different toolbars. Viper has its own admin settings page on which one of the options allows you to display it on rows 1-4.

Got it. Thanks, Dom!

Excellent, thanks for your work on this. I think it will really help people out, especially those new to the Commons and WP in general.

@boone, I've pushed my code up to master. Let me know if you have any problems with the code on your end before I close this issue.

(For reference, here's Dom's changeset: https://github.com/castiron/cac/commit/b4f4c2113568816b6d887add00c6101674307263)

Sorry, I keep forgetting to paste the GitHub commit URLs in these updates. :-(

The functions in my code don't accept the $buttons argument because I'm not "updating" or "adding" or even "removing" buttons. My two functions attach to the mce_buttons and mce_buttons_2 filters and just return an array of our custom button layout (I'm basically completely overriding and replacing all buttons by returning a new array of buttons). The information I found while researching this issue states that all plugins should work with these filters when altering the layout of TinMCE's toolbar. For example:

This page: http://codex.wordpress.org/TinyMCE_Custom_Buttons

Says to use:

array_unshift($buttons, 'styleselect');

when customizing buttons. As long as plugin developers adhere to that advice there shouldn't be any problems with my code. Of course there's no way to be sure that plugin authors are following that specific "best practice."

If I understand correctly, because bp-custom.php is executed before a plugin has a chance to get its hands on TinyMCE's toolbar, our buttons will already be customized by the time their code is executed. If they're using array_unshift() (or something similar) to add custom buttons then there should be no conflict with the CAC custom buttons.

Please correct me if you think (or know) that I'm wrong on this point.

I'll take a look at BuddyPress Docs to see how (and more importantly when) you're accessing the buttons.

As long as plugin developers adhere to that advice

because bp-custom.php is executed before a plugin has a chance to get its hands on TinyMCE's toolbar

Sorta. bp-custom.php is loaded from BuddyPress, but strictly speaking it's just a plugin like any other. It's loaded after mu-plugins, but before most other stuff. In any case, file load order is only a secondary determinant of priority for plugins. The first is your filter priority (the third parameter of add_action() or add_filter()). In other words, something hooked like this

add_filter( 'mce_buttons', 'foo', 5 );

will load before

add_filter( 'mce_buttons', 'bar' );

regardless of when the file is loaded (file load order can sometimes break ties).

So an adequate solution is probably just to hook with priority 1. It'd be marginally safer to do some robust checking at the time of reordering, but it's probably overkill.

Let me know how the experiments go. I'll take a look myself in the upcoming days. Thanks for you work on this.

Fantastic work, Dom!

Thank you sir. :-)