Last updated March 30, 2011. Created by esmerel on September 8, 2009.
Edited by sime, iamjon, merlinofchaos, Letharion. Log in to edit this page.

Overview

This document provides guidelines for submitting a Views issue. Please read the document and use the checklist as a reminder of the key points.

Submission checklist

  • Is this really a Views issue? (It could be a Drupal, CCK or other module's issue.)
  • Are you using the latest version of Views? Is the problem fixed in the development version?
  • Is it a duplicate? Have you searched?
  • Do not hijack other issues (if you have to change the title you should probably open a new issue)
  • Issues should be specific. Broad topics are better in the forums.
  • Do not post issues that can be fixed with CSS.
  • Describe, in detail, the steps to reproduce the issue.
  • Try to reproduce your problem using a Drupal core theme and turning off as many modules as possible.
  • Screenshots are always helpful.

Getting help

The Views issue queue is used to track bug reports, support requests, general tasks, and feature requests. In order for the queue to be the most effective for everyone, we've assembled these guidelines. Please follow them before you open a new or add to an existing issue:

  1. Make sure that your issue is a Views issue! Views provides the ability to list data - if your data is provided by a module other than Drupal Core, please enter your issue in that module's issue queue instead. If your problem deals exclusively with fields or filters provided by another module (CCK, Image, VotingAPI are common) please post the issue under the queue for that module first; all modules are responsible for telling Views about their own fields. Issues based on other module's data sent to the Views queue will be punted over to that module's issue queue. Module maintainers are the best people to make the determination that the module is providing the right information to Views and they can kick the issue into the Views queue with an explanation of what's wrong if that is the case.
  2. If there is a more recent version of Views that is supported, please try that version if at all possible. Consider trying the -dev version if you have a viable test site; fixes get committed to dev, sometimes weeks before a full release is available.
  3. Search for duplicate issues. Roughly 10% of the Views queue is duplicated - searching the queue with multiple keywords may help you find your answer faster.
  4. Do not hijack issues. It's confusing to everyone involved in the original issue, to other people who might have the same issue as you, and it's rude.
  5. Support requests should be very specific, narrow scope items. Broad or vague support requests or general pleas for help are best left to the forums, where you will get more eyes.
  6. Support requests shouldn't contain stuff like: Field A should look like this and be floated right. This kind of support requests can be mostly solved with CSS. The views issue queue is then not the place to ask.
  7. Take the time to detail steps to reproduce the issue. If you are the least uncertain as to what the problem is, then you can be sure the maintainers of Views will be very uncertain. Even if you don't understand all the technical details, you need to communicate clearly what the problem you are having is. If you cannot take the time to do this, then the maintainers' time is being wasted trying to figure out all the possibilities of what could be happening.
  8. Try to reproduce your issue with the most minimal installation possible. It's nearly always a good idea to export your view, so that the problem can be reproduced. Many views can't be imported if they are dependant on CCK fields on your system.
  9. Sometimes images are really worth a thousand words - attach screenshots whenever they can be helpful.

When opening a new issue, failure to completely fill out all fields may result in the immediate closure of your issue due to lack of information.

Reasons your issue may be closed:

  1. Your issue has been left marked "Postponed, maintainer needs more info" for more than 30 days, in "Needs work" for more than 3 months, or has had no activity for 6 months.
  2. You have failed to provide enough information to begin to even guess what the problem may be. Issues that can be summarized as "it's broken. Fix it." will be closed with a pointer to this page.
  3. You are combatative or argumentative in the queue.
  4. You have excessively bumped an issue too quickly or too often.

Providing information

Please read the following information for help in providing the most data in order to solve your issue quickly.

  • Version: The exact version of Views being used.
  • Component: Which piece of Views is the center of the issue.
    • Code: Problems with actual Views code.
    • Documentation: Problems with documentation (see also Advanced Help)
    • Miscellaneous: Issues which do not fit into any other component category
    • User interface: Problems with the Administrative interface.
    • Views data: Problems with data being displayed by the Views module.
    • Node data: Issues with data specifically supplied by the core node fields.
    • User data: Issues with data specifically provided by the core user fields.
    • Profile data: Issues with data specifically provided by the core profile.
    • Comment data: Issues with data specifically provided by core's comments.
    • Taxonomy data: For issues with using core taxonomy data.
    • Statistics data: For core statistics issues.
    • Files/upload data: For problems with integrating file or upload information.
    • Search data: For issues with core search. Note: this is core search with Views2. Apache/Solr search is not available until Views 3. Please mark your issues accordingly.
    • Book data: Issues with data from book module.
    • Aggregator data: Problems with data from Aggregator
    • Poll data: Problems with poll integration.
    • Page displays: Issues dealing with the creation and use of Page displays within Views.
    • Block displays: Issues dealing with the creation and use of Block displays within Views.
    • Feed displays: Problems dealing with the creation and use of RSS/feed displays.
    • Table Style: Issues dealing with the Table style plugin.
    • Exposed filters: Problems with exposing filters in your views.
  • Category: bug report, task, support request, feature request.
  • Priority: Critical, major, normal, minor. There is no such thing as a critical support request. If you are under a time constraint, Drupal Jobs< or the irc channel #drupal-consultants are better options. Critical issues are bugs where the application crashes or is otherwise completely unusable. For all other issues where a feature does not work properly, please use "Normal".
  • Status: Where the issue stands. If an issue is closed or marked "Won't fix", seriously consider if you really want to re-open the issue. If you are experiencing the same problem in a different release of Views, open a new issue for that version, and link to the previous issue. The statuses "Needs review" and "Needs work" should be reserved for issues with patches attached. For further details on issue status, please see Status settings for an issue
  • Title: Please provide a descriptive title. "error message during creation" is not specific. "Undefined variable error during creation of default display" is significantly more specific.
  • Description: This is critical. Be as specific as possible.
    • If your issue report is about a view that provides unexpected results, or about a SQL error, PLEASE export the entire view and paste it between
      <?php

      ?>
      tags. Please also paste the query from the live preview; you can put the query between <code> tags to preserve formatting.
    • If you are getting a crash bug, please explain precisely what you were trying to do/accomplish with the View at the time.
    • If you are getting a white screen while installing Views, please be sure you have at least 32MB memory available for PHP (google search can easily tell you how); and this can go up if you have a lot of modules. There is extra memory processing on the modules screen due to menu rebuilds and Views will build its first data cache on that page as well, so lots of things will come together to use memory.
  • If there's a crash of some kind and you don't get any kind of error message, be sure to check your apache/php error log. (The location varies from server to server but every server should have one).

  • Sometimes, javascript will crash early on the page. Check your javascript console. In Firefox, you can hit ctrl-shift-j or use firebug.
  • Questions you should be able to answer:
    1. How often does this happen?
    2. What is the exact, complete error message? Copy and paste it into the issue.
    3. List every step you took to create the problem. Each click, each menu item. Reproducibility is the key to solving issues.
    4. Other modules that may be interacting.
    5. Completely describe exactly what you are attempting to accomplish. If your issue is only one or two sentences long, you have almost certainly not described the problem in enough detail.

Common issues

If you have a "An error occurred at /admin/build/views/" error please first the following steps.

  • Enable php errors and log them. There might be some, you have to report them!
  • Disable jquery_ui / jquery_update if you have enabled them to find out whether they cause the problem
  • Disable secure_pages module to find out whether this is the cause of the problem
White screen during Views install

Please be sure you have at least 32MB memory available for PHP; and this can go up if you have a lot of modules. There is extra memory processing on the modules screen due to menu rebuilds and Views will build its first data cache on that page as well, so lots of things will come together to use memory.

"An error occurred at /admin/build/views/"

If you see this, please first take the following steps.

How you can help:

Provide details. Pay it forward (if you've asked a few questions and gotten help, take one of the hours you saved and help close out a few other issues. Every bit counts.) Write a tutorial and submit it as a patch/issue to be integrated into Advanced Help.

Write tests. If you upload a patch or if you create a bug issue write a simpletest. With a simpletest it is possible to be sure every time that nothing of the tested features are broken

Join the bug squad
The bug squad helps managing the issue queue. Please read more about them if you're interested.

Looking for support? Visit the Drupal.org forums, or join #drupal-support in IRC.