This module collects various fixes to core issues that have not been implemented yet. By default, all of these fixes are disabled, and you can enable them one by one.

   Be sure to test each fix before turning it on on a live site.

Whenever you update Drupal, you must check whether the enabled fixes still apply. At some point, some of the issues may get fixed in core, and the corresponding fix in this module may then start to cause problems, if it's still enabled.

Here's a list of the fixes, taken directly from the module's Settings page:

Administrator issues

  • [ ] (new in D7) Protect the Administrator role setting
    #1356964: Hide the Administrator role selection in admin/config/people/accounts unless the user has the 'administer permissions'
    Hide the control unless the user has the Administer permissions permission.
  • (D6 only) Avoid clobbering the user's access time on the admin/user/user page through administrative action
    Fixed in Drupal 7: #171117: Regression: users without administer users permission can not access user profiles of users that never logged in

    This bug was introduced in Drupal 6.0-beta3 and it was impossible to get fixed in Drupal 6. It was the reason for starting this module.

    • [ ] Don't fake access, preserve 'never'
      If you create a new user, core immediately sets their Last access to the same time as their Member for value. Correct behavior would be to show 'never' until the user has actually accessed the site, so that you can easily tell whether a user has activated their account or not. Also, users should not appear in the Who's new block if they've never accessed your site.

      If you want to fix existing users and find out who has never accessed your site, run the following query:

      UPDATE {users} SET access = 0 WHERE access = created;

      The downside of enabling this fix is the following: the user pages of users with access=0 are inaccessible to other users, and if you have a buggy module or view that displays a list of user records and fails to filter out the access=0 records, then you may get links to 'access denied' (403) pages; this needs to be fixed in that module or view!

    • [ ] Preserve access time when editing an existing user
      When an administrator edits a user, e.g. to block them, core sets their Last access to the current time. Correct behavior would be to leave Last access unchanged.
  • [ ] Avoid MSOffice Server Extensions page not found errors
    If you're tired of seeing page not found errors for MSOffice/cltreq.asp and _vti_bin/owssvr.dll, then turn this on. (More info: http://www.msoffice-cltreq-asp.info/)

End user issues

  • Newbie users (not) changing their password
    #601146: D7UX: Newbie users trying to change their password fail to click on the [Save] button

    This is a severe usability and maintenance issue: experience shows that newbie users who log in via a log-in link often forget to click the [Save] button after changing their password. This causes endless frustration to your users and to you, because they always fail to log in.

    • Reminder:
      ( ) None
      ( ) Static
      ( ) Dynamic (uses JavaScript)
      Add a reminder to the description below the password change widget on the user/%/edit page.
    • [ ] Write a watchdog entry when the user password is updated
      Knowing whether they did change their password or not will help you to get them over that critical hurdle.
  • [ ] Redirect the User|Edit page to User|View on [Save]
    #1524438: Usability: Redirect User|Edit page to User|View on submit
    This is a related usability issue: Users can easily get confused when they submit a password change and the form comes back at them, seemingly begging to enter and confirm the new password again.
    This fix redirects the User|Edit page to User|View on submit, to reinforce the confirmation, unless the user has the Administer users permission.
  • [ ] (D6 only) Collapse the Revision information fieldset for new nodes
    This is a usability issue: if you turn on Create new revision for some content type and you have regular users creating nodes of that type, then these users are often confused by the open Revision information fieldset. This is rarely needed for new nodes.
  • [ ] (D6 only) Redirect logins to the front page
    This is a usability issue: The Drupal default is to redirect to the dull and ugly user page; turn this on to redirect to the (hopefully now enhanced) front page. Logins through the Login block are not affected.
  • [ ] Allow preselecting the contact category
    This is a usability issue: the site-wide contact form does not allow preselecting a category, and thus you cannot create category-specific links. Turn this on and add the index of the desired category to the path, such as contact/1.

Display issues

No I-prefer-it-this-way tweaks, only fixes for obvious bugs that interfere with intended use!

  • [ ] (D6 only) Make multiselect definition lists auto-sized
    Drupal core's system.css gives only a hard-coded 8em width to multiselect definition lists such as the one on admin/user/user. This is not enough for some translations, e.g. German, resulting in a garbled display.
  • [ ] (new in D7) Empty summary token
    #1300920: The [node:summary] token does not output anything for body fields without a manual summary
    Core's Teaser display typically uses the Summary or trimmed format for displaying short versions of node bodies. However, the [node:summary] token delivers only the summary and is empty if the node's summary field is not set, which is rarely useful. This fix implements the patch to return the trimmed body if the summary is empty, using the Trim length of the node type's Teaser display.

    Fixed in Drupal 7.28 after 31 months.
  • [ ] Make the background of unpublished nodes a darker shade of red
    Users with the administer nodes permission have access to unpublished nodes, and Drupal core's node.css displays them with a reddish background. If it looks white to you, then turn this on to make it redder.

Development issues

 

Contributing

If you have a fix you'd like to contribute, then please create a new issue and include

  • a patch to the current -dev version of Fix Core
    (including the fix itself as well as an entry on the Settings page),
  • a link to the core issue where the problem is discussed,
  • an explanation of why the fix should go in here, and
  • an explanation of how the fix works and what its risks are.

FixCore for Drupal 8

D8 Core will be awesome, but just in case it needs a fix, we need help for moving FixCore to D8 and supporting it there.

Supporting organizations: 
sponsors development and maintenance

Project information

Releases