Ok, so getting the content type’s comments into a block is pretty easy once you know how.

This method will require you to use PHP code from within the block you will create to show the comments. So the first thing is to make sure that this is possible by going to site building and then modules and turning on the PHP Filter under the category of Core Optional (if it is not already on that is).

NOTE: Check at admin/settings/filters to be sure that only trusted roles can use the PHP filter, otherwise your web site could be vulnerable to attack. By default, only the administrator can use this filter.

Create a new block and select a region for it. Put the following code on the body textarea:

Do not forget to select the PHP filter from the list of the input filters. After entering the rest of the settings for your block click save.

Now your new block should be ready to assign to whatever region you want. If the page you load has comments related to it. They should now appear via the block.

The arg() funtion may seem a bit cryptic if you’re new to Drupal. Here is a quick explanation from George Notaras in his post: Drupal Tip: List a node’s taxonomy terms inside a Block which I found helpful in compiling this information.

“Now to some technical details about arg(0) and arg(1), which probably seem a bit cryptic to a user that is not experienced with Drupal (like me). Assume we have the following URL to a node: www.example.org/node/23, which means that the path to the page is /node/23. Well, arg(0) is the node part and arg(1) is the second part; 23 that is. Read about the arg() function.”

I hope this was helpful.

To get Drupal 6 to do this, I am creating a custom module. One of the things I have learned about creating a custom module in Drupal 6 is the implementation of the module’s “install” file.

If you create a module named say,  my_module.module then the module’s install file name would be  my_module.install and will reside in the directory named my_module located at….

my_site/sites/all/modules/my_module

Drupal 6 Module Install File Documentation

The  .install file will be run by Drupal 6 the 1st time my_module has been enabled. The my_module.install file will then be used to run setup procedures as stipulated by your module. The most common task for the my_module.install file to perform is creating database tables and fields. There is no special syntax for the install file. It is simply a PHP file with a .install extension to properly identify it to the Drupal 6 platform.

There is special function used in the .install file called hook_schema(). Where hook would be replaced by the name of your module. For example, if  the module you create is named my_module, then you would create a PHP file and name it my_module.install. Inside that file you will create a function named  my_module_schema(). The my_module_schema() function is used to create arrays representingthe database tables you wish the module to create in the Drupal database. You can see how this works here.

Why do it this way?

Once you build the Drupal API Schema there is no more need for  separate CREATE TABLE or ALTER TABLE statements on each database. As a module developer, you only need to create a schema structure and/or use the Drupal Schema API functions, and Drupal takes care of the rest. This greatly simplifies  writing install and update functions.

This way of creating the module install files also allows for support in multiple database platforms.

According to Drupal’s Blog this also allows for “Several advanced capabilities, such as incremental database updates, a simple and consistent CRUD API, form scaffolding, simpler CCK and Views, schema and data validation, become much easier to implement in future enhancements.”

Schema Data Structure Documentation by Drupal

Wild-card sub domains can be a great way to handle multiple sub domains that need to be created dynamically by making a simple edit to Apache via the terminal and some creative PHP programming.

The first step is alter Apache. There are a few ways to do this depending on how your server is set up.
Here are some links I have found on how to do this in various server environments;

• PLesk
• cPanel
• In Apache

NOTE: In the case of the project I am working on, we have a dedicated server by RackSpace. It was necessary to register the wild-card sub-domain ( *.you-domain.com ) with their name servers as well in order for this to work.

Step One: Set Up a Wild Card DNS Record

The first step is to create a wildcard DNS record. Your DNS server is already resolving visitors to domain.tld, but it doesn’t know where to resolve them to find subdomain1.domain.tld.

You’ll need to create what is called an “A record,” which is short for “address record.” As the name implies, “A records” tell what IP address a host is pointing to.

The way to do this will vary based on your DNS server and what control panel (or command line) you are using, most are somewhat similar. When you create a name record of type “A” pointing from *.domain.tld to your web server’s IP address.

If you are using a control panel, then likely you can set this using a web form. Sometimes have to get your web host to do this.

Your web server’s DNS service may need to be restarted. You can expext it to take a few hours or even up to a few days sometimes to propagate throughout the Internet.

Step Two: Set Up a Wild Card DNS Record

Test and make sure it working by typing in a random sub-domain url to your site ( ie. Http://random-name.your-domain.com  ). It should resolve to your site’s home.

Now that any sub-domain will point to your domain, you can use some PHP to determine what URL brought your user to your site. Once you have that knowledge you can manipulate the functionality of  your site accordingly. Pretty cool!

Recognize Which Sub Domain Brought Your Visitor With PHP

One way to “recognize” the subdomain from the URL that brought you visitor is to use the a supper global ( which means they are available in all scopes throughout a script. There is no need to do global $variable; to access them within functions or methods) server variable called $_SERVER['HTTP_HOST'].

This super global variable will return the host name.
ie.   sub-domain.your-domain.com
( if there is no sub- domain then it would just be the domain.com)

If you use PHP’s explode with “.” as the delimiter, you can isolate the sub-domain by separating out the first element of the resulting array of URL parts like this…

$url_sections = explode(”.”,$_SERVER['HTTP_HOST']);
$subdomain =$url_sections[0];

Knowing what sub-domain you’re dealing with gives you the PHP power to make you scripts act accordingly. In my case, I used the extracted information for the “virtual” sub-domain to query the MySQL database.

Wild card sub domains can useful for content management platforms like Drupal. With wild card sub domains and a little cleverness you can handle multiple sub domains within a single installation of Drupal.

A Special Note Regarding  SEO

It is very important that you do not have more than one URL (including the sub domain) point to identical content. Google penalizes for “duplicate content” so be sure not to carelessly point various unknown sub domains at your sites home page. With wild card sub domains, if a user makes a mistake and types in a misspelling then use PHP to redirect their page in some way that corrects them and then points them to the right page.

If you are dealing with this already and have any comments or suggestions or corrections feel free to post a comment.

It is generally not wise to make these changes in the php.ini file itself unless you have a very good reason. The preferred way would be to make the required change at execution time for the particular script you happen to be running only. This gives you better control over site operations and security. To do this you use the “ini_set()”  function.
To demonstrate how to do this, I will show you the code for the four changes I needed to make to my script to accommodate the large image uploads. First, I defined global variables that determine what the setting should be.

Defineing Globals in PHP

I do this so that later if I chose to edit the settings I can do so from my configuration file and not have to hunt through the script to make the changes. Also this allows me to duplicate the setting elsewhere if needed. The setting are as follows:

Also, If you are using a form to upload the file, do not forget to make the MAX_FILE_SIZE directive large enough to accommodate your file size. By the way, do not rely on MAX_FILE_SIZE as any sort of security measure.

Once I made these settings on my local testing server, all worked well. However, after the site was in the “live” pre production mode, the large file sizes would return an error. I knew it was not the file size issue because I had already compensated for that. What tipped me off to the problem was the fact that, every once in a while the file would upload with no error. That is when I realized it was not only a “memory limit” issue but also a timing issue. This did not show up at first because it takes much longer for a file to upload to a remote server than to the local server.

Settings we do not often deal with are easy to forget about and that was the case this time. Once I remembered to reset the “max_execution_time”  to the appropriate amount of seconds, the files uploaded just fine.

As mentioned above, the maximum execution time limit is set in the php.ini file. The line of code in the php.ini file is:

Set the max_execution time in the php.ini file.

With this little line of code in your PHP script, you are now afforded 180 seconds of time to run your program. You can adjust the seconds as you wish by simply changing the number.

I hope this helps!

By having the php.ini file, PHP has made it easier to change how it responds and beh

aves even after it has already been installed. What a pain it would be to have to re-compile every time you realize the need for a configuration change.

The php.ini file really helps make PHP more powerful and more secure as well. This is because you can configure PHP with secure settings until the setting need to change for some reason. Then you can also programmatically alter its behavior to accommodate a particular script file’s needs, on the fly, and returning the settings to normal when you’re done.

When PHP is booting, one of the first things it does is look at the php.ini file. It reads into memory the directives defined with in it. In most cases, when you compile PHP, it puts a copy of the php.ini file in /usr/local/lib/php. This may different depending upon your server.

If you are on a Unix machine, you may be able to type locate php.ini or find / -name php.ini -print and have it tell you the location of the php.ini file. If you have installed it on a Windows machine, use the “Find -> Files or Folders” option from the Start Menu.

What Happens With SQL Injection

By passing an unexpected string of code into a user input, such a form, an attacker send damaging code that causes an otherwise good query to go haywire. For example:

unprotected query is vulnerable

The above snippet of code works as long as users put in the expected information. An attacker, will instead, make clever use of a few extra characters. You likely know by now that SQL requires a semi-colon at the end of each query. PHP automatically adds it in if you omit it. Because of this, the attacker, by closing the string and using the closing parenthesis to finish the query followed by a semi colon, can add an additional query to drop the table.

This is what we in the world of secure web development refer to as a ‘bad thing’!
Scary isn’t it? Attackers have used this method to not only drop tables and destroy records, but also to retrieve highly sensitive information.

How to Protect Against SQL Injection

OK, after that scary bit of information, you’ll be glad to know that protecting yourself is really not all that hard. The hard part is always remembering when and where to do it.

Protecting against SQL Injection is a simple matter of calling a PHP function that renders data safe ( or cleansed ) for use in a query. There are a few methods for cleansing user input in PHP depending on the PHP extension you are using. We will be discussing the mysql extension.The name of the function is:
mysql_real_escape_string(). Notice in this snippet how it is used:

How to protect again SQL Injection

See how easy it is?  Just take the user input (in this case a post ) and pass it through the mysql_real_escape_string() function, (as shown on line 7 ). Then use the “cleansed” variable in the query ( as shown on line 9 ).

It is so easy to protect against this, yet it is often overlooked or forgotten. SO remember to use mysql_real_escape_string() to cleanse your input to help guard against SQL Injection.

There is more to learn and be discussed so feel free to stop back or drop me any suggestions or tips to share.

So, what should be done once you launch your new web site? Well, as proud as you may be of your new creative geniuses, a wise web developer has the humility to recognize that bugs are still likely to surface from time to time. While you do not want any attackers to see error reporting, the information is still valuable to you for squishing bugs. You can (and should) write your error reporting to a file. Actually, PHP does this by default. If you are on a shared server, though, you likely will not have access to this file. You will need to write these errors to your own file.

Don’t Worry, Witting Errors to a File Is Easy
All you need to do is make a few adjustments in you php.ini file. Here are a few php.ini directives that are relevant:

•    display_errors This directive controls whether PHP errors should be sent to the screen. For the production environment this should be turned off.
•    error_reporting This directive controls which errors that should be reported. You should set this to E_ALL and you should fix all issues that appear by doing this.
•    log_errors This directive controls whether errors should be logged to a file. I would recommend that you always turn this on.
•    error_log This is the path of the file errors should be written to. This is only applies if log_errors is turned on obviously.

Your directory structure effects how error_log is set, since it involves creating a path to the error log.

The important thing to remember is that you want to be cautious about what information your error reporting is throwing out to the client. Whenever, possible keep it private. While it should be safely tucked away, it does provide valuable information to you as a web developer. So, keep it handy.

There are many other things to consider in safely setting up a PHP environment with security in mind. We will discuss these in future posts.

Setting the PHP Execution Time Limit

What tipped me off to the problem was the fact that, every once in a while the file would upload with no error. That is when I realized it was not only a “memory limit” issue but also a timing issue.
Settings we do not often deal with are easy to forget about and that was the case this time. Once I remembered to reset the max_execution_time to the appropriate amount of seconds, the files uploaded just fine.

As mentioned above, the maximum execution time limit is set in the php.ini file. The line of code in the php.ini file is:

max_execution_time = 30 ; Maximum execution time of each script, in seconds

It is generally not wise to make this change in the php.ini file itself unless you have a very good reason. The preferred way would be to make the required change in execution time for the particular script you happen to be running only. This gives you better control over site operations and security.

Simply place an ini file setting within the file that executes the script which is causing a delay ( in my case the file upload ). The line code looks like this:

set_time_limit ( 60 ) ;

With this little line of code in you PHP script, you are now afforded 60 seconds of time to run your program. You can adjust the seconds as you wish by simply changing the number. I hope this helps!