All these solutions have their limitations, are inflexible and you go into a dependency that will be hard to get out and with each update of WordPress you have to check if the Plugin is still working or has any bugs with the new version. Therefore, I would suggest a solution that we use in our Inpsyde Team frequently for customers and maintained their strength in the flexibility, in extensibility and in its capacity to use the WordPress standard without changing the core or anything else. You can deactivate the Plugin at any time, you won't lose anything, your website remains the same.

Why multilanuage?

• 2/3, if not even more, of the worldwide population speak another language
• Globale Aufstellung von Unternehmen
• Better distribution of content
• Service for the client
• Search Engine Optimization

The solution

WordPress Multi-site provides the solution already.
This makes the management of different instances, with similarities and differences, with the help of an installation possible. The exchange of data is possible via core functions, which get united and simplified via Plugin.

Advantages

• WordPress Core Functions
• No dependency to Plugins
• Independent to WordPress development*
• Control Themes, Plugins at a central place, use them decentralized
• Low maintenance
• Seperating languages in Backend/Frontend (user dependent)
• Complete mirrored or in every content form seperated
• Subdomains or Subdirectories
• de.example.com, example.com/de
• Seperate Domains via Domainmapping
• example.de, example.com
• Free in development in design and usability
• Optimization not only on frontend, also lang-attributes, SEO

Plugin

With all these requirements and benefits, we use a base that is available as a Plugin in the official repository of WordPress: Multilingual Press . The plugin provides several convenient tools to use Multisite for the implementation of multilingualism.

This plugin simplifies the identification of different blogs in the network to a language and linking to other blogs, so that when you publish the content in blog A, it will create a post as draft in blog B. Thus, the articles are in relation, the system knows this and with the help of some functions, it may be used in the frontend and backend.
The Plugin provides in the article or page the ability to see a meta box with the content of the linked data, in the simplest case as a translation aid. Similarly, there is a widget that simplifies the frontend to change. In each blog you can be make ​​some adjustments, assigning a flag and language.

An outlook

We are in the midst of the development, which adds the extra help. For example a dashboard widget with the overview of article and all links, an extension of the mediathek to seperate global content across all blogs and independent content per blog. Similarly, there are helpers for updating existing installations. In addition there is the possibility to directly load the language in the backend, without the need of FTP/SSH and assign the languages accordingly​​. We will also add the function to copy existing blogs with all the content and options if you want to.

Summary

WordPress Multisite provides the basis and with some adjustments, a clean, controlled solution exists for the use of WordPress in a multilingual environment. Now it's up to you - use Multisite, Test the Plugin and give us a feedback, preferable on our repo on Github.

.

This was our last door of our Advent Calendar. We hope you enjoyed it!

We wish you a Merry Christmas and thanks a lot for reading our posts!

Why WordPress doesn't follow MVC pattern consistently?

If we have a close look on WordPress, we can detect an MVC pattern. By separating the Themes (view) from the core (model) it gives the impression WordPress pursues an MVC pattern. But this patternn is found only in the frontend. Let's take a closer look and we see that there is no such logic for the admin area. So, the view for the admin area has to be anchored somewhere in the core. We can also notice that in the core itself are lose SQL queries within PHP. Well, a general separation of view and logic is not equal MVC. An MVC-Pattern is principally composed of a sort of object-oriented programming paradigm, in WordPress, these can also be found occasionally, but we find much more procedural than object-oriented programming paradigms. Conclusion WordPress itself does not pursue a MVC pattern, but it is quite possible MVC principles, as we used in the following.

function get_some_foo() {
	$my_foo = 'This is Foo!';
	return $my_foo;
}

function some_foo() {
	$foo = get_some_foo();
	echo $foo;
}

Why is this useful? We want the function some_foo() returns a predefined output. In another template we want to change the default behavior of the function some_foo(). In order to effectively reflect both requirements, two functions are defined. The first function consists only the elementary logic and is only returned as return values​​, it is always preceded by a get_.... The second function includes predefined information, which in turn can be HTML, test logic, loops, or a hook.

function get_some_foo() {
	$foo_bar_array = array( 'Foo', 'Bar', 'FooBar', 'BarFoo' );
	$foo_bar_array = apply_filters( 'some_foo_array', $foo_bar_array );

	return $foo_bar_array ;
}

function some_foo() {
    $foo_list = '<ul>'; 

    foreach( get_some_foo() as $foo_key => $foo_value ){
		$foo_list .= '<li>' . $foo_value . '</li>';
    }

    $foo_list .= '</ul>';

    echo apply_filters( 'some_foo', $foo_list );
}

In the previous example in each of the two functions with the function apply_filters() the possibility will be created, to change returned values later as you desired. A manipulation can take place via the so-defined hooks some_foo_array or some_foo. Here is an example of how a possible manipulation can look with the two defined hooks.

In the next code example, we change an array $foo_bar_array and the HTML output. This involves the two hooks some_foo_array and some_foo, which were set with apply_filters('some_foo' .... With the function add_filter() filter functions for further processing in the global variable $wp_filter will be registered.

function get_my_some_foo( $foo_bar_array ) {
	$foo_bar_array[ count( $foo_bar_array ) + 1 ] = 'FuuBoo';

	return $foo_bar_array ;
}

function my_some_foo( $foo_list ) {
    $foo_list = str_replace( 'ul', 'ol', $foo_list ); 

    return $foo_list;
}

add_filter( 'some_foo_array', 'get_my_some_foo');
add_filter( 'some_foo', 'my_some_foo');

// do not forget, call some_foo()
some_foo();

Let's look briefly what's happening. What outputs some_foo() has without manipulation we see in the following example.

function get_some_foo() {
	$foo_bar_array = array( 'Foo', 'Bar', 'FooBar', 'BarFoo' );
	$foo_bar_array = apply_filters( 'some_foo_array', $foo_bar_array );

	return $foo_bar_array ;
}

function some_foo() {
    $foo_list = '<ul>'; 

    foreach(get_some_foo() as $foo_key => $foo_value){
		$foo_list .= '<li>' . $foo_value . '</li>';
    }

    $foo_list .= '</ul>';

    echo apply_filters( 'some_foo', $foo_list );
}
?> 

// output
<ul>
	<li>Foo</li>
	<li>Bar</li>
	<li>FooBar</li>
	<li>BarFoo</li>
</ul>

In the next example we use the functions defined in the hooks some_foo_array and some_foo to add the array another element to make the unordered list, an ordered list.

function get_my_some_foo( $foo_bar_array ) {
	$foo_bar_array[ count( $foo_bar_array ) + 1 ] = 'FuuBoo';

	return $foo_bar_array ;
}

function my_some_foo( $foo_list ) {
    $foo_list = str_replace( 'ul', 'ol', $foo_list ); 

    return $foo_list;
}

// register Hooks in the stack ($wp_filter)
add_filter( 'some_foo_array', 'get_my_some_foo');
add_filter( 'some_foo', 'my_some_foo');
?>

//output
<ol>
	<li>Foo</li>
	<li>Bar</li>
	<li>FooBar</li>
	<li>BarFoo</li>
	<li>FuuBoo</li>
</ol>

How does add_filter and apply_filters work in the program flow?
Each hook which should be executed is registered with add_filter or add_action in the global variable $wp_filter. If the function apply_filters() is called, an appropriate filter function based on the transmitted variables will be searched in the $wp_filter, if this is registered with add_filter, the appropriate function will execute. Now values will be manipulated now and then passed back to apply_filters.

Let's take our example from above, it looks like this.

<?php
// the default function
function get_some_foo() {
	$foo_bar_array = array( 'Foo', 'Bar', 'FooBar', 'BarFoo' );
	$foo_bar_array = apply_filters( 'some_foo_array', $foo_bar_array );

	return $foo_bar_array ;
}

// the filter function
function get_my_some_foo( $foo_bar_array ) {
	$foo_bar_array[ count( $foo_bar_array ) + 1 ] = 'FuuBoo';

	return $foo_bar_array ;
}

// register function in $wp_filter
add_filter( 'some_foo_array', 'get_my_some_foo' );
?>

Without hook functionality the whole thing would look like the following. Although we have much less code, but this is not reusable.

<?php
//Das ist unsere default Funktion
function get_some_foo() {
	$foo_bar_array = array( 'Foo', 'Bar', 'FooBar', 'BarFoo' );
	$foo_bar_array[ count( $foo_bar_array ) + 1 ] = 'FuuBoo';

	return $foo_bar_array ;
}
?>

A constant is an identifier (name) for a simple value. As the name suggests, that value cannot change during the execution of the script. A constant is case-sensitive by default. By convention, constant identifiers are always uppercase.
PHP docs

Content

• General
• Status
• Paths, dirs and links
• Database
• Multisite
• Cache and script compressing
• Filesystem and connections
• Themes
• Debug
• Security and cookies

General

• AUTOSAVE_INTERVAL #
  Defines an interval, in which WordPress should do an autosave.
  Value: time in seconds (Default: 60)
• CORE_UPGRADE_SKIP_NEW_BUNDLED #
  Allows you to skip new bundles files like plugins and/or themes on upgrades.
  Values: true|false
• DISABLE_WP_CRON #
  Deactivates the cron function of WordPress.
  Value: true
• EMPTY_TRASH_DAYS #
  Controls the number of days before WordPress permanently deletes posts, pages, attachments, and comments, from the trash bin.
  Value: time in days (Default: 30)
• IMAGE_EDIT_OVERWRITE #
  Allows WordPress to override an image after editing or to save the image as a copy.
  Values: true|false
• MEDIA_TRASH #
  (De)activates the trash bin function for media.
  Values: true|false (Default: false)
• WPLANG #
  Defines the language which WordPress should use.
  Values: For German de_DE
• WP_DEFAULT_THEME #
  Defines a default theme for new sites, also used as fallback for a broken theme.
  Value: template name (Default: twentyeleven)
• WP_CRON_LOCK_TIMEOUT #
  Defines a period of time in which only one cronjob will be fired. Since WordPress 3.3.
  Value: time in seconds (Default: 60)
• WP_MAIL_INTERVAL #
  Defines a period of time in which only one mail request can be done.
  Value: time in seconds (Default: 300)
• WP_POST_REVISIONS #
  (De)activates the revision function for posts. A number greater than 0 defines the number of revisions for one post.
  Values: true|false|number (Default: true)
• WP_MAX_MEMORY_LIMIT #
  Allows you to change the maximum memory limit for some WordPress functions.
  Values: See PHP docs (Default: 256M)
• WP_MEMORY_LIMIT #
  Defines the memory limit for WordPress.
  Values: See PHP docs (Default: 32M, for Multisite 64M)

Status

• APP_REQUEST #
  Will be defined if it's an Atom Publishing Protocol request.
  Value: true
• COMMENTS_TEMPLATE #
  Will be defined if the comments template is loaded.
  Value: true
• DOING_AJAX #
  Will be defined if it's an AJAX request.
  Value: true
• DOING_AUTOSAVE #
  Will be defined if WordPress is doing an autosave for posts.
  Value: true
• DOING_CRON #
  Will be defined if WordPress is doing a cronjob.
  Value: true
• IFRAME_REQUEST #
  Will be defined if it's an inlineframe request.
  Value: true
• IS_PROFILE_PAGE #
  Will be defined if a user change his profile settings.
  Value: true
• SHORTINIT #
  Can be defined to load only the half of WordPress.
  Value: true
• WP_ADMIN #
  Will be defined if it's a request in backend of WordPress.
  Value: true
• WP_BLOG_ADMIN #
  Will be defined if it's a request in /wp-admin/.
  Value: true
• WP_IMPORTING #
  Will be defined if WordPress is importing data.
  Value: true
• WP_INSTALLING #
  Will be defined on an new installation or on an upgrade.
  Value: true
• #WP_INSTALLING_NETWORK #
  Will be defined if it's a request in network admin or on installing a network. Since WordPress 3.3, previous WP_NETWORK_ADMIN_PAGE.
  Value: true
• WP_LOAD_IMPORTERS #
  Will be defined if you visit the importer overview (Tools → Importer).
  Value: true
• WP_NETWORK_ADMIN #
  Will be defined if it's a request in /wp-admin/network/.
  Value: true
• WP_REPAIRING #
  Will be defined if it's a request to /wp-admin/maint/repair.php.
  Value: true
• WP_SETUP_CONFIG #
  Will be defined if WordPress will be installed or configured.
  Value: true
• WP_UNINSTALL_PLUGIN #
  Will be defined if a plugin wil be uninstalled (for uninstall.php).
  Value: true
• WP_USER_ADMIN #
  Will be defined if it's a request in /wp-admin/user/.
  Value: true
• XMLRPC_REQUEST #
  Will be defined if it's a request over the XML-RPC API.
  Value: true

Paths, dirs and links

• ABSPATH #
  Absolute path to the WordPress root dir.
  Default: path to wp-load.php
• WPINC #
  Relative path to the /wp-includes/. You can't change it.
  Default: wp-includes
• WP_LANG_DIR #
  Absolute path to the folder with lanugage files.
  Default: WP_CONTENT_DIR /languages or WP_CONTENT_DIR WPINC /languages
• WP_PLUGIN_DIR #
  Absolute path to the plugins dir.
  Default: WP_CONTENT_DIR /plugins
• WP_PLUGIN_URL #
  URL to the plugins dir.
  Default: WP_CONTENT_URL /plugins
• WP_CONTENT_DIR #
  Absolute path to thewp-content dir.
  Default: ABSPATH wp-content
• WP_CONTENT_URL #
  URL to the wp-content dir.
  Default: {Site URL}/wp-content
• WP_HOME #
  Home URL of your WordPress.
• WP_SITEURL #
  URL to the WordPress root dir.
• WP_TEMP_DIR #
  Absolute path to a dir, where temporary files can be saved.
• WPMU_PLUGIN_DIR #
  Absolute path to the must use plugin dir.
  Default: WP_CONTENT_DIR /mu-plugins
• WPMU_PLUGIN_URL #
  URL to the must use plugin dir.
  Default: WP_CONTENT_URL /mu-plugins

Database

• DB_CHARSET #
  Defines the database charset.
  Values: See MySQL docs (Default: utf8)
• DB_COLLATE #
  Defines the database collation.
  Values: See MySQL docs (Default: utf8_general_ci)
• DB_HOST #
  Defines the database host.
  Values: IP address, domain and/or port (Default: localhost)
• DB_NAME #
  Defines the database name.
  Value: database name
• DB_PASSWORD #
  Defines the database password.
• DB_USER #
  Defines the database user.
• WP_ALLOW_REPAIR #
  Allows you to automatically repair and optimize the database tables via /wp-admin/maint/repair.php.
  Value: true
• CUSTOM_USER_TABLE #
  Allows you to define a custom user table.
  Value: table name
• CUSTOM_USER_META_TABLE #
  Allows you to define a custom user meta table.
  Value: table name

Multisite

• ALLOW_SUBDIRECTORY_INSTALL #
  Allows you to install Multisite in a subdirectory.
  Value: true
• BLOGUPLOADDIR #
  Absolute path to the site specific upload dir.
  Default: WP_CONTENT_DIR /blogs.dir/{Blog ID}/files/
• BLOG_ID_CURRENT_SITE #
  Blog ID of the main site.
  Default: 1
• DOMAIN_CURRENT_SITE #
  Domain of the main site.
  Default: domain
• DIEONDBERROR #
  When defined database errors will be displayed on screen.
  Value: true
• ERRORLOGFILE #
  When defined database erros will be logged into a file.
  Value: absolute path to a writeable file
• MULTISITE #
  Will be defined if Multisite is used.
  Value: true
• NOBLOGREDIRECT #
  Defines an URL of a site on which WordPress should redirect, if registration is closed or a site doesn't exists.
  Values: %siteurl% for mainsite or custom URL
• PATH_CURRENT_SITE #
  Path to the main site.
• UPLOADBLOGSDIR #
  Path to the upload base dir, relative to ABSPATH.
  Default: wp-content/blogs.dir
• SITE_ID_CURRENT_SITE #
  Network ID of the main site.
  Default: 1
• SUBDOMAIN_INSTALL #
  Defines if it's a subdomain install or not.
  Values: true|false
• SUNRISE #
  When defined WordPres will load the /wp-content/sunrise.php file.
  Value: true
• UPLOADS #
  Path to site specific upload dir, relative to ABSPATH.
  Default: UPLOADBLOGSDIR /{blogid}/files/
• WPMU_ACCEL_REDIRECT #
  (De)activates support for X-Sendfile Header.
  Values: true|false (Default: false)
• WPMU_SENDFILE #
  (De)activates support for X-Accel-Redirect Header.
  Values: true|false (Default: false)
• WP_ALLOW_MULTISITE #
  When defined the multisite function will be accessible (Tools → Network Setup).
  Value: true

Cache and script compressing

• WP_CACHE #
  When defined WordPres will load the /wp-content/advanced-cache.php file.
  Values: true|false (Default: false)
• COMPRESS_CSS #
  (De)activates the compressing of stylesheets.
  Values: true|false
• COMPRESS_SCRIPTS #
  (De)activates the compressing of Javascript files.
  Values: true|false
• CONCATENATE_SCRIPTS #
  (De)activates the consolidation of Javascript or CSS files before compressing.
  Values: true|false
• ENFORCE_GZIP #
  (De)activates gzip output.
  Values: true|false

Filesystem and connections

• FS_CHMOD_DIR #
  Defines the read and write permissions for directories.
  Values: Siehe PHP Handbuch (Default: 0755)
• FS_CHMOD_FILE #
  Defines the read and write permissions for files.
  Values: Siehe PHP Handbuch (Default: 0644)
• FS_CONNECT_TIMEOUT #
  Defines a timeout for building a connection.
  Values: time in seconds (Default: 30)
• FS_METHOD #
  Defines the method to connect to the filesystem.
  Values: direct|ssh|ftpext|ftpsockets
• FS_TIMEOUT #
  Defines a timeout after a connection has been lost.
  Values: time in seconds (Default: 30)
• FTP_BASE #
  Path to the WordPress root dir.
  Default: ABSPATH
• FTP_CONTENT_DIR #
  Path to the /wp-content/ dir.
  Default: WP_CONTENT_DIR
• FTP_HOST #
  Defines the FTP host.
  Values: IP Adresse, Domain und/oder Port
• FTP_LANG_DIR #
  Path to the folder with language files.
  Default: WP_LANG_DIR
• FTP_PASS #
  Defines the FTP password.
• FTP_PLUGIN_DIR #
  Path to the plugin dir.
  Default: WP_PLUGIN_DIR
• FTP_PRIKEY #
  Defines a private key for SSH.
• FTP_PUBKEY #
  Defines a public key for SSH.
• FTP_SSH #
  (De)activates SSH.
  Values: true|false
• FTP_SSL #
  (De)activates SSL.
  Values: true|false
• FTP_USER #
  Defines the FTP username.
• WP_PROXY_BYPASS_HOSTS #
  Allows you to define some adresses which shouldn't be passed through a proxy.
  Values: www.example.com, *.example.org
• WP_PROXY_HOST #
  Defines the proxy adresse.
  Values: IP address or domain
• WP_PROXY_PASSWORD #
  Defines the proxy password.
• WP_PROXY_PORT #
  Defines the proxy port.
• WP_PROXY_USERNAME #
  Defines the proxy username.
• WP_HTTP_BLOCK_EXTERNAL #
  Allows you to block external request.
  Values: true|false
• WP_ACCESSIBLE_HOSTS #
  If WP_HTTP_BLOCK_EXTERNAL is defined you can add hosts which shouldn't be blocked.
  Values: www.example.com, *.example.org

Themes

• BACKGROUND_IMAGE #
  Defines a default background image.
• HEADER_IMAGE #
  Defines a default header image.
• HEADER_IMAGE_HEIGHT #
  Defines the height of the header image.
• HEADER_IMAGE_WIDTH #
  Defines the width of the header image.
• HEADER_TEXTCOLOR #
  Defines the font color for the header text.
• NO_HEADER_TEXT #
  (De)activates the support for header text.
  Values: true|false
• STYLESHEETPATH #
  Defines the absolute path to the stylesheet of the current theme.
• TEMPLATEPATH #
  Defines the absolute path to the template files of the current theme.
• WP_USE_THEMES #
  (De)activates the loading of themes.
  Values: true|false

Debug

• SAVEQUERIES #
  (De)activates the saving of database queries in an array ($wpdb->queries).
  Values: true|false
• SCRIPT_DEBUG #
  (De)activates the loading of compressed Javascript and CSS files.
  Values: true|false
• WP_DEBUG #
  (De)activates the debug mode in WordPress.
  Values: true|false (Default: false)
• WP_DEBUG_DISPLAY #
  (De)activates the display of errors on the screen.
  Values: true|false|null (Default: true)
• WP_DEBUG_LOG #
  (De)activates the writing of errors to the /wp-content/debug.log file.
  Values: true|false (Default: false)

Security and cookies

• ADMIN_COOKIE_PATH #
  Path to the /wp-admin/ dir.
  Default: SITECOOKIEPATH wp-admin or for Multisite in subdirectory SITECOOKIEPATH
• ALLOW_UNFILTERED_UPLOADS #
  Allows unfiltered uploads by admins.
  Value: true
• AUTH_COOKIE #
  Cookie name for the authentication.
  Default: wordpress_ COOKIEHASH
• AUTH_KEY #
  Secret key.
  Values: See generator
• AUTH_SALT #
  Secret key.
  Values: See generator
• COOKIEHASH #
  Hash for generating cookie names.
• COOKIEPATH #
  Path to WordPress root dir.
  Default: Home URL without http(s)://
• COOKIE_DOMAIN #
  Domain of the WordPress installation.
  Default: false or for Multisite with subdomains .domain of the main site
• CUSTOM_TAGS #
  Allows you to override the list of secure HTML tags. See /wp-includes/kses.php.
  Values: true|false (Default: false)
• DISALLOW_FILE_EDIT #
  Allows you to disallow theme and plugin edits via WordPress editor.
  Value: true
• DISALLOW_FILE_MODS #
  Allows you to disallow the editing, updating, installing and deleting of plugins, themes and core files via WordPress Backend.
  Value: true
• DISALLOW_UNFILTERED_HTML #
  Allows you to disallow unfiltered HTML for every user, admins too.
  Value: true
• FORCE_SSL_ADMIN #
  Activates SSL for logins and in the backend.
  Values: true|false (Default: false)
• FORCE_SSL_LOGIN #
  Activates SSL for logins.
  Values: true|false (Default: false)
• LOGGED_IN_COOKIE #
  Cookie name for logins.
  Default: wordpress_logged_in_ COOKIEHASH
• LOGGED_IN_KEY #
  Secret key.
  Values: See generator
• LOGGED_IN_SALT #
  Secret key.
  Values: See generator
• NONCE_KEY #
  Secret key.
  Values: See generator
• NONCE_SALT #
  Secret key.
  Values: See generator
• PASS_COOKIE #
  Cookie name for the password.
  Default: wordpresspass_ COOKIEHASH
• PLUGINS_COOKIE_PATH #
  Path to the plugins dir.
  Default: WP_PLUGIN_URL without http(s)://
• SECURE_AUTH_COOKIE #
  Cookie name for the SSL authentication.
  Default: wordpress_sec_ COOKIEHASH
• SECURE_AUTH_KEY #
  Secret key.
  Values: See generator
• SECURE_AUTH_SALT #
  Secret key.
  Values: See generator
• SITECOOKIEPATH #
  Path of you site.
  Default: Site URL without http(s)://
• TEST_COOKIE #
  Cookie name for the test cookie.
  Default: wordpress_test_cookie
• USER_COOKIE #
  Cookie name for users.
  Default: wordpressuser_ COOKIEHASH

The following code belongs in the functions.php of the Theme, or better, in a Plugin. It adds the current favicon before the blog title. And to fit the image into the overall picture of the admin bar, we darkened it and and gave it a round shape.

<?php
/**
 * Plugin Name: Icon for Admin Bar Site Link
 * Plugin URI:  http://wpengineer.com/?p=2366
 * Description: Add Icon to Site Link in the WordPress Admin Bar
 * Version:	1.0.0
 * Author:      Sergej Müller
 * Author URI:  http://ebiene.de
 * License:     GPLv3
 */

// This file is not called from WordPress. We don't like that.
! defined( 'ABSPATH' ) and exit;
// If the function exists this file is called as comments template.
// We don't do anything then.
if ( ! function_exists( 'sm_add_adminbar_site_icon' ) ) {

	// add to admin area, inside head
	add_action( 'admin_head', 'sm_add_adminbar_site_icon' );
	// add to frontend, inside head
	add_action( 'wp_head', 'sm_add_adminbar_site_icon' );

	function sm_add_adminbar_site_icon() {

		if ( ! is_admin_bar_showing() ) {
			return;
		}

		echo '<style>
			#wp-admin-bar-site-name > a.ab-item:before {
				float: left;
				width: 16px;
				height: 16px;
				margin: 5px 5px 0 -1px;
				display: block;
				content: "";
				opacity: 0.4;
				background: #000 url("http://www.google.com/s2/u/0/favicons?domain=' . parse_url( home_url(), PHP_URL_HOST ). '");
				border-radius: 16px;
			}
			#wp-admin-bar-site-name:hover > a.ab-item:before {
				opacity: 1;
			}
		</style>';
	}

}

$template_file = get_post_meta( get_the_ID(), '_wp_page_template', TRUE );

add_filter( 'use_default_gallery_style', '__return_false' );

If you don`t understand the function __return_false() of the WP Core, please read our post for this function.

function hide_admin_bar() {
    return FALSE;
}
add_filter( 'show_admin_bar' , 'hide_admin_bar' );

It's a bit tedious to define an additional function just to return "FALSE". Since version 3.0 WordPress provides various functions to shorten the code:

• __return_true()
• __return_false()
• __return_zero()
• __return_empty_array()

The above code can now be written as

add_filter( 'show_admin_bar', '__return_false' );

In this little tutorial we show how to add in the navigation of the TwentyEleven Theme our RSS Feed, a link with icons to our Twitter page and to our Facebook profile. Without writing a single line of PHP code. You are able to accomplish this with the WordPress Menu.

First we go in the backend to Design-> Menu and activate the CSS Classes. Therefore we click on "Screen Options" on the very top right corner. And unter "Show advanced menu properties" you check the box for "CSS Classes" and close the Screen Options.

After that we use the "Custom Links" to create the menu entries. We add the addresses to our RSS Feed, Facebook and Twitter and add them to the menu. There we assign the 3 menu entries to the CSS Classes. RSS Feed has the class rss, Twitter the class twitter and Facebook facebook. Don't forget to save.

I prepared a sprite, which you can download with a right mouse click->Save Image As… . You have to save this sprite into the folder twentyeleven/images/.

Then we open the file TwentyEleven style.css with a text editor and add at the end of the Menu block #access our additional CSS. We do not have much to add. We let our 3 list items float to the right, push the text out of view and position the graphic. Only for the hover, focus and active states, we must define a little tricky CSS rule in order to circumvent the background gradients of TwentyEleven.

#access .twitter, #access .rss, #access .facebook {
	float: right;
}
#access .twitter a, #access .rss a, #access .facebook a {
	background: transparent url(images/social-sprite.png) 0 0 no-repeat;
	padding: 0;
	text-indent: -9999px;
	width: 70px;
}
#access .rss a { background-position: 0 0; }
#access .facebook a { background-position: 0 -96px; }
#access .twitter a { background-position: 0 -48px; }
#access .rss a:hover, #access .rss a:focus, #access .rss a:active {
	background: transparent url(images/social-sprite.png) 0 -144px no-repeat;
}
#access .twitter a:hover, #access .twitter a:focus, #access .twitter a:active {
	background: transparent url(images/social-sprite.png) 0 -192px no-repeat;
}
#access .facebook a:hover, #access .facebook a:focus, #access .facebook a:active {
	background: transparent url(images/social-sprite.png) 0 -240px no-repeat;
}

This is just an example to experiment. Add your Google+ profile and expand this example with cool CSS tricks!

WordPress provides a simple method to ensure that all stylesheets and scripts are reloaded from the source when they have changed by providing a version parameter:

wp_enqueue_script( $handle, $src, $deps, $ver, $in_footer );
wp_enqueue_style( $handle, $src, $deps, $ver, $media);

You can increase the $ver parameter every time you've changed the files:

wp_enqueue_script( 'my_script', 'my_script.js', '', '0.11' );
wp_enqueue_style( 'my_style', 'my_style.css', '', '0.11' );

The URL of the stylesheet/script will be changed to '.../my_script.js?ver=0.11' so that every caching system detects the changed file and reloads it from its source and the user always gets the recent version.

But to change the version number manually every time in the development stage would be a bit tedious and you're a programmer, right? So let's automate this:

wp_enqueue_script( 'my_script', 'my_script.js', '', time() );
wp_enqueue_style( 'my_style', 'my_style.css', '', time() );

The value of time() changes every second so the version ID of the file changes constantly and it's reloaded from the source and not from some cache.

It's a bit disadvantageous that you have to substitute the time based version parameter by a "real" version number every time you deploy your code since the actual user still should have the benefits of cached scripts and stylesheets. Let's extend the idea:

define ('VERSION', '1.1');

function version_id() {
  if ( WP_DEBUG )
    return time();
  return VERSION;
}

wp_enqueue_script( 'my_script', 'my_script.js', '', version_id() );
wp_enqueue_style( 'my_style', 'my_style.css', '', version_id() );

This way you can make sure that in your development environment everything is reloaded from source all the time but a productive server takes advantage of caches.

In this article I would like to briefly explain how to get content of Custom Post Types in the loop of WordPress. This is not a complete guide, but please feel free to add tips, critics, hints in our comment area.

The screenshot is an example of the use of CPT, hereby were the Plugins Archive und Snippet created, they have different tasks and via CPT tailored to the requirements you need.

In the first case, the syntax is shown how to use the query and passes through the type of the CPT via parameters. In a template of the theme it ensures that only the CPT will be read. All other parameters of the query remain untouched.

query_posts( 'post_type=my_post_type' )

Another solution differs essentially only in style and that several CPTs are passed, wich are in an array.

global $query_string;
parse_str( $query_string, $args );
$args['post_type'] = array( 'my_post_type', 'my_second_post_type' );
query_posts( $args );

To complete the loop of WP and not to limit, the array is added to the parameter of the post_type. So only via the array array_merge the array is added to another array.

global $wp_query;
$args = array_merge( $wp_query->query, array( 'post_type' => 'my_post_type' ) );
query_posts( $args );

Furthermore you can define your own queries, especially if you want to use them in your own variables, either in your Themes or Plugins.

$args = array(
	'post_type' => 'my_post_type',
	'post_status' => 'publish',
	'posts_per_page' => -1
);

$posts = new WP_Query( $args );
if ( $posts -> have_posts() ) {
	while ( $posts -> have_posts() ) {
...
	}
}

wp_reset_query();

At the end a solution that has a particular charm that you control it via Plugin and turn it off easily while testing. Also, to implement the application in a Plugin is simple or as an extension of an existing Themes via Childtheme or Plugin. About the Hook pre_get_posts you can adjust various things of the query, including the CPT.
In the example I have via conditional tags diverse conditions implemented, so that you can see, how it responds to the output in the frontend.

// $this? - example was used in class-structures
// add custom post type to wp loop
add_filter( 'pre_get_posts', array( $this, 'add_to_query') );

// ads to query
function add_to_query( $query ) {

	if ( is_admin() || is_preview() )
		return;

	if ( ! isset( $query -> query_vars['suppress_filters'] ) )
		$query -> query_vars['suppress_filters'] = FALSE;

	// conditional tags for restrictions
	if ( is_home() || is_front_page() && ( FALSE == $query -> query_vars['suppress_filters'] ) ) {
		$query -> set( $this -> my_post_type, array( 'post', $this -> get_textdomain() ) );

	return $query;
}