thanks a lot

CommentFileSizeAuthor
#2 markitup-1.1.4-update-304772-2.patch2.57 KBwebchick
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

webchick’s picture

Title: update to markItUp! pack 1.1.2 » update to markItUp! pack 1.1.4

They're now at 1.1.4.

webchick’s picture

Status: Active » Needs review
FileSize
2.57 KB

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.

Garrett Albright’s picture

Title: update to markItUp! pack 1.1.4 » update to markItUp! pack 1.1.5

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.

webchick’s picture

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.

Garrett Albright’s picture

Status: Needs review » Fixed

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)

Garrett Albright’s picture

Title: update to markItUp! pack 1.1.5 » markItUp! pack 1.1.5 - set switching
Status: Fixed » Active

* 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.

chasz’s picture

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

Garrett Albright’s picture

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.

Garrett Albright’s picture

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.

Garrett Albright’s picture

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.

webchick’s picture

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. :)

Garrett Albright’s picture

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.

webchick’s picture

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 configuration of advanced editor settings), so this module still is very useful to people.

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

Garrett Albright’s picture

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?

Garrett Albright’s picture

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.

NaheemSays’s picture

Version: 6.x-1.x-dev » 6.x-2.x-dev

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.

Garrett Albright’s picture

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.