[nggallery id=1 template=galleryview images=0]

Taken from http://www.ardamis.com/2011/06/02/fix-for-php-fatal-error-get_header-in-wordpress/

While making changes to my WordPress theme, I noticed that the error_log file in my theme folder contained dozens of PHP Fatal error lines:

[01-Jun-2011 14:25:15] PHP Fatal error:  Call to undefined function  get_header() in /home/accountname/public_html/ardamis.com/wp-content/themes/ars/index.php on line 7
[01-Jun-2011 20:58:23] PHP Fatal error:  Call to undefined function  get_header() in /home/accountname/public_html/ardamis.com/wp-content/themes/ars/index.php on line 7

The first seven lines of my theme’s index.php file:

<?php ini_set('display_errors', 0); ?>
<?php
	/*
	* @package WordPress
	* @subpackage Theme
	*/
	get_header();
?>

I realized that the error was being generated each time that my theme’s index.php file was called directly, and that the error was caused by the theme’s inability to locate the WordPress get_header function (which is completely normal). Thankfully, the descriptive error wasn’t being output to the browser, but was only being logged to the error_log file, due to the inclusion of the ini_set(‘display_errors’, 0); line. I had learned this the hard way a few months ago when I found that calling the theme’s index.php file directly would generate an error message, output to the browser, that would reveal my hosting account username as part of the absolute path to the file throwing the error.

I decided the best way to handle this would be to check to see if the file could find the get_header function, and if it could not, simply redirect the visitor to the site’s home page. The code I used to do this:

<?php ini_set('display_errors', 0); ?>
<?php
/**
* @package WordPress
* @subpackage Ars_Theme
*/
if (function_exists('get_header')) {
	get_header();
}else{
    /* Redirect browser */
    header("Location: http://www.ewea.org/SITENAME/");
    /* Make sure that code below does not get executed when we redirect. */
    exit;
}; ?>

The latest version of Typo3 locks the frame of Quixplorer divs so you cannot resize the shape.

By editing this file:

/typo3/templates/template_page_backend.html

And adding:

###TITLE###
###META###
###CSS_INCLUDE###
###CSS_INLINE###
###JS_LIBS###
###JS_INCLUDE###
###JS_INLINE###
###HEADERDATA###
<!--###POSTJSMARKER###-->
<style type="text/css">
textarea {resize: auto;}
</style>
</head>
###BODY###
###JS_LIBS_FOOTER###
###JS_INCLUDE_FOOTER###
###JS_INLINE_FOOTER###
###FOOTERDATA###
</body>
</html>

I was able to unlock the resizing.

Found here.

I had a collection of database dumps from a server that had been created using MySQL’s –all-databases option. This contained the databases for several Drupal websites, but I wanted to restore the Drupal database for just one of the sites. After a bit of Googling I came across two simple solutions:

The first option is to pass the whole SQL dump to MySQL command line, but restrict it’s operation using the “–one-database” option.

mysql -u root -p --one-database oneDB < fulldump.sql

In the above code substitute oneDB with the database name you want to restore, and fulldump.sql with the name of your full DB backup. If you would rather just extract the database dump of the single database from the –all-databases dump file, you can do this with sed using this command:

sed -n '/^-- Current Database: `oneDB`/,/^-- Current Database: `/p' fulldump.sql > oneDB.sql

Where dbname is replaced with the database name of the database to extract, and alldatabases.sql is the name of your dump file. The result will be saved into the file oneDB.sql.