Home

Configuration

Opcode Cache for Dummies

tags:
Submitted by Harry Slaughter on November 12, 2006 - 6:40pm

PHP is an interpreted language. This means that each time a PHP generated page is requested, the server must read in the various files needed and "compile" them into something the machine can understand (opcode). A typical Drupal page requires more than a dozen of these bits of code be compiled.

Opcode cache mechanisms preserve this generated code in cache so that it need only be generated a single time to server hundreds or millions of subsequent requests.

Enabling opcode cache will reduce the time it takes to generate a page by up to 90%.

Vroom! PHP is known for its blazing speed. Why would you want to speed up your PHP applications even more? Well, first and foremost is the coolness factor. Next, you'll increase the capacity of your current server(s) many times over, thereby postponing the inevitable need to add new hardware as your site's popularity explodes. Lastly, high bandwidth, low latency visitors to your site who are currently seeing page load times in the 1-2 second range will be shocked to find your vamped up site serving up pages almost instantaneously. After enabling opcode cache on my own server, I saw page loads drop from about 1.5 seconds to as low as 300ms. Now that's good fun the whole family can enjoy.

»

Dreaded blank page of death

tags:
Submitted by Harry Slaughter on July 10, 2006 - 11:53am

A search for "blank page" of the Drupal.org domain yields about 37,000 results.

This is probably one of the more common and frustrating problems for Drupal admins.

»

Creating custom apache logfile names for your multisite instances

tags:
Submitted by Harry Slaughter on May 3, 2006 - 3:30pm

One of the great features of Drupal is its ability to run any number of sites from one base installation, a feature generally referred to as multisites . Creating a new site is just a matter of creating a settings.php file and (optionally) a database to go with your new site. That's it. More importantly, there's no need to set up complicated Apache Virtual hosts, which are a wonderful feature of Apache, but can be very tricky and tedious, especially if you're setting up a large number of subsites.

No worries, there is a solution.

»

Sharing Cookies between Sub-domains

tags:
Submitted by Harry Slaughter on November 18, 2006 - 11:00pm
If you have two sites using the same domain and would like to share cookies between them, set something like this in your settings.php file for each domain:

ini_set('session.cookie_domain', '.EXAMPLE.com');

Be sure you include the leading '.' before the domain name or it won't work.

This allows users to maintain login status between any sites configured for domain-wide cookies.

This can also have negative side effects, so don't do this unless you're familiar with all the cookies involved for the sites you wa
»

"You are not authorized to access this page" checklist

tags:
Submitted by Harry Slaughter on April 30, 2006 - 9:11pm

This is a surprisingly common error for drupal users. Drupal has very powerful access control features, this is good. But it also means it's pretty easy to configure things in such a way that you prevent your users (usually the anonymous ones) from accessing content, this is bad.

I've run across this problem on many occassions, so I've put together a checklist that may help you debug your access problems.

  1. access control - Start here, does your user actually have access granted to him to view the content in question? Browse to your admin/access_control page and confirm that read access is granted for users on modules such as 'node'. If "access content" is not checked for anonymous users in the node access row, anonymous users will not be able to view any nodes! Check all the "access content" type values for all node types. Make sure they are the way you want them.
  2. User 0 - Make sure this user exists in all the appropriate tables. This is probably the most common reason for anonymous users being denied access. See my post, All Important User Zero, for more info.
  3. Make sure the author of the node(s) you are trying to view exists in your users table. There's currently a bug in Drupal in which if the author of a node can't be found in the users table, access will be denied to all for that node. To prevent this from happening, instead of deleting authors who are no longer part of your site, disable their account instead of deleting it.
  4. Make sure you're using the appropriate mysql extension. Check your settings.php file. If you're using "mysqli://" in your $db_url value, try using "mysql://"
I'm sure there was more, but I can't recall it now.

Well, that's it for now. As always, if you have any tips or ideas, please add a comment here.

»
Syndicate content