What is the difference between using the WYSIWYG module pointing to the CKEditor library and using the dedicated CKEditor module.
We currently use the WYSIWYG module with TinyMCE.
The answer seems to be that with the Wysiwyg module, you get an interface for which buttons appear in the profiles, whereas with just CKEditor, you don't? Or at least it's not obvious where choosing which buttons appear happens in the CKeditor module. http://drupal.ckeditor.com/ has some documentation on the subject, which says you can change the buttons.
http://drupal.org/node/606404 for some background on why CKEditor and Wysiwyg are separate efforts (though you can use CKEditor just fine with Wysiwyg).
I'd be inclined to stay with Wysiwyg so that you can swap out editors (that is, the JavaScript libraries for them) without having to swap out Drupal modules.
The CKeditor module gives you have much more granular control around where the editor windows appear, user role level permissions and the buttons available for each. The WSYIWYG API just allows for basic on/off configuration of editor windows for text fields across the whole site. Button profiles are based around input types (filtered & full HTML). The advantages of the API module is that it's not limited to just one editor (there's 10 or so) and really easy to configure.
The Ckeditor module is more difficult to configure and certainly not for most implementations, but very nice to have this module available if you require that level of control.
From my experience, using the Wysiwyg module was a better decision.
In some special cases (mainly when the editing was inside of an Ajaxed page), using ckeditor was a bad chioce.
When using the Wysiwyg, replacing the editor itself wasn't a hard task, which solved several problems very fast.
Therefore, for future situations you might not even think of now - use the Wysiwyg module.
Using the WYSIWYG module will allow you to fairly easily switch to another editor if you find one you prefer (or if new ones come onto the market).
RE: WYSIWYG module using CKEditor library vs CKEditor module
I found the former only allowed the following toolbar;
(source: johnathanthwaites.info)
Later had much more like font colour, flash embed, spell check etc.
(source: johnathanthwaites.info)
Have done a full explanation here;
Link to CKeditor
Related
The GridFieldExtension module comes with a GridFieldRequestHandler class which would enable extending the default GridField detail view (eg adding tabs or breadcrumbs). Unfortunately this feature is not included in the module's documentation.
Q: Can this class be used to add the following functionality to the GridField detail view?
Back Button
Save & Close
Delete
Userfriendly breadcrumbs
I'm familiar with the module BetterButtons that includes all these features, but it would be unnecessary to install yet another mod it if this mod already enables these features.
In this case I would suggest using the Better Buttons module instead of using GridFieldRequestHandler. The Better Buttons module is well maintained, full of features and works right out the box.
I don't believe it's worth writing all the code needed to use GridFieldRequestHandler to reproduce the Better Buttons functionality. I think Better Buttons is the right tool for this job and it warrants being installed even if we already have the GridFieldExtension module installed.
Currently using CKEditor + IMCE.
http://drupal.org/project/ckeditor + http://ckeditor.com/
http://drupal.org/project/imce
Are there better alternatives for a Drupal rich-text editor with image upload support?
To set it up, I add the modules, enable them, add the CKEditor source, configure the Default CKEditor profile to not load unless I tell it to, disable security filters until it loads, and enable the Drupal - Full toolbar version. This gives me all the CKEditor features and flexibility, image and flash upload support via IMCE.
I have tried CKFinder, but I rarely use it on client projects (non-free usage licences). Other modules are a pain to configure and may sometimes break the interface or content (especially around full HTML or PHP inputs).
Update 1: Added a small bounty, looking for more answers.
After having trouble with the CKEditor module over and over again, I switched to http://www.drupal.org/project/wysiwyg , which encapsulates the JS of multiple WYSIWYG Editors in a generic way (by using input filters, which somehow feels like The Right Thing to me).
Add http://www.drupal.org/project/imce_wysiwyg - the WYSIWYG IMCE bridge module, and it works almost exactly as CKEditor.module and IMCE would. A plus: It works with other editors, too, just download and install the editor JS code per the instructions.
I suggest you http://drupal.org/project/whizzywig it is light, full featured and natively includes an image browser (have a look at the comparison table).
I did a comparison on our blog a while ago, looking at some solutions.
Currently I'm sticking with wyswiwyg + imce + tinymce + imce_wysiwyg.
BUT I don't think it's the perfect solution. However in Drupal 6, we don't really have a central image library, this will be a lot better in Drupal 7.
I would recommend checking this module out:
http://drupal.org/project/nrembrowser
It integrates with CKEeditor and might be the way to go.
I want to add basic WYSIWYG functionality to Drupal 6. It does not have to be bleeding edge.
I have found about 150 blogs and posts with options and an equal about of issues and problems
Can somebody point me to the easiest solution?
Easiest solution IMO is to use the WYSIWYG api to include TinyMCE.
You will need:
WYSIWYG dev release (supports new TinyMCE)
TinyMCE main package
The WYSIWYG module has an excellent administration screen to which you can turn buttons on and off with a simple tick box. I also prefer TinyMCE due to it's small library and therefore fast speed on browsers.
For file uploading and integration with the WYSIWYG, I use:
IMCE
IMCE Wysiwyg bridge
Which I find super easy, and business users seem to have no issues either. Supports image resizing and thumbnail generation
FCKeditor has been deprecated in favor of CKEditor. CKEditor also has a pay-for file manager addon called CKFinder.
CKEditor is a good choice. CKEditer can integrate with IMCE for file uploading as well as CKFinder.
FCKeditor and TinyMCE are both good, simple choices.
I finally got it working with this combination of modules.
TinyTiny MCE – text editor
Tiny MCE - js
IMCE – image uploader
I had a good blog with the recipe for setup, but can't find it today. :(
(I've posted this on the drupal forum too btw)
I'm converting the company websites to use Drupal, or at least trying to check that its going to be the best way forward. I have a background in PHP development, and I'm currently using the CakePHP framwork. I've built this site (not my design) and I can see how to replicate most of the functionality using Drupal, most likely using the CCK module.
http://preview.tinyurl.com/yk6u8mt
As you can see from the homepage:
A user chooses a country.
The country is passed using an ajax call to a script that decides which phone is best based on 'in country' network coverage.
A div is shown recommending the visitor the best phone for that country.
I'm wondering how to go about this in Drupal, I'm definitely not after a step by step guide, I just want to know if this kind of thing is possible with Drupal, and what approach to use.
If someone can help that would be superb. Thanks.
Okay, so you've got a path you're defining in hook_menu, which is where your form is being presented - or else you've got it set up as a webform in a node, that could work too.
Either way, in your form you're going to be using AHAH - check out http://api.drupal.org/api/drupal/developer--topics--forms_api_reference.html/6#ahah and http://drupal.org/node/348475 .
Basically, you're going to define another path in hook_menu that's of type MENU_CALLBACK, and which will receive the country as input, and then will return the div that you'll display on the screen.
One core example of AHAH that may be useful to you is where you're entering a password and it lets you know if the password is secure enough - check that out.
Edit: There's also some good examples at http://drupal.org/project/examples.
I would look into using CCK and views. you can set up filters for the views. If filters don't work, you have the ability to include php code. I have also successfully added jquery code in the header of a view through which I was then able to have my view filtered by what is typed in a text box.
Coming from CakePHP using Drupal is a pain in the a** - even more for developers.
It's application structure might be designed to ease extensibility but this only means you have a system to enable your own plugins and themes.
While modules are basically the M+C-part the themes are the V-part of an MVC-application. The problem is that this seperation is not very strict in Drupal - in fact you have to break it sometimes in order to make things work (e.g. you have to include a theme_mymodule_myfunction() into your module as default output which you then can override with your theme using mytheme_mymodule_myfunction() ) And don't even bother looking for classes ( see http://drupal.org/node/547518 ).
Also there is no real link from a module to a theme. On many occations this is a good thing as you can switch modules and themes seperatly without creating a problem. For application builders coming from CakePHP (or any other framework) you often feel a lack of "wholesomeness" - you create parts for a base software and have to live with it's drawbacks.
IMHO I wouldn't recommend this step. Drupal is fine if you have to manage a website and might add a few modules to add neccessary value (image gallery etc.) but I definetly don't recommend it as a base for a customized web-app.
In Drupal, is there a way to create new content (based on a content type that uses CCK) in a popup or lightbox or similar technique?
There are at least two worlds that I know of:
http://drupal.org/project/popups_reference which uses http://drupal.org/project/popups
and
http://drupal.org/project/noderelationships which uses http://drupal.org/project/modalframe
Both of these are about creating the node in a modal in order to reference it via a node reference field. There might be ones for more general purposes, or you could probably adapt one of those. I've been enjoying noderelationships lately. Haven't tried the other recently.
The projects sprugman refers to are useful when you need to create a referenced node while you're adding another node. If you simply want to make the /node/add/[contenttype] link to open in a lightbox, try the Lightbox2 module.
There is a great module in Drupal automodal that works with Modal Frame API. What you need to do is simply add a new class 'automodal' to your links... and the magic is done for you.
Another one is the Modal Nodereference module. Here is a quote about it (from the module's project page):
... turns the nodereference widget into a modal popup allowing new linked nodes to be created on the fly. Because it uses an iframe, it should support even Javscript and file uploads within the sub-node.
The big feature: It should work with editors, image fields, and all of those other JavaScripting things. We built it precisely to meet those needs. We started with modalframe, instead of one of the other popup libraries, because we knew that we could make this work with TinyMCE, CKEditor, and ImageField -- libraries that have difficulties dealing with other popup APIs.
It depends on the Automodal module, as well as the excellent Modal Frame API module.