The folks over in Indiana are organizing a Drupal Camp on October 23. Hope you can make it.
I had a situation today where I wanted to drop all the tables in a database, but didn't have access to a UI like phpMyAdmin. The easiest thing to do would have been to drop the entire database then re-create it, but I didn't have permissions to drop an entire database.
After searching around online, this is the best solution I found:
While it doesn't happen that often, occasionally I'll need to export a certain subset of data from a MySQL table instead of the entire dataset. You can do this with mysqldump using the --where option which allows you to apply a WHERE clause that filters the data in your tables based on a certain condition.
Let's say in Drupal, you'd like to copy a single comment from one table into another.
Drupal's core pagination system does not scale well on large, high-traffic sites because of it's need to count the total number of items in the list. This involves wrapping the original query around a COUNT query like below.
SELECT COUNT(*) FROM (SELECT nid FROM node);
Count queries are usually very fast for tables using the MyISAM engine, but most high-traffic Drupal sites use the InnoDB engine for most of the tables.
If you are looking to learn the Drupal API so you can develop your own modules, check out the Examples for Developers project. It includes highly commented example code covering some of the most common features of Drupal. Versions exist for both Drupal 6 and 7.
I work on several high traffic Drupal sites that get millions of page views per month. These sites require special fine tuning to make sure they stay online under heavy load and serve pages to users quickly.
Tuning a Drupal site for performance involves looking at several layers of the web application.
- The Web Server
- The PHP code
- The Database and queries
- HTML Components
Items 1 to 3 are in the category of Back End Performance and involve delivering the main HTML document to the user's browser as quickly as possible.
Lately, several of the Drupal sites I work on with large amounts of traffic have been showing many sluggish queries. One query that kept constantly showing up was this one:
SELECT * FROM variable;
Drupal stores most of it's settings in the variable table, but to improve query performance it stores all the variables from this table into a single record inside the cache table. However, when a variable is changed, added or deleted that cache must be updated.
The reason the above query was getting executed so frequently was because of a variable_set() call inside the Views module that was run on every page load.
I've seen this mistake more than once, so keep in mind that you should only add, change or delete variables during administrative tasks.
Last week at the first Dayton Drupal User Group I presented on Drupal and Security. Here are the slides from the presentation. Many thanks to Greg Knaddison for his book Cracking Drupal which was extremely helpful in putting together this presentation.
Here are some best practices when organizing your theme folder to make things easier to find.
Keep these files in separate folders like so:
theme-name/js/ theme-name/css/ theme-name/images/
or you may want to organize them into an assets folder like this:
theme-name/assets/js/ theme-name/assets/css/ theme-name/assets/images/
Put all your template files into a templates directory, then further separate them by the base template type (ie. page, node, block, view).