markItUp! pack 1.1.5 - set switching

They're now at 1.1.4.

Here's a patch that got this working for me with markItUp! 1.1.4 and the bbcode set. Note that I didn't include the markitup files themselves because we should not be distributing these at all from drupal.org, and having users download them from the source instead. See http://lists.drupal.org/pipermail/development/2006-May/016589.html.

Summary of changes:
* For some reason, I had to add the skin/set CSS at a "theme" weight rather than "module" to get it to work. I also removed the other parameters being passed into those drupal_add_css() calls because they are the defaults.
* skin-skin-style.css and set-set-style.css have been renamed to just style.css and set.css.
* In 1.1.4, it appears they've gotten rid of the name-spacing of the settings in set.js, since they're all just var mySettings.

webchick: markItup is dual-licensed under the GPL and MIT, so it should be just as kosher to host it on D.o as jQuery itself, right? Or if you were referring to the last paragraph, I wouldn't consider mIU a library; more of a final product.

It's kosher from a distribution standpoint, but not from a Drupal.org CVS policy standpoint.

From http://cvs.drupal.org/viewvc.py/drupal/contributions/README.txt?revision...

In cases where another non-Drupal project is required DO NOT include that code
in the repository. Instead provide a link where the other code can be
downloaded and instructions on how to install it.

Since jquery.js is /part/ of the Drupal project, it's exempt from this rule.

Hm, bummer. Okay, I'll remove it from the next release.

Hopefully future releases of mIU won't be continually breaking the module, though…

(patch accepted, btw)

* In 1.1.4, it appears they've gotten rid of the name-spacing of the settings in set.js, since they're all just var mySettings.

Hmm. Given this, I'm not sure how switching between sets on-the-fly or having multiple textareas using different sets is supposed to work anymore. Why did the mIU crew do this?

Even the live switching example on the mIU site seems to be using an older version of mIU, or at least older versions of set files where each set had its own variable name.

The only ways I can think of to get around this all involve ugliness. Hmm, I'll call it a night; maybe I'll be more clever tomorrow.

thanks for all the hard work, perhaps you can post on their forums regarding your concern

There are forums for mIU? Where? They're not in any obvious place on the site, and a quick search didn't turn them up either.

Okay, I've found a hacky-but-not-too-hacky way to recreate on-the-fly set changing. However, only one "set" can be loaded and active at a time, so all textareas on a page will have to have the same button bar regardless of their input filter.

A workaround for this would be to examine what (if any) input filter a particular textarea is using when it gains focus, then load the corresponding set, so that way at least whatever textarea the user is currently using will have the correct button bar. Oh, God, that sucks.

Screw it. CCK doesn't build its textareas in a similar way to the standard node/block ones, so I'm not going to be able to alter it in a reasonable way to get it to do what I want it to do. And since there's few other reasonable cases in which there will be multiple textareas on a single page which one would want to enter formatted text into, I'm just gonna say screw it and scale back the scope of this thing so that it only works on comment and body fields - where the format radio buttons are always there and easy to find. The rate of return in proportion to the amount of effort it'll take to get it to work otherwise just isn't worth it at this point.

Well, before you say screw it, take a look at how a project like http://drupal.org/project/wysiwyg is dealing with this problem.

Edit: Btw, thanks so much for picking up this module! It has so much awesome potential. :)

Working with the WYSIWYG project is on the horizon, but I was hoping to get out at least one slick, refactored "plain" release of the module before I started looking in that direction. And I will soon. If nothing else, it's familarizing (or whatever the verb is) me with the inner workings of mIU when I've only ever really known it from a user perspective before I opened my big yap and volunteered to work on this project.

EDIT: By the way, I'm noticing that the current dev release still has a few remnant markItUp! JavaScript files in the archive. Oh, CVS, you old card. You've done it to me again.

Oh. I meant specifically how they deal with "attaching the wysiwyg editor to all input formatted textareas" problem, not so much solving the larger issue of how to integrate markItUp into WYSIWYG API. I already worked with sun on the latter problem and basic support was committed as a result of #352295: Add markItUp support. Unfortunately, it'll be a long while until WYSIWIYG API supports constructs such as swappable sets and skins (see #313497: Allow to configure advanced editor settings), so this module still is very useful to people.

And yes, CVS is a cruel, fickle mistress. :(

Ah, okay. I'll take a look at that later, but for now I'm just going to set that aside and get things working 100% just on body and comment fields first, before I run out of momentum from running into all of these walls. Know what I mean?

Yaaay! After taking a day off yesterday to play Cartoon Network FusionFall , I pulled a double-shift today and got things done. There's a graphical glitch in Webkit and I haven't tried it in IE yet, but things are 100% in Firefox. I was going to do another CVS release, but… it's almost 10:30 and I'd rather start going in the direction of bed than fighting with CVS right now.

I ended up pretty much just rebuilding the module from scratch; sorry, Mr Samuelson, but I redid the admin screen, and then I redid the JavaScript bridge code, and before I knew it I had redone everything. What I'll probably end up doing (if CVS will let me) is labeling this as a 2.0 version, so that if there's bugs (and there will be) you can still go back to Samuelson's earlier version.

I am testing this and current there is no way to choose which text area to show the editor on. I want to use the editor for the privatemsg pages too.

As mentioned, I had a bear of a time trying to predictably find arbitrary textareas to apply markItUp! to, so in the end I just went for the 90% solution of only doing node, comment and block textareas. I'd like to restore the ability to apply it to arbitrary text fields in the future, but for now it's kind of back-burner.