Upgrade Your Drupal Skills

We trained 1,000+ Drupal Developers over the last decade.

See Advanced Courses NAH, I know Enough
Jun 21 2016
Jun 21

Google Summer of Code (GSoC), has entered into the mid-Term evaluation stage. This is a 1 week period from 21- 27 June, were students and mentors present the progress of their projects. Based on the reports submitted, students are made pass/ fail.

I have been working on porting Search Configuration to Drupal 8 in the past few weeks. If you would like to have a quick glimpse of my past activities on this port process, please go through these posts.

last week, I could learn some Drupal concepts which were really helpful for my project. In the previous versions of Drupal, the role permissions were stored in a role_permissions table in the Database. But now, in Drupal 8, the role permissions are directly stored in the role configuration entity.

So, as described above, in D7 and its preceding versions, role permissions were stored in a role_permissions database which had the role Id and the corresponding permissions. The permissions distributed to a role was retrieved in D7 using:

$permissions = role->getPermissions();

But, in D8, this is done by the

$permissions = role->getPermissions();

Another instance is that, to grant certain permissions to roles.

In D7 it was controlled by,

user_role_grant_permissions($rid, array(‘ access content’));

The role configuration entity remodels this functionality in D8 to:

$role->grantPermission(‘ access content’);

In connection with the term permissions, the most important aspect in Drupal is a hook: hook_permissions(). This hook, obviously as you might have guessed, distributes the permissions to various users; decides whether a particular user should be allowed to access a page or a content, granting and restricting the access.

This hook has been replaced in Drupal 8 by a module.permissions.yml file. This file contains the permissions and its specifications. We can write a driver function in a php file to add the dynamic permissions. This can be achieved by making a driver class in the php file and adding the behaviour of the permission we need in the member functions of the class. We also have to link this PHP file with our yml file to keep it active. This is done by adding a callback function in the yml file which references this php file.

To display special characters in a plain text string for display as HTML format, Drupal earlier versions used the function check_plain.  This had the general syntax:

check_plain($text); // where $text was the string to be processed.

This function has got deprecated in Drupal 8. This has been replaced by the \Drupal\Compoent\Utility\Html::escape($text).

Mar 22 2013
Mar 22

Listen online: 

In this episode, Addison Berry is joined by Kyle Hofmeyer, Dave Burns, Jerad Bitner, and Sean Lange to discuss the deceptively simple question "What is a Drupal Site Builder?" This is a term that is bandied about quite a bit, but we wanted to try to zero in on what exactly a site builder does. We end up talking about several different roles that are often used around site-building, like themer, front-end developer, developer, and they relate to each other. In the process, Dave and Sean end up creating some new words too. What is a globulator?

Podcast notes

Ask away!

If you want to suggest your own ideas for podcasts, or have questions for us to answer on a podcast, let us know:
Contact us page

Release Date: March 22, 2013 - 10:21am


Length: 39:31 minutes (22.86 MB)

Format: mono 44kHz 80Kbps (vbr)

Nov 19 2012
Nov 19

Drupal's highly granular permissions system allows site builders to control who can create, edit, and delete each type of content on the site. Third-party modules can add additional permissions to that mix as well, paving the way for extremely focused role-based permission setups. The interface for configuring all of those permissions, however, is more than a bit cumbersome. Thankfully, the Permissions Grid module offers a solution: a consolidated permissions page that only includes node and entity type specific options.

Screenshot of administration screen

Installing the module doesn't alter the operation of Drupal's standard permission forms. Rather, it adds an additional "Permissions Grid" page that exposes just node and entity related permissions. Because Drupal 7's entity system includes Taxonomy terms, Drupal Commerce products, Flag module flag types, and more. Because the permissions are organized by content and entity type rather than by name (the normal Permission screen's default), it's quite a bit simpler to set them up or skim them to review their current state.

Permissions Grid is a simple module, but if you're frustrated by the complexity of node type permissions, it's a quick and painless solution.

Apr 20 2012
Apr 20

How do I allow a user to create other users?

It’s a pretty common use case which requires a non-admin user role that can create other users for a Drupal site and I’ve frequently seen questions about how to best implement this. I recently also saw the suggestion to simply create a role with the 'Administer users' permission. At first blush, it might seem to work; if that’s the only “administer” permission they have, users with this role can only create basic users with the role “Authenticated user”, they cannot edit the user to add any other roles or upgrade their own role directly. In limited situations, this might even be appropriate.

Drupal’s “administer users” permissionUsers with the administer users permission can edit any other user on admin/people

What might not be immediately apparent, however, is that a user with this permission can edit any other user’s account… and I do mean any. This means that, if their intentions are not pure, a user with this role could easily change the password (or any other fields) on a more privileged user, even user/1, and then log into that account. Once they’ve done that, there is really no limit to what they could do to your site. Even if they have no means to add modules, ones which might be used for particularly nefarious purposes, if you have a module like Backup and migrate available, they could download your database with all sensitive user data; and even if this module is not available to them, you most likely have Views, which they could also use to harvest all user email addresses or other private data fields. And then they could easily cover their tracks, too. If they don’t do anything obvious (like deface your site or start sending spam from it), and only change the password on the admin account, you might be puzzled by why you cannot log in with your normal password, and follow the normal procedure to reset your forgotten password, then forget all about it. Meanwhile, your “user moderator” has collected lots of sensitive data from your site and still has the means to do it again one day.

There’s a module (or a few) for that!

Depending on your actual use case, which might include requirements a bit more complex than just creation of a basic “Authenticated user”, there are a number of modules which might be useful for a “user moderator” role. Some of these modules do nothing about actual creation of users, after all, probably most Drupal sites allow users to just register themselves, but deal with the related need to delegate the responsibility of giving some users additional roles beyond the “Authenticated user” role. But for sites which don’t provide self-registration, there are a couple of modules which allow non-Administrators to create new users, as well.

  • Role Delegation is one of the most popular such modules, used by over 8000 sites with stable releases for both Drupal 6 and Drupal 7, but it’s limited to role assignment and does not allow users without additional permissions to actually create new users.
  • Administer Users by Role has stable releases for Drupal 5 and Drupal 6 and allows users of a particular role to create, edit, and delete other users. In theory, it should provide limits to the “administer users” permission by allowing them to administer users with roles that you select. There is no version for Drupal 7 yet available, but a port is in progress. It’s a fairly popular module with about 2,500 users.
  • RoleAssign is a module with a stable release for Drupal 6 and a “release candidate” for Drupal 7 and is used by about 2,800 sites. It allows users with appropriate permissions to assign pre-defined roles to other users.
  • Subuser is a module available for Drupal 6 (stable) and Drupal 7 (currently in -alpha2). It is, perhaps, the most advanced and interesting of these modules, although it is not used by the most sites (currently only 282 sites). It allows for a user to be given permission to create users which that user then has permission to manage. Users not created by this “parent” user are not available for management. “Child” users can be given any of the roles which the “parent” is allowed to assign, and the role assignment can be automatic. In other words, an “editor” might create “author” users or a primary “site moderator” might create “forum moderator” users, etc. I think this module shows a lot of promise, especially since it’s written and maintained by the highly esteemed boombatower, a true “Drupal rockstar”.
  • User Creator is a module which will not be ported to Drupal 7 (they suggest using the aforementioned Subuser module). It allows users with particular roles to create other users with particular role limitations. The example is provided that, for a school website, a “Principal” could create other users with the roles “Teacher” or “Student” and a Teacher could create only “Student” accounts. Site administrators can determine which roles are allowed to create accounts for which other roles.
  • Control Access to User Settings is a module which seeks to increase the granularity for the “administer users” permission, so that user settings and user administration are separated under this permission and a site administrator can assign just a part of this permission. It has a “stable” release for Drupal 6 and a development snapshot for Drupal 7.

In short: Beware of granting excessive permissions

Be very careful (and generally avoid) granting any kind of “administer” permissions to non-Admin-role users. This article should make it clear that the “administer users” permission is one that could lead to disastrous results if given to the wrong user. While it might even be appropriate to give this permission to a very trusted “admin helper” (e.g. if you want to hide some of Drupal’s administration complexity from your partner—so want to give them some admin permissions—to avoid having them be overwhelmed by the full admin interface), you must absolutely trust such a user not to do anything to abuse the power. And then, it’s probably still best to use one of the appropriate modules, just in case you might forget and grant the same role to someone you trust less than your partner, just to allow this other person to add some new user accounts.

Hopes for the future of Drupal

As I see it, something like the Subuser modules could well be a part of Drupal core. There is almost no reason for any non-admin user to be granted the full power of “administer users”, but there are many reasons you might want to allow for a role that can at least create users and provide limited management of other users (with fewer permissions than their own). I believe some degree of this functionality would be a good thing to include in Drupal core and hope to see that in the future.

Oct 28 2011
Oct 28

Some time back, I promised another short article in the WYSIWYG set-up series for Drupal 7, one which covers BUEditor. First, we should note that the BUEditor is not actually “WYSIWYG”, but it offers some nice features which might make it a bit better than the WYSIWYG options, depending on your use case. It also does not integrate with the Wysiwyg module. You add it separately (and instead of Wysiwyg), but it does have some great supporting modules and code libraries. This article covers some of the basics about use and installation of the BUEditor on a Drupal 7 site (most of the information applies equally to Drupal 6, where the BUEditor module is also available). I’ve also got some good tips for some ways to extend the default button-set. (And you can download my modified button code here to easily import the buttons into a new editor profile.)

The BUEditor is now used on Drupal.org

The BUEditor is now in use on Drupal.org. Nice!

Since the time I planned to write this post, BUEditor has surely got some additional attention; it’s now what you’ll use if you leave a comment on an issue or forum post on Drupal.org. It’s refreshing to have more than just a plain text area for HTML entry; I think this is a great step for the Drupal community’s official site. In addition to basic set-up of the BUEditor, as it’s used on Drupal.org, I’d like to cover some nice features of the BUEditor which are not being used on Drupal.org.

The BUEditor integrates nicely with IMCE

The default BUEditor Insert/edit image pop-up dialog is very limited but can be modified.The most recent article in this series covered the set-up of IMCE and supporting modules for inserting images. You’ll be glad to know that the BUEditor supports adding images with IMCE. I’m sure you could also simply “attach” images and add them to content with the Insert module. The BUEditor’s default image popup is very limited, which was at first a deal-breaker for me to suggest using it on this website, however I learned it’s not so difficult to adjust the pop-up dialog to add more fields; by default it only has the URL, dimensions, and alt text fields. I also wanted fields for title text, class, and style (though it is probably best to avoid using inline styling, it’s sometimes handy and nice to have a GUI for adding this to your tag when you create it).

Remaining downsides to the image dialogue

At first it wasn’t obvious how to add new fields to BUEditor Image dialogue for Title, Class, and Style…Proportional dimension calculations: It would be nice if there were support for automatic adjustment of the “Width” and “Height” fields to adjust one automatically (by ratio) if the other is modified. I tend to place images that are often wider than 600 pixels, which means they would not display nicely in the layout of this site. The Image Resize Filter automatically creates a smaller image, to be displayed in the content, if I adjust the size when placing the image. And it’s easy to link the full-size original image to appear in either a Lightbox2 or Colorbox overlay. If I have an image which is 938 pixels wide by 529 pixels high, and I change “Width” to 600 in the BUEditor image popup, I’d like a default option for the “Height” to automatically be proportionally re-scaled, as it works in CKEditor and TinyMCE. It’s not hard to calculate what the height should be, but I’d rather not have to, and I’m not the only one who would have to. The easy solution to this is to just leave the height field empty and the Image Resize Filter will still proportionally resize the image, but if the image doesn’t load, for some reason, the page layout will be affected.

Longer fields: Even after working out how to add the new fields, I couldn't figure out how to make the whole dialogue larger (assuming physical display size is large enough) so that these fields could all be a bit wider. The default size of the text fields is pretty darn short, but my initial attempts to modify this just ended up breaking the whole editor. Well, it’s not a big deal, but perhaps I'll figure out how to further customize the image pop-up. (If anyone knows how to make such modifications through simple button code (or an add-on module), please share your tips.)

Quibbles aside, the BUEditor really is awesome!

BUEditor has a great preview function available with the Ajax markup moduleThe BUEditor provides a nice, clean user interface with what could be a perfect balance between simplicity and usefulness, provided users are comfortable with working directly with HTML code. It’s easy to apply formatting to selected text and it’s also simple to modify the values of the editor buttons or add your own. Converting unstyled lines of text into lists (ordered or unordered), blockquote, or heading, is as simple as the click of a button and if anything gets mucked up, you have the code right there to adjust, but it’s less likely to get messy than with a WYSIWYG editor since you have complete control over what you select before you click the button. This might be a good time to mention that there is also a Drupal-free version of the BUEditor, though the BUEditor was first created specially for Drupal, unlike so many of those other (“WYSIWYG”) editors.

It’s especially awesome with the Ajax Preview option enabled

The Ajax markup module, also written by the author of the BUEditor, allows you to simply modify the “Preview” button to provide a display which closely matches the end result (taking the text format settings into consideration). Awesome! I’d like to see them add this integration on Drupal.org, too, since it’s much faster and nicer than reloading the page with the main “Preview” button. It would be great to also have this functionality in a Wysiwyg-integrated editor. Bear in mind, once you have this configured and working, clicking the “Preview” button displays the preview and by dragging on the handle at the bottom of the editor pane, you can see the corresponding code… but you won't be able to edit that code till you click the “Preview” button again.

BUEditor keyboard shortcut support

Not all browsers support the shortcuts equally, but when you are actively using the text editor, you should be able to use keyboard shortcuts to add tags, snippets you’ve configured, or perform other editor functions. In Safari, I found that I had to use the control and option keys in combination with the configured key. In Firefox it was just the control key. More than one editor in a page can mess this up and the shortcuts may not work at all in some browsers, but they can certainly be useful. You can also remove the key codes if you think it might cause more problems for your users than it’s worth.

Keep in mind: The button-set is based on role

One potential issue is that the editor button set is based on the user role, not on the Text format. So it’s still easy to create content (as a privileged user) in the “Filtered HTML” format, and include images or other tags… that are then stripped on output. With Wysiwyg-integrated editors, the button sets are per text format. There are pros and cons to this, but I’d prefer to have a default editor configuration for each text format. There is a BUEditor Plus add-on module which aims to take care of this issue, but it’s still in beta (actually still in the developer’s “sandbox”). Since it’s likely to be released soon as a full project, I won’t link to the sandbox. Instead look for the module on HollyIT’s user page on Drupal.org. Caveat: I can not confirm that the sandbox beta is ready for production use. Use or experiment at your own risk.

Another cool feature: BUEditor supports BBCode output

Many forums and sites support BBCode, which is easier for users to enter, a bit simpler than HTML, and removes many of the potential hazards of allowing users to enter HTML. If you want to have commenters post using BBCode, it’s as simple as configuring the button-set for the included BBCode editor. The defaults might already be everything you need. Of course you’ll also have to add and enable a BBCode text filter.

Are you ready to install and configure the BUEditor?

Add and activate the modules

Add and activate the BUEditor module (plus optional modules if you like)admin/modules
You will want to download the appropriate modules. The BUEditor module is required, of course, and I also recommend the Ajax markup module. Add them both to your sites/all/modules folder, then activate them, as usual. If you want to use IMCE, IMCE Mkdir, and/or the Image Resize Filter, be sure to add and activate them, too (see previous lesson about using IMCE with images in a Wysiwyg-integrated module and just follow the steps for configuring IMCE and the Image Resize Filter.)

Note: The BUEditor Plus module is also shown here, but may not yet be ready for production use. And, in case you were wondering, Internal links is a module I’m working on in my free time, so you see an “unversioned” copy in the screenshot from my D7 development installation. I will be committing some improvements to that in the near future.

Configure the BUEditor

Click the “Import editor” link to easily start from exported button code, like the modified button-set I’ve attached here. By the way, I’ve tested this button code in both BUEditor 6.x-2.x and 7.x versions. The same button definitions work in both.

To import a previously exported button-set, paste the code in the “Editor code” text area

You can simply paste the code from the file I attached if you have the Ajax markup moduleYou can create a new editor based on the Default profile (as I did originally) or you can import the code I’ve already modified to provide what might be a better starting point. Simply add a name for your new editor and paste the code from that file into the text area labeled “Editor code (PHP)

If you choose to start from the “Default” set, and want to enable Ajax preview, look for the “Preview” button in the “Buttons” rows and paste over the existing “Content” for that button with the following code:
js: E.prvAjax();

Note: This is already done in the attached version of the button-code.

You might want to remove the H1 tag from the “Headings” selector button. Another change I made was to remove the “Heading1” selector from the default Headings button code. Why? A page should really only have one <h1> tag, and it’s already provided by the node’s Title field, so except in unusual use cases, you’d never want to have this in your editor. That tag can be removed from the button very simply by dragging the “Content” text area for Headings open to see the full contents and selecting the second line for deletion. I also added a few new text buttons for <p>, <br />, and <?php tags; adding or customizing such tags is super-easy, especially if you simply add a plain text “Icon” to represent the button in the editor, as I did. If you want to add custom icons, you can supply the path to find your custom icons (e.g. a copy of the default icons, plus a few more that you create yourself; or you could replace the original icons with ones you like better. The original icons are all 20 pixels high, so match the height and your icons should look fine; for my paragraph and line-break buttons, a plain-text button suits me, but I’ve created a few alternate icons, included with the attached code.) If you choose to use alternate or extra icons, be sure to follow the directions included in the readme.txt file within the BUEditor module’s “icons” subfolder and copy all default and custom icons that you want to use to a new sub-directory under your files path.

Additional simple toolbar configurations

Export your modified button code.You can drag rows up and down to adjust the order of icons in the BUEditor toolbar. You can also modify the keyboard shortcuts linked to the buttons and make other simple modifications before saving. I would suggest that you actually save periodically and make sure that everything is still working in the “Demo” text area, especially if you are editing button code or adding new buttons.

It’s a good idea to periodically select all buttons and export your button set. To export all buttons, simply select the checkbox at the top right of the “Buttons” configuration table, which will select all checkboxes, then at the bottom of the list, select the “Export” action and click “Go”. You can also use this action selector to remove buttons with the “Delete”, copy selected buttons to another configuration of BUEditor, etc. If you don't do this, you might not notice when your custom code gets broken until you just have no icons showing up above the Demo textarea after clicking Save configuration. If you’ve got the buttons backed up, you can easily revert to a working set.

Assign the new editor(s) to suitable role(s)

Don’t forget to assign your editors to roles.admin/config/content/bueditor
Be sure to go back to the main BUEditor configuration page and select your new editor configuration to use for the appropriate roles. In this case, the “advanced” editor I set up for “Staff” needs to be assigned to all trusted roles who have access to “Full HTML”. You may also want to assign an editor for basic “Anonymous” and “Authenticated” users. Untrusted roles should probably not be allowed to add images, headings or other special tags. The included “Commenter” editor configuration is likely appropriate for your “Filtered HTML” needs, but if you add any additional buttons to be used by roles who only have access to “Filtered HTML”, be sure to make corresponding changes to the “Allowed HTML tags” in your “Text formats” configuration:
As mentioned before, you could also configure the BBCode editor or set up an editor for other special markup languages. Exploring these use cases is outside the scope of this article.

More advanced configuration

Super light-weight HTML syntax highlighting; how cool is that?!You can do a lot more with the BUEditor… this article might be a bit long, but the official documentation is even longer. There are loads of API functions for doing really cool stuff with BUEditor buttons; and don’t overlook all the pages of contributed button code. Before you spend a lot of time trying to figure out how to implement a particular button for your needs, take a look at what’s already tested and available; even if you don’t want the exact functionality offered by a contributed button, it may offer an example you can more easily adapt to achieve your particular needs.

Some of my favorite contributed buttons include the:

  • Special Characters button, which provides a nice pop-up panel for just about any “special character” a user might want to insert
  • Text Color button, which provides a pop-up selector with color swatches which can be applied to text or backgrounds
  • Class Attribute Library; allows easy addition of a particular class to selected HTML
  • Smileys Button, which provides reasonable integration with the Smileys module (unfortunately not yet officially available for Drupal 7, though it does look like the port is reasonably complete.)
  • Remove Formatting button (perhaps less risky than the one I created since it only strips designated tags, so won’t remove everything inside of IMG tags or between the php tagset used for longer blocks of syntax-highlighted code.)
  • BUEditor Imagecache button (similar to the standard insert image button, but also allows selection of a pre-set image style)
  • BUEditor Quick Table (okay, HTML tables are worth avoiding, but sometimes data content really is best displayed in a table; this makes it easy)

Good luck and have fun…

We wish you every success configuring your Drupal site for maximum productivity and a user experience to write home about. The BUEditor might not be for everyone or every use case, but its light-weight code-base is amazingly efficient and with the proper configuration it can be better than a WYSIWYG editor for offering a friendly way to add and edit content. If you come up with some interesting things to do with it or have comments about this article, or any of our others, we look forward to hearing from you. Please feel free to leave a comment, below.

Thank you for visiting us on the Cocomore Drupal blog.

Oct 06 2011
Oct 06

This article covers the configuration and use of IMCE (and related modules) to integrate uploading and inserting images within your Drupal content. We assume you are using either TinyMCE or CKEditor with the Wysiwyg integration module, but in a separate post we will cover using IMCE with the BUEditor, a simpler text editor which also works well with Drupal. Note: This article uses Drupal 7, but most of the tips should also be helpful if you are configuring a Drupal 6 site for the same functionality. Indeed, this site is still running on Drupal 6 and also uses a Wysiwyg-integrated CKEditor, IMCE, the Image resize filter, and Lightbox2.

Add necessary modules to sites/all/modules

Add necessary IMCE-related modules to your sites/all/modules directory

If you’ve been following along, you’ve already added the IMCE and IMCE-Wysiwyg Bridge modules; otherwise this is the first step you’ll want to take. In addition to these required modules, this post also covers using the Image Resize Filter and Lightbox2 modules, which work together with IMCE and Wysiwyg to allow you to automatically create smaller images embedded in your content, which are linked to the full-size images and can optionally be viewed in a Lightbox overlay. This is very cool, especially if your original images are wider than the content area and you wish to give users a closer look without actually opening a new window for the image or forcing the user to click the back arrow to return from a linked image to your Drupal content. The IMCE Mkdir module allows you to add directories to your file hierarchy so that you can keep uploaded media nicely sorted.

Activate the modules you’ve added

Activate all the modules you’ve added

You’ll find the Image Resize Filter in the “Input filters” fieldset. IMCE and IMCE Mkdir should be in the “Media” fieldset. And the IMCE-Wysiwyg Bridge and Lightbox2 modules are activated in the “User interface” fieldset. Click on the “Save configuration” button and you’re ready to move on. Note: Using Drush to add and activate modules is outside the scope of this article, but is a nice time-saving trick.

Configure IMCE

After saving your configuration, you can go through and click on the “Configure” links beside the modules which have additional configuration. If you only intend to allow your “User-1” (initial admin account) to upload and insert images into content, then the defaults for IMCE might already be suitable. But assuming you have other roles who you trust enough, you’ll probably want to adjust the default configuration and permissions.

Start by taking a look at the IMCE configuration for your “User-1” profile (we have made no changes to this profile, so will not display a screenshot, but if you don’t have IMCE installed yet, you can see a screenshot of this configuration here).

For the sake of this example use case, we have created additional “staff” roles for “Editor” and “Author” users, who will be allowed to use the “Full HTML” text format (or a custom text format which allows image uploads) and will be allowed to upload images using IMCE and perform various levels of file administration. Our standard anonymous and authenticated users will not be allowed to use a text format with <img> tags at all, so we will not need corresponding IMCE profiles (allowing untrusted users to use <img> tags is a potential security issue which is best avoided; using BBCode or Markdown for these roles can help mitigate the risk if you really want to allow new users to display images on your site — but further discussion of this matter should be considered outside the scope of this article). If you do add new roles, be sure to give them appropriate permissions. For this use case, we’ve given our Author and Editor roles permission to “Use the Full HTML text format” and permissions to create and edit various content types. (admin/people/permissions/list)

Add a new IMCE profile

Import settings from User-1 profile then tweak a bit for our Staff profile.You will probably wish to add a new profile for any new roles. For my simple use case, I will create one “Staff” profile which will have almost the same defaults as the “User-1” profile. We can save time by clicking the “Import settings from other profiles:” link labeled “User-1” and then tweaking the profile a bit more. We might want to cap the directory quota a bit, but not nearly as much as the 2MB, which is the default for a new profile. We also want to allow our staff to create directories in the main files area rather than within a subdirectory with their user-ID. Be sure your settings are a good fit to your use case.

Make your Role-Profile assignments

Make sure appropriate roles are assigned to a profileAssign the “Staff” profile to appropriate roles and make sure the “weight” of each role has them in correct order of their importance (descending order). We aren’t going to allow authenticated or anonymous users to upload images, so we won’t assign any profile to them.

Make sure applicable Wysiwyg profiles include IMCE in “Buttons and plugins”

Make sure you check the IMCE checkbox in your Wysiwyg profile configuration.admin/config/content/wysiwyg/profile
Assuming you have followed the steps in the previous article in this series, you have already configured Wysiwyg profiles for your editor(s) of choice. The IMCE-Wysiwyg Bridge module which you've activated in this lesson adds another checkbox (to at least some of the editors which you can integrate via Wysiwyg, e.g. CKEditor and TinyMCE), labeled IMCE, which you'll probably see down in the bottom row of your “Buttons and plugins” section for each applicable profile. Check the IMCE box and the “Image” (and “Advanced image” for more features in TinyMCE) checkboxes. The IMCE checkbox does not actually add a button to the editor’s menu bar (you just see the normal image button). The pop-up box for adding images should now include a link to “Browse server”.

Configure the Image resize filter module and Lightbox for your text formats

Configure your Full HTML (and/or appropriate) text format(s) for Image resize filter and Lightbox filteradmin/config/content/formats
The only settings for the Image resize filter are found in Text formats. It is a filter which you can turn on and configure individually for each text format. What we want is to configure the Image resize filter to link a resized image to the original and display the full-sized original image in a Lightbox overlay. In my simple use case, I'm giving all “staff” roles access to Full HTML; you may wish to create and configure an additional text format, e.g. one somewhat more restrictive. We need to make sure the Lightbox filter is active, as well as the Image resize filter. I have had good success with the Filter processing order displayed (with the Image resize filter running before the Lightbox filter). Note: There are several other Lightbox-related filters available if you want to use Lightbox for other special purposes (e.g. video, slideshows, etc), but for the basic needs of our use case, we only need the “Lightbox filter”.

When the Image resize filter is active, there is a tab at the bottom of the Text format configuration screen to adjust its settings. Click on that tab and at least select the option to resize locally stored images. Check the box next to “If resized, add a link to the original image.” We can see, from looking at the help text for the Lightbox filter that “Image links with rel="lightbox" in the <a> tag will appear in a Lightbox when clicked on.” So we put if we put “lightbox” in the text field for adding a rel attribute, everything should work correctly. Note: The JavaScript degrades gracefully — even if JavaScript is unavailable or inactive, the link will still work; it just won’t open the full-size image in a Lightbox overlay, but in the current window.

There are additional settings available for Lightbox2

Assuming you only want Lightbox for the purpose of giving visitors a better look at images resized and embedded in your content, the default settings should suffice. Lightbox will even add captions to images if you add a title attribute to the images. This is default behavior. But if you want to use Lightbox to view galleries of images (e.g. a group of images attached to a node), adjust settings for displaying video content in a Lightbox, prevent Lightbox from being active on certain pages or sections of your site, or want to configure Lightbox for Flickr content, Gallery2, Image assist, or other possible integrations, there are some settings you may wish to adjust. Note: there are four tabs at the top of the Lightbox configuration page, so in addition to all the settings hiding in the individual collapsed fieldsets on the “General” tab, there are dozens more settings there for you to tweak. Digging into everything you can do with Lightbox2 is well outside the scope of this article, but may be covered at a later time.

You are now ready to start uploading and inserting images

There are a few steps to the process of adding an image into your content:

Click on the Image button in your editor…

Put your cursor at the beginning of a paragraph and click the “Image” buttonBe sure your cursor is at the beginning of the paragraph where you want your image to appear (especially if you want text to flow around your image). The “Insert/edit image” button is similar in both TinyMCE and CKEditor:

Click on the “Browse server” button…

Click on the “Browse server” button to select an image You should get a pop-up window for inserting an image, which should look something like this. Note: This illustration shows the basic Image popup option for TinyMCE, further below we also show what the popup looks like if you've selected the “Advanced image” option in TinyMCE (recommended, if using TinyMCE) or if you are using CKEditor (similar to TinyMCE with the “Advanced image” plugin option.)

Click on the “Upload” button in the IMCE window…

Click on the “Upload” button in the IMCE windowIn addition to the “Upload” button, which pops up a “browse” window to files on your local operating system, this window is where you can create a directory structure for your files. You may want to create directories for your content types and/or for individual nodes, if each article has many images. If you’ve set permissions in your IMCE profile for non-admin users (e.g. the “Staff” profile we created) to upload, create, and/or delete directories, you will see the corresponding buttons in this window. Note that if you use IMCE’s “Resize” function, this will create a resized version of your file as the “original” passed to your editor, which would be viewed in your Lightbox overlay. I do not usually use the “Resize” or “Crop” buttons in the IMCE window. Resizing an image, especially one in a stored in a file-type with “lossy” compression, e.g. JPEG, is best done as few times as possible, so we should preferably only upload files which are already cropped and sized the way we wish them to appear in the Lightbox overlay. That said, there may still be times when these functions are useful.

Click on the “Insert file” button…

Click the “Insert file” button to pass the file details to your editor’s image popup

After you select a file to upload (you can upload several and then just select them from your server directory as you insert them), click on the “Insert file” button.

Adjust options in your editor’s Image popup window

Selecting left or right alignment translates into inline CSS styling: style="float: left; ", for example. This is a good time to talk about some of the differences between the image popup panels provided by TinyMCE and CKEditor. The “Advanced image” plugin for TinyMCE provides a field for “class”, which can be a better way of styling image placement since the class can also include padding or margin settings, etc. It also allows you to resize an image, automatically adjusting the second dimension (width or height) to keep the same ratio, and provides a field for the image title, which is used by Lightbox2 to provide a caption below the image. To get the advanced options, select both the “Image” and “Advanced image” options when configuring “Buttons and plugins” for the applicable Wysiwyg text format(s). Be sure to enter something useful in the “Image description” field; this will be your alt text; it is displayed if the image does not load or if a visitor is using assistive technologies (i.e. alt tags are required for better accessibility); alt tags are also required if you want pages to pass HTML validation on W3C and are useful for providing search engines more information about an image (so are good for SEO). In CKEditor, the standard “Image” button yields a popup with all the features of the “Advanced image” version in TinyMCE. The fields and buttons are labeled somewhat differently, but each has three tabs which include fields which provide basically the same end result.

These are the most important two tabs in the TinyMCE Image popup

The “General” tab in TinyMCE’s advance image popup includes both “Image description” (alt) and “Title” fields.The TinyMCE “Advanced image” popup has a tab for “Appearance”, where you can set alignment, dimensions, and other styling.

The “General” tab in TinyMCE’s “Advanced image” popup includes both “Image description” (alt) and “Title” fields. The popup also has a tab for “Appearance”, where you can set alignment (i.e. “float” left or right), dimensions, and other styling.

The corresponding tabs and fields provided by CKEditor…

In CKEditor, the “Image Info” tab provides your basic Alt text and size options, as well as the “Alignment” for floating an image left or right in your content.The “Advanced” tab in CKEditor’s image popup provides a field for the HTML title attribute (labeled “Advisory title”) and allows you to tweak the inline CSS styling.

In CKEditor, the “Image Info” tab provides your basic alt text and size options, as well as the “Alignment” for “floating” an image left or right in your content. The “Advanced” tab provides a field for the HTML title attribute (labeled “Advisory title”) and allows you to tweak the inline CSS styling.

Resized images appear in the Lightbox overlay when clicked

And this is what your Lightbox overlay will look like (if you adjust the width and/or height in the editor's popup window or in the HTML source code, the original is displayed in the Lightbox overlay when you click on the resized version).

What your Lightbox overlay will look like

Sep 18 2011
Sep 18

In Drupal, there are actually a number of ways to add a WYSIWYG editor to a text area. The new “Drupal way”, used on over 150,000 Drupal sites and arguably not so “new” anymore, is to use the Wysiwyg integration module, which has support for several of the editor libraries. I would personally suggest using it, if your needs can be met by it, since it's becoming more and more powerful and offers a fair bit of flexibility to easily change the configuration or editor used. That said, there may still be reason, in Drupal 7, to use one of the single-library integration modules, such as the still-popular CKEditor project. The TinyMCE integration module development has already been abandoned in favor of Wysiwyg, but it's good to have alternatives. Note: In this post, we assume you already know your way around Text formats. Text format configuration can be one of the most tricky parts of properly setting up your WYSIWYG experience, so if you don't already feel you know your way around this common stumbling block, be sure to read our recent post about Text formats / Text filters, too. This article is a companion-post to that one, but it also includes some degree of overlap, since when we turn on the Lightbox and Image Resize Filter modules, we have new filters we'll want to use in some text formats and we will want to pay attention to the order in which they are applied, so we will briefly revisit this topic here.

If you happen to like the more “minimalist” editors, and your site's users won't be freaked out by having to see actual HTML code, you may wish to consider using BUEditor instead of any of those which integrate with Wysiwyg. We will cover using it in another post, since I've personally been convinced that it's maybe even more awesome than a “WYSIWYG” editor. This post will simply cover setting up TinyMCE or CKEditor with the Wysiwyg integration module.

First we'll add and activate the Wysiwyg module

Put all contributed modules in the sites/all/modules directory

Please start by downloading the latest stable release of the Wysiwyg module. Contributed modules like this are usually added to the sites/all/modules directory. It's activated on the Drupal admin/modules page in the “User interface” fieldset, which you should see near the bottom of the page. Since it's common to want images within posted content, we are also going to demonstrate using IMCE and the IMCE-Wysiwyg Bridge to upload and insert images and we'll also add Lightbox2 and the Image resize filter module for improved display of images. You can add all four of these image-related modules to your sites/all/modules directory and also activate them at admin/modules. This blog post will not delve deeply into configuring images or associated modules — this can be a rather complicated topic, so it should also be covered in a separate post. So, while we'll be integrating IMCE and Lightbox2 for display of embedded images in this tutorial post, the full configuration of these modules will be covered separately.

Add editor library(ies) to your sites/all/libraries directory

If you aren't already sure that you want to use TinyMCE or CKEditor, it's a good idea to take a little time to experiment with at least some of the different alternatives to determine which you like the best for your use case. CKEditor and TinyMCE are the two editors which integrate best with the Wysiwyg module and IMCE (to allow uploading and adding images to text areas). You could try some of the others, but bear in mind that, at least at this stage, many of the editors are not very fully supported by the Wysiwyg integration and may not have support for the full button sets available, nor for integrated image upload, etc.

Editor code, once downloaded, is extracted in sites/all/librariesEditor libraries are added to Drupal by extracting their code files and putting them in the sites/all/libraries directory, which you should create if it doesn't already exist. In a few odd cases you may need to rename a directory or add/remove a level of hierarchy, so it's best to read the installation directions on the Wysiwyg profile page, which you'll find at the bottom in a collapsed field-set. Click it open and find the directions that apply to your editor of choice. For TinyMCE or CKEditor, you should be able to simply download the latest stable version of the Javascript libraries for the editor and extract the archive (.zip file) into the sites/all/libraries directory, as per the directions:Download and extract the TinyMCE javascript library in the sites/all/libraries directory

One of my long-time personal favorite editors for embedding in browsers is the Markitup editor. It's simple, light-weight, and technically is not truly “Wysiwyg”, but it offers some nice features you won't normally see in the really fancy-looking editors. If your target audience could be described as “HTML-savvy” (or BB-Code-savvy / Markdown-savvy, etc), they may prefer such an editor since they always have access both to editor buttons and to a view of the generated code. And where other editors may add a dozen lines of in-line CSS styling when you paste text from a styled document, Markitup will only copy the text, not the styling. Even better, you can wrap a tag-set around selected text with just a simple keyboard shortcut.

What the Markitup editor normally looks like

I like the nice combination of simplicity and power that Markitup offers, but you can't get it with Wysiwyg module and Drupal 7.

As you can see it offers most tags you'd want for any HTML content and you'd only need to hand-code a few tags, here and there. You can experiment with this configuration on the Markitup "examples" page.

This is Markitup integrated by Drupal 7's latest version of the Wysiwyg module

Markitup has very limited support with Wysiwyg integration in Drupal 7.And that's with ALL available buttons selected… so Wysiwyg integration supports only a fraction of Markitup's standard Filtered HTML button set. Most disappointing! Well, having read up on the topic, I believe that it's just some work, currently, to integrate each button, so some editors that many people use are much better supported while others may still be more of a “development stub” example that the community can build on. It may just be that those of us interested in Markitup will have to help complete its integration with Wysiwyg (or help complete the port of the Markitup module to Drupal 7). But the search for a better “non-WYSIWYG” editor (text editor) did lead me to the BUEditor, a nice alternative which can be used with Drupal 7.

The safest solution is to use one editor

It's probably best to adopt just one editor for all text formats. Otherwise if you have privileged users with access to more than one format, that will mean two different libraries of Javascript code are added to the text areas and you can start to run into weird conflicts… like no editor showing up for a text format which is assigned to an editor… or no ability to properly switch between “rich text” and “code” views. It also means a lot more Javascript is added to each page, so it can delay initial page loads. So we strongly suggest choosing one editor which is sufficient for all your needs. To my knowledge, since only TinyMCE and CKEditor are supported by the IMCE-Wysiwyg bridge (which you may want if you'd like to add images to posts), it might be worth trying out both, before selecting one. From this point on, in this article, we are assuming you have settled on TinyMCE (or CKEditor), so some steps will include tips or screenshots which apply only to TinyMCE (but CKEditor is very similar in terms of the configuration).

We'll start by configuring the Filtered HTML button-set

Select TinyMCE as editor for Filtered HTML and saveFirst we need to select an editor to use for “Filtered HTML”. Select “TinyMCE” (or CKEditor, or whatever) from the select list for “Editor” and then click “Save”.

But wait… you still have to select the buttons

If we stopped now, we would only have an empty editor, one with no buttons — which would be much like no editor at all. Don't make the mistake of stopping now and thinking the defaults are probably good enough. Unfortunately, they aren't. Be sure to click on the “Edit” link which is now active for Filtered HTML and TinyMCE in the “Operations” column.

Select appropriate buttons when configuring your editor for a "filtered" text format

Select appropriate buttons when configuring TinyMCE for the Filtered HTML text formatJust select buttons which will be useful and appropriate for the limits of the text format. In this image, you can see what should be an appropriate selection of buttons for a Filtered HTML text format. I would be sure to add the <p>, and to be safe, both <br> and <br /> tags to the allowed list of tags for your Filtered HTML text format. (See related article for more info about configuring text formats). Why? Now you can turn off the “turn line breaks into HTML” filter (which turns double line-breaks into <p> tags and single ones into <br />). You will probably find that any WYSIWYG editor is going to add those tags, anyway. And people will try to add them (in code view) and be annoyed by having them stripped out on output. Plus, you'll probably find that your code gets re-formatted, no matter what settings you use in configuring the editor.

Tweak the settings for “Cleanup and Output” (optional)

Adjust settings for Cleanup and Output of HTML code from TinyMCEI personally can normally accept all the other default settings, but change the Cleanup and Output settings, as shown. Verify HTML should be good, but I don't like the editor to add lots of styling when people paste. Let's try to keep that in the CSS files. I also don't like all the linebreaks removed, since I tend to look at the code, and I'm sure many others are like me and will also want to see or adjust the code. Assuming you don't have the “convert line breaks to HTML” turned on (you shouldn't if using a WYSIWYG editor), it’s safe to leave “Apply source formatting” on. It will give you some appropriate line breaks (hopefully) so that it’s easier to read through the code. The “Force cleanup on standard paste” option helps clear out some of the garbage that people might attempt to paste in. I’ve seen no reason to disable that feature.

Now your editor should look something like this

Your TinyMCE editor should now look something like this.

Provided you are configuring TinyMCE and selected the same buttons I did, your editor should look something like this, at least to your regular users who probably will only have a limited set of HTML tags they are using.

Make sure selected buttons correspond to allowed tags

To make sure that your editor and corresponding text formats are properly configured, you should test the different buttons and pay attention to the preview. Here, we can see that the <strike> tag is not allowed by the current format (Filtered HTML) and should be added to the list of allowed tags for Filtered HTML if we want to have that button available for use*. Nothing is much more confusing and annoying to users than when they add the proper code, can see it in the code view, but don't see the same result in the saved output. Look at what tags are output by the editor (for each button used) and either disable the button or add the corresponding tag to the text format's allowed tags. Use the node preview button (at the bottom of the page, next to the “Save” button) to check [*Note: Actually, in the current TinyMCE, the “strikethrough” text treatment is accomplished by wrapping text in <span> tags with a style attribute which achieves the same effect. In the current version of CKEditor, it's <strike> tags. In other editors, you may find the “same” button adds <del> tags. All three achieve the same effect and if you want to include the strike-through button, you may wish to add more than one of these tags to those allowed for your text format.]

Don't enable the “preview” button

Don't add the preview button to your editor for a filtered HTML text format. It will render tags that are removed by Drupal's filter system. There is a common issue across various editors integrated by Wysiwyg. If the editor provides a “preview” button, and most do, the preview will render any HTML, regardless of tag limitations imposed by the current text format. For example, this means that images and <strike> tags used for strikethrough text will work as expected in a preview, but since the tags are not part of the default “Filtered HTML” text format, the <strike> or <img> tags will actually be removed on output instead of displaying an image or the text between the <strike> tags with “strikethrough” styling. You can still preview by clicking on the “Preview” node button, before saving, but the “preview” provided by the editor can be misleading. Hopefully future development of the Wysiwyg module might implement something like Ajax markup, which integrates with BUEditor (but not with the Wysiwyg module) to display text with correct output, i.e., according to active text format filter settings, etc.

Repeat for other text formats, but keep it simple

It should be easier to set up your editor for Full HTML. You may also wish to create a filtered html text format for trusted users, e.g. a “Filtered+” HTML. Just follow the same steps. Add a few more tags to the allowed set (perhaps you trust these users to add images or sub-headings). My only advice is to follow the KISS principle and “keep it super simple”. It's easy to get carried away and add all buttons available for Full HTML. Resist the urge. You are more likely to run into bugs and you'll end up with an overwhelming user experience. I'd suggest keeping the button-set limited to the most useful tags.

This is what the button-set looks like if you select them all:
TinyMCE and CKEditor are overwhelming if all buttons are selected for Full HTML

My recommendation would be to add just a few more buttons to the set you created for Filtered HTML. If you want users to be able to simply add images within their text and you've turned on the IMCE module, be sure to select both the Image and IMCE checkboxes. Working with images and IMCE is complex enough that we'll cover that in the next post.

Make sure the text filters for the format make sense and are in logical order

Minimal filters for Drupal's FIltered HTML text format

Now you should check your filters. Make sure the appropriate filters are enabled and that text is processed by the filters in a reasonable order. The Filtered HTML Text format normally includes the “convert line breaks to HTML” filter, which doesn't make sense if you are using a WYSIWYG editor (just be sure to include the <p> and <br /> / <br> tags in your allowed set). For Full HTML or other text formats with images, you'll probably want to include other filters, such as the Image Resize Filter and/or Lightbox. Again, we'll cover image-related tips in the next post.

Congratulations, you now have a killer WYSIWYG editor configured!

Be sure to test that everything works the way you want it to. Be sure to test that all of your user roles have the expected access to the editors and text formats and that features are working as expected. If you are working on a local development environment, it can be helpful to turn on the Devel module's “switch users” block and give all user roles permissions to use it. This will allow you to easily switch between a user of one role and your user-1 admin to tweak permissions or other configuration.

Be sure to check back for our next post about working with images in a WYSIWYG editor, which should be posted in the next few days.

Mar 20 2010
Mar 20
Printer-friendly versionPDF version

 I recently received an email asking me how to bring a Drupal site back online after taking it offline for site maintenance. For those of you who haven't done this yet you can take your site offline (and put it back online) by going to /admin/settings/site-maintenance. If you take your site offline for maintenance, then log out of the site you will get the "Site off-line message" indicated in your settings. To get back into your site all you need to do is go to /user/login. There you will be presented with the login form that you can complete in order to gain entry to your site.

It's important to understand that unless you specifically set the permission for "administer site configuration" under the system module then only user #1 can manage the maintenance status of the site. If you do want to grant this access to another user then you will also probably want to grant access to "access administration pages" as well. A screenshot of the appropriate section of the user permissions page (/admin/user/permissions) is included below.

System Module Permissions

I received another question recently that relates to roles and permissions as well. A reader asked how they could eliminate all of the extra fields below the node body when editing a node. An example of these "extra fields" is shown below.

Vertical Tabs

This is what the node submission form looks like with the vertical tabs module installed. Vertical tabs is highly recommended for Drupal 6 sites. In Drupal 7 this is a core module so you'll have it out of the box. What about the fields though? Users should not see those "extra fields" as long as they don't have the "administer nodes" permission.

If you're concerned about what your users who can contribute content to your site are seeing I recommend that you do two things. First, check your permissions in the Node Module section of the User Permissions page to see what the appropriate role can and cannot do. Second, create a user for yourself with a role equal to that of your contributors. This way you can login with the contributor role and see what they see. The Masquerade module looks like something that would assist with switching on the fly so you don't have to log out and log back in. You can also use separate browsers or use something featured in the Google Chrome web browser called an .

At this point I think it's worth noting just how important roles are on your Drupal site. They are definitely worth thinking about. Out of the box there are two user roles which are anonymous and authenticated. Those roles are in addition to the everything (or "god") role that is granted to user #1 on the site. If you're going to have a site where people cannot sign up for accounts (configure that at /admin/user/settings) then you won't have to spend too much time on it. Your user setting options are pictured below.

User Settings

If you are going to allow people to sign up for accounts then think hard about the access they will have. If you're in a situation where there will be other administrators or site editors then it is likely that you will want to set up additional roles (do this at /admin/user/roles) to give those users special permissions. For example, if you have people who are editing content or perhaps moderating comments then you would create a separate role, assign the appropriate permissions to the role then assign the role to that user. Roles can be assigned manually in the account page of a user as shown in the picture below.

If you want roles to be assigned automatically I suggest that you investigate the Auto Assign Role module. I haven't used it yet but I have it on my list of modules to try for another site that I am working on.

If you have any ideas, tips or tricks related to user roles I'd love to hear about them in the comments.

Video Links

YouTube Version

Flash Version

Quicktime Version

About Drupal Sun

Drupal Sun is an Evolving Web project. It allows you to:

  • Do full-text search on all the articles in Drupal Planet (thanks to Apache Solr)
  • Facet based on tags, author, or feed
  • Flip through articles quickly (with j/k or arrow keys) to find what you're interested in
  • View the entire article text inline, or in the context of the site where it was created

See the blog post at Evolving Web

Evolving Web