In order to solve the above problem, here’s a little trick:

<?php

// post param
$param = array('data' => 'abc');

$c = curl_init();
curl_setopt($c, CURLOPT_URL, "form.php");
curl_setopt($c, CURLOPT_POST, true);
curl_setopt($c, CURLOPT_POSTFIELDS, $param);
curl_setopt($c, CURLOPT_HEADER, 1);
curl_setopt($c, CURLOPT_FOLLOWLOCATION, true);
curl_exec($c);

// here's the trick
$redirectLocation = curl_getinfo($c, CURLINFO_EFFECTIVE_URL);
header("Location: $redirectLocation");

?>

<?php

$hostname = 'localhost';
$username = 'username';
$password = 'password';

try {
$dbh = new PDO("mysql:host=$hostname;dbname=mysql", $username, $password);

// Setting the notification to throw exception when error encountered
$dbh->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);

$dbh->beginTransaction();
$count = $dbh->exec("INSERT INTO user(userID, name) VALUES ('1', 'Steve')");
$dbh->commit();

$dbh = null;
}
catch(PDOException $e)
{
$dbh->rollback();
echo $e->getMessage();
}

?>

The above might work, but i would suggest you to try the following method before going thru the turn-off plugin cycle. For example, if you have modified “functions.php”, and the above header information header appeared right after, you can easily resolve this by removing all the extra whitespace before the “<?php” and “?>” tag. Viewing thru editor, you might not notice any whitespace, but try this trick:

1. Remove the “>” from the “?>” tag at the end of file
2. Then keep holding Delete key (not backspace) for a few seconds. (*note that the cursor should be locate after the “?”)
3. You will notice some whitespace being deleted. Amazing isn’t it?
4. Add the “>” after the “?” to properly close the php tag
5. Save the file, and try accessing it, the header information error should have been resolved

// HTML Snippet
<div id="test-area">
  <ul>
    <li>row 1</li>
    <li class="even-row">row 2</li>
    <li>row 3</li>
    <li class="even-row">row 4</li>
    <li>row 5</li>
    <li class="even-row">row 6</li>
    <li>row 7</li>
    <li class="even-row">row 8</li>
    <li>row 9</li>
    <li class="even-row">row 10</li>
  </ul>
</div>

// CSS Snippet
ul {
  list-style: none;
}

// color the even rows
.even-row {
  background-color: #ccc;
}

The above method is okay when you are working with simple rule, but how about if i only want 1, 7, 13, 19…(6n+1)th rows to be highlighted. Then you probably need to write some javascript and do calculation to do it. However, with HTML 5, we got a better yet easier way to accomplish this. We will be using the new property “nth-child”. Let me illustrate by rewriting the example above:

// HTML Snippet
<div id="test-area">
  <ul>
    <li>row 1</li>
    <li>row 2</li>
    <li>row 3</li>
    <li>row 4</li>
    <li>row 5</li>
    <li>row 6</li>
    <li>row 7</li>
    <li>row 8</li>
    <li>row 9</li>
    <li>row 10</li>
  </ul>
</div>

// CSS Snippet
ul {
  list-style: none;
}

// Note that n is a special symbol here
li:nth-child(2n) {
  background-color: #ccc;
}

See the power of nth-child? We now no longer need to label alternate rows, instead, we use the nth-child property. We simply tell nth-child with the calculation (e.g. any integers like “1″, “3″, “5″ or using the special “n” variable for help, like: “2n” representing alternative rows, “5n” representing every fifth rows or even the word “odd” and “even”… you might try to edit the code above to use “even” instead of “2n” to accomplish the same effect.), and it will apply the CSS for you. To learn more, you might try the demo page i made.

Afterall, is having Chinese URL available, good or bad?

On the POSITIVE side: First, it creates lots more space/possibility for meaningful URL, as current latin url has been exhaustively registered by bulk registration. Meaningful and Short URL is hard to create. Second, chinese url is more familiar to chinese people and they can easily remembered the address. Third, It’s another $$ opportunity. Lastly, some proper rule could be implemented on top of the new registration procedure to reduce the chance of abusing url registration.

On the NEGATIVE side: First, chinese url doesn’t sound meaningful to any foreigner, and in particular, it requires users to know chinese typing in order to access the website, which limits business (of course, it could be solved by purchasing TWO sets of URL, Chinese and English). Second, on the technical aspect, it creates trouble for writing regular expression, since some programming language like PHP, doesn’t have a easy way to match unicode characters, and another set of regular expression specifically addressing unicode would need to be added to current working web app to extend its functionality to accommodate chinese url (e.g. to validate website address / email address). Third, headers (e.g. HTTP, SOAP or so…) will need to be able to handle unicode or at least Chinese Character, which is another big changes.

It could be seen that Chinese URL has its own use, but is it necessary?