If you develop Drupal sites for clients, then you've no doubt been requested to change some of the default language found in Drupal core and/or contributed modules. For example, instead of "My account", your client wants it to read "User info". Or instead of "Create content", they request "Add stuff".
Depending on what type of product you sell on your Ubercart powered Drupal site, you may want to make it even easier for your users to increase the quantity of what they're ordering.
Yesterday's DrupalEasy Quicktip covered 3 modules that can extend Ubercart's functionality. Here's 3 more...
As terrific as Ubercart is for turning your Drupal site into an ecommerce powerhouse, there's a lot of additional modules that can extend its functionality. Here's a quick look at just a few of them:
Donations - want to accept donations from you site? Among other functionality, this module allows you to create a "product" where your donors to specify the amount they'd like to contribute.
There's a lot of times when you're building a site and trying to figure out the best way to do something. It doesn't matter if you're a newbie or a rockstar, if you're not familiar with a particular type of funcationality, you're going to need to do some homework to figure out the best solution.
One handy way of figuring out the best solution is by gathering up all the possible modules and comparing them. Unfortunately, this can be quick time-consuming. Luckily, there's an entire Drupal group devoted to exactly this!
One of the most requested features by content administrators is the ability to search by node title on the main content administration page (admin/content/node). Since this isn't a feature of Drupal core, some people have resorted to (gasp!) hacking core or writing custom modules to get it done.
Whenever you need to write a custom module that involves redirection using the drupal_goto() function, things can always get tricky - especially if there are other forces at work. One such force might be the "destination" variable that sometimes gets passed around in the URL querystring when the user is attempting to access content that requires authentication.
When creating a theme, it is often very handy to break up the CSS into multiple files for the purpose of keeping things better organized. Luckily, Drupal has built-in CSS optimization on the admin/settings/performance page, but during development it is sometime quite easy to run up a large number of CSS files being used.
Need an fast way to theme a submit button on your site? Using one hook_form_alter() function and some simple CSS, it's fairly easy to do.
The method below actually keeps the text of the button as text and not part of the image (this allows you to reuse the button image for multiple buttons), but you can just as easily set the #value attribute to '' to get rid of the text.
You'll use hook_form_alter() to simply add a CSS class to the button you want to theme and to modify the text of the button.
A common development practice is to keep a local web server running on your laptop, or a development/staging server. A feature of Drupal designed for multisite installations can actually help you out in this situation.
Different servers often mean different databases, database users, and passwords. Sometimes, you may also need to point to a different files/ directory or tmp/ directory, especially if you are moving between Windows to Linux, or a local machine to a server.
Getting quick and easy control of rounded corners is a bit of a holy grail for theme developers and CSS jockeys. In order to do rounded corners correctly and have them appear consistent across a wide range of browsers often entails several additional HTML elements (usually DIVs) and several hours of CSS head-banging.
An easy way to get around this, providing you're willing to give up rounded corners in IE (a big "if", I know) is to utilize a couple of browser-specific CSS properties. Both Firefox and Safari utilize the "border-radius" CSS properties. For example:
The Context module is a great way to get a site's unwieldy block configuration page under control. It allows you to display individual blocks only when a certain "context" is available.
For example, a context may be set when a particular view is displayed. When that happens, you can use the Context module to display certain blocks alongside the view. If you find yourself writing block visibility code over-and-over again, the context module will save you time and headaches.
When developing a Drupal site, sometimes you have the need to reset a password - either for yourself or another user. Often, when working with a copy of live data, I want to be able to login as another user who is already in the system. Rather than asking them for their password, I use this method to change it.
While Drupal's built-in "reset password" functionality or user editing capabilities work great, if you're like me and tend to work with your database editor open, there's a quick-and-dirty way to quickly change a user's password.
Perhaps the most critical component of a Drupal site's security is the user login. For a login attack to be successful, the attacker must guess both the username and its password -- usually an impossible feat. But if the username can be easily guessed, that reduces the potency of this key security barrier. Far too many Drupal sites have "admin" as a username. Even worse, this is typically not a username assigned to a user who only has permissions for relatively innocuous capabilities, such as commenting on articles.
If you use the most excellent Calendar module, then you probably know that it defaults to a "Month" view. Here's the easy way to change the default view to something different.
In your calendar's main view, click on the "defaults" tab, and then click to edit the "Date: Date (node)" argument. Simply change the "granularity" setting to whatever you want the default view to be and you're golden.
(I found this tip deep in the Drupal.org forums.)