Drupal 7 body content going blank? An obscure PCRE configuration setting may be the culprit.

Recently, one of our clients noticed that when they added additional text to the body field of a node with a bunch of existing content the changes would appear to save on the back-end edit screen but the body content of the page disappears on the front end without a trace and with no errors. At first, we thought it was a character or word count restriction that was placed on the body field or that a text-format filter/html combination was throwing things off. After checking a bunch of settings on the admin screen and testing different combinations of words, characters and text-format filters we came up empty handed.

Turns out it was an obscure setting within sites/default/settings.php. If you open this file and search for ‘pcre.backtrack_limit’ you’ll find a surprisingly accurate description of the problem at hand:

* If you encounter a situation where users post a large amount of text, and
* the result is stripped out upon viewing but can still be edited, Drupal’s
* output filter may not have sufficient memory to process it. If you
* experience this issue, you may wish to uncomment the following two lines
* and increase the limits of these variables. For more information, see
* http://php.net/manual/en/pcre.configuration.php.

# ini_set(‘pcre.backtrack_limit’, 200000);
# ini_set(‘pcre.recursion_limit’, 200000);

So once you comment these out and increase the limits you’ll find that the body content reappears on the front end.
Since everyone’s server setup is different, you’ll have to experiment with what values work best for you. Here’s a link to the php.net manual for this configuration setting: http://php.net/manual/en/pcre.configuration.php.

Hope this saves you some time and frustration!

Drupal 7 Views: Directly Edit Content Rendered In Views


Thought I’d share a trick that I learned from Metal Toad while working on a Drupal 7 development project. This trick may make you very popular with your clients if they hate the being forced to dig through the content table in the standard admin overlay until they find the specific piece of content in a view they want to edit. Instead, using this method will create a gear button when you hover over the content on the front end, with a link that says “Edit” when you click on it.

I should note that if you style each row in the view using ‘Content’ under the Format > Show menu then views will add the link for you automatically. If you have a very simple view and this is all you need, no need to read further.

Unfortunately for me, many of the views I tend to create are formatted using ‘Fields’ because it provides me more flexibility to customize the output. The drawback is that it doesn’t automatically add these useful contextual edit links for content. But don’t worry, a pretty simple solutions follows..

1.)  Open up your view and navigate to the ‘Fields’ section.  Click ‘Add’ and search for ‘Content: Edit link’, check the box next to it and apply it to the display.


2.)  Navigate back to the ‘Add’ button next to ‘Fields’ section of your view and click on the small arrow to right of of it. Next select ‘Rearrange’ and move your ‘Content: Edit Link’ field to the top of the Fields list. Apply the change.

3.)  Now go back and click on the ‘Content: Edit Link’ to bring up the field configuration screen.  Expand the ‘Style Settings’ section and make the following changes.  Be sure to change the HTML element to DIV and spell the class names exactly as below.


4.)  Scroll down further in the same screen until you see the ‘Rewrite Results’ section and expand it. Check the “Rewrite the output of this field” box and put the following HTML into the text box:



5. )  Scroll up to the ‘No Results Behavior’ section and make sure that “Hide if empty” and “Hide rewriting if empty” check boxes are checked.  Apply your changes.

6.)  Lastly, you need to add some styling to the edit links wrapper. For my example I used the following which put the edit links in the top left of the content box.  If you want it to appear at the top right just leave out the ‘top:0px’ line.

.views-field-edit-node .contextual-links-wrapper {

    height: 50px;

    width: 50px;

    top: 0px;

    left: 0px;


If you want the wheel to be a different color than standard grey, you can use image editing software to alter the color of the image of the wheel at the following location:  “[your projects base url]/modules/contextual/images/gear-select.png “.

Hope this trick helps you as much as it has helped me! Feel free to reach out with any questions.



Drupal 7: Fancy exposed view filters

A couple of days ago, we were looking to theme a set of Drupal 7 View filters that were also using AJAX to load the new View content. By default, the filters were rendering as a set of radio buttons so by default we were getting HTML that looked like this:

The problem was that given the design mockups we had, styling the filters to match with only CSS was going to be impossible. Writing a jQuery plugin to dynamically replace the filters with custom HTML was pretty straightforward but the tricky part was getting a notification that an AJAX request had completed so that we could reload the filters.

We managed to do this using the Drupal.behaviors Javascript object using code that looks similar to what is below:

Anyway, nothing to crazy but there doesn’t seem to be a ton of documentation about the Drupal.behaviors object.

Fixing blank CCK Location fields in Views

Recently, we inherited a Drupal 6 site via a client of ours and ran into a pretty irritating bug with the Location module.

The site had been configured to allow users to create profiles using Node Profile along with the Location to allow users to input their street addresses.

Anyway, the issue was that when we created a View that included Location fields the fields were always rendering as blank even when we confirmed there was data in the database. A bit of poking around lead to this issue.

It turns out that due to an optimization in CCK or Views that the tables that have the data for the location fields are not getting JOIN’ed in when the view is executed. Unfortunately, the patch provided on the issue doesn’t work on the latest 3.x release of the Location module.

The fix that worked for us is #14 (copied below)

* Preprocess hook for location().
function yourtheme_preprocess_location(&$variables) {
  if (!isset($variables['location']['name']) && isset($variables['location']['lid'])) {
    $variables['location'] = array_merge($variables['location'], location_load_location($variables['location']['lid']));

Basically, you’ll need to add the above snippet to a template.php file in your theme and change the name to reflect the theme you’re using. What this function does is basically pre-process the location fields to pull in the data so that the View will work properly.

Anyway, enough blogging it’s football time.