Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
I am currently unable to add any buttons in markItUp. I tried editing what was in the /sets/default/ folder and it seems to have no effect. How does wywiwyg know how to build out the buttons toolbar?
Comment | File | Size | Author |
---|---|---|---|
#24 | 577258-d7-1.patch | 5.49 KB | redndahead |
#21 | markitup.buttons.21.patch | 3.15 KB | sun |
#16 | markitup.inc_.patch | 3.01 KB | MaffooClock |
#15 | markitup.inc_.patch | 3.42 KB | MaffooClock |
Comments
Comment #1
livingegg CreditAttribution: livingegg commentedI dug into markitup.inc and it seems like the buttons are hard-coded.
Would a better solution be to parse the "mySettings" object from /sets/default/set.js into the $default_buttons array in markitup.inc?
I could take a crack at a patch if that sounds like a good route to take.
Comment #2
TwoDYes the button/plugin configurations are hardcoded into the editor implementations.
You can also add additional buttons by implementing the plugin hook provided by Wysiwyg module. That way you can describe two types of plugins for use in the editors. The first is a plugin which is native to the editor (ie, written as you'd write the plugin when not using the editor via Wysiwyg module). The second is a "Drupal plugin", which is a kind of meta-plugin which relies on a proxy implementation of a native plugin in the editor implementation. Basically a way to communicate with and extend all editors through a common API.
If you wish to use an existing plugin for an editor, you use the hook to tell Wysiwyg module to load it as such, and where to find it. If you wish to create a new plugin which could also be used by other editors, without the need to adapt your code for each one, you should tell Wysiwyg module it's a Drupal plugin via a proxy and load it as such. (Note that the 'API' for writing Drupal plugins and interacting with Wysiwyg module is a bit sketchy in 2.x but will be much improved in 3.x.) More documentation was committed a while ago and can be found in the -dev snapshot.
There are some scattered discussions about plugin detection in #320562: Libraries API and #328252: Handle compatibility of internal plugins via plugin API.
In short, we'd like to reuse the code in Libraries API to detect the available plugins for each editor and treat them as individual "libraries".
Comment #3
livingegg CreditAttribution: livingegg commentedThanks for taking the time to give this great explanation, although I admit that I am a bit lost. Not being a drupal module devloper myself I have only a fragmented understanding of what you're talking about and of the implications in those threads you mentioned.
The "default" implementation of markItUp is very, very basic, and is meant only as a starting point. The markItUp editor by nature is a little different than other editors as one of the main objectives is to allow people to build out their own custom buttons based on their needs, using the simple javascript implementation they created - which also include the ability to define shortcut keys which are essential to markitup. Is this still possible with what you're suggesting? It seems to me that if you ignore the javascript set files and instead ask people to do this themselves in php (via the plugin hook?) then doesn't it pretty much destroy the markitup editor model? You will be asking people to basically implement every button themselves using drupal specific php and nobody but a module developer is going to know how to do this. Please correct me if I am misunderstanding you with this, but I still think that in the case of markitup it is important to be able to parse their sets javascript objects, or at least provide an example of how people could do something similar through the library api - otherwise in the case of markitup it seems like wysiwyg acts more like a drupal developer's api than as an abstraction layer / module to an external editor.
Comment #4
TwoDI'm not surprised you are a bit lost, it's much to take in and many things to consider so I think we all are a bit lost now and then. I'll gladly explain what we're trying to do and why if it helps people understand. I know I will repeat myself a bit but I'm just trying to keep things in an order which [I imagine] makes sense.
Yes. In a sense, Wysiwyg module on its own is a basic editor implementation with an API. (Hence why the module used to be called Wywsiwyg API.) For the site-builder it's an easy way to get your favorite editors up and running in Drupal. For the developer it's a standardised way to extend the editors either in an abstract fashion using Drupal plugins, or by telling the editor where to look for and how to load native plugins.
From a pure user POV this is not very interesting if they don't get the functionality they need. A side-effect of Wysiwyg module implementing the whole editor configuration and init process is it getting locked down. If left so, you couldn't [easily, or without modifying files] change what Wysiwyg module tells the editor to behave like. For editors like markItUp this is obviously disastrous. That's what Wysiwyg module's plugin hook and eventually the GUI from #313497: Allow configuration of advanced editor settings is and will be there to remedy.
The markItUp sets are usually available as a simple .js file, maybe accompanied by a .css file and some images. Normally you'd just drop the set related files in some folder, change your document to include the script/css files and pass the resulting object to the editor initialization. Regular users, or in the worst case the site-builder/maintainer could do this. But when markItUp is loaded via Wysiwyg module, Drupal is in control of the document and Wysiwyg is in control of the configuration. So you have to use PHP to hook into the system to include the files in Drupal and tell Wysiwyg module they're there for use, or the editor will not know of the new functionality.
One could, as you mentioned, write a small Drupal module for each and every set you'd like to use with your editor. Once you've learned how to do it, it'd pretty much be a copy/paste job with some name and path changes. Soon you'd have lots of modules with no purpose other than adding sets to the editor. That's way too much overhead.
Installing sets is a pretty repetitive task, right? So why couldn't there be a single Drupal module to load all the sets? A single module implementing the plugin hook can expose as many plugins/sets as it likes (or finds in a folder). It could both include the script/css files as well as override the editor configuration to actually use the sets, all on its own. Any new set would then just need to be placed in a folder, say
/sites/all/libraries/markitup_sets
and it would automagically be detected by the Drupal module and passed on via Wysiwyg to the editor. Some more complicated plugins will of course need some extra treatment before Drupal is able to chew them and get them all the way through to the editor. A module like that could even expose a GUI for managing the sets if the editor profile settings GUI is insufficient.That is where I'm hoping this plugin integration thing will end up some day. The user should just need to upload a library with new functionality to the site, and it's there for use in Drupal.
Why is this not in Wysiwyg module already? Well, the most important part is there, being the plugin hook. Like I said, any module could implement this functionality in parallel with the work on Wysiwyg module. We, as in the Wysiwyg module developers, don't have the resources to do all this fast enough. If we can keep the foundation solid enough, anyone can build on it.
Comment #5
livingegg CreditAttribution: livingegg commentedThat does clear up some of my confusion - thank you. You and sun are really taking on a great vision with this project, much credit to the both of you for all your hard work. If you pull it off I suspect this will be the first and only project of this nature and magnitude to happen in the open source cms community - really good stuff.
So in the meantime I'm still looking for a quick and dirty way to get sets into markitup - a stopgap solution until the 3.0 branch is more mature, and I'd rather not resort to hacking the markitup inc file. If I'm interpreting everything correctly it looks like #30 from the [#313497: Allow to configure advanced editor settings] post would be the best option for now - does that sound right to you?
Comment #6
TwoDYes, you should be able to override most things that way. The only problem (as noted in that issue) is passing object/function references via drupal_add_js(), which is simply not possible as they can't be serialised in a good way. Unless your button requires that it should not be so hard.
Comment #8
sahaj CreditAttribution: sahaj commentedHi,
I'm getting really lost in the process to try simply to add unordered list button in markItUp. Is it an easy way to do it?
Comment #9
sahaj CreditAttribution: sahaj commentedComment #10
Z2222 CreditAttribution: Z2222 commentedA suggestion for markItUp: why not have the module automatically download the full HTML set of buttons instead of just the default ones?
The full HTML set is here:
http://markitup.jaysalvat.com/downloads/
markItUp is the best WYSIWYG editor for Drupal in many situations because it doesn't allow users to paste weird formatting into posts. It would be great if the module automatically fully enabled the main HTML button set.
Comment #11
elBradford CreditAttribution: elBradford commentedI'm not sure if this is the correct issue, however it seems the WYSIWYG button API is not implemented at all for markitup. This is required for the WYSIWYG Image Upload plugin to work. Any chance of implementing that?
Comment #12
amrit_b CreditAttribution: amrit_b commentedComment #13
amrit_b CreditAttribution: amrit_b commentedComment #14
Brodingo CreditAttribution: Brodingo commentedsubbing and completely agree with #10
Comment #15
MaffooClock CreditAttribution: MaffooClock commentedIs this topic dead? Well, I've run into this again, so I've added the buttons from the Basic HTML Set and created a patch to enable them. I'm not real deep into the development of the WYSIWYG module, so I don't expect this patch to make it into the repo -- I just wanted to share it in case anyone else want a simple way to get all the buttons from the aforementioned pack.
Aside from applying the patch, you'll need to download the "Basic HTML Set" and extract it into
sites/all/libraries/markitup/markitup/sets
, and when unzipped, should provide a second folder labeled "html". Rename "default" to "old" (or delete it if that's how you roll), then rename "html" to "default".You will then need to visit
admin/config/content/wysiwyg
to re-configure each profile by enabling the new buttons you want.NOTE: use patch from comment 16.
Comment #16
MaffooClock CreditAttribution: MaffooClock commentedUploaded wrong patchfile in comment 15.
Comment #17
hunterish CreditAttribution: hunterish commentedUsed MafooClock's patch from comment 16, and it works like a charm.
Comment #18
goldhat CreditAttribution: goldhat commentedPerhaps WYSIWYG API should provide a hook_settings(&$settings) that can be called from a custom module which would function similar to hook_menu in that we can define an array of new buttons that will be parsed.
Comment #19
TwoDWe already have
hook_wysiwyg_editor_settings_alter(&$settings, &context)
which can be used for that now.See wysiwyg.api.php and the issue queue examples for more info.
The downside is that since the settings are transported to the client using JSON, we can't add stuff like JavaScript Functions, RegularExpressions, or references to them. Hence, you might additionally have to set some other values which you know can be "translated" to such JS types in the hook, override a method or two in editors/js/markitup.js, like Drupal.wysiwyg.editor.attach.markitup, and make them do the actual transformation to the datatypes you need the settings to be in before the editor is attached.
This is made extra complex by markItUp assuming there can't be two markup sets used on the same page. Each markup set, as downloaded from their site, will by default [re]define the same global variable.
Comment #20
populist CreditAttribution: populist commentedI am a big fan of Markitup! and added buttons to Panopoly WYSIWYG through the method described in #19 (http://drupalcode.org/project/panopoly_wysiwyg.git/commitdiff/7256bbe). It was easy enough to implement, but it loses certain configurability in the GUI which seems desirable. +1 from me for adding the HTML button set since it provides a few important/general buttons (h1, h2, h3, h4, ul, ol) that are important for a lot of content editors.
Comment #21
sunRe-roll of #16 without tabs and with proper formatting.
The changes to wysiwyg_markitup_settings() do not really look correct to me. As @TwoD pointed out, we have a new callback for editors, which allows each editor to customize/enhance the settings form, if required. (I'm not sure whether that's the correct approach here, but it could be.)
Comment #22
Dries ArnoldsIs there any objection in making MarkItUp a little more useful and adding this patch to the current versions?
Comment #23
Anybody+1 for adding markitup sopport for additional "sets" by UI. It would be nice if someone can do it.
Comment #24
redndahead CreditAttribution: redndahead commentedThis patch adds the ability for plugins to do actions on the buttons. As it sat before you couldn't really add an outside plugin and use the markitup actions. Unfortunately I couldn't create a diff that didn't look like I threw away all the code so I'll explain what the patch does here.
1) I moved the default buttons definition to it's own helper function. There was no need to declare them twice, once in the settings and once in the plugins.
2)
This pulls the plugin info. Plugins will need to add some markitup settings so it can work with markitup.
3)
This grabs the settings from the plugin for markitup if it isn't one of the buttons we provide.
4)
This sets a new setting called iconPath if it doesn't already exist in the settings. This is the path to the icon for the plugin. If it isn't set it falls back to the library icons.
5)
Now we use this new iconPath in the js. As an awesome side affect you can now change the icons by doing a hook_wysiwyg_editor_settings_alter and changing the icon paths that were set.
Comment #25
redndahead CreditAttribution: redndahead commentedIgnore the patch I had above. The patch that I have posted here: https://www.drupal.org/node/397994#comment-8929741 adds some things that make it easier for plugins to support markitup. You can see an example module here: https://www.drupal.org/sandbox/redndahead/2294249