Simple and fast solution for turn the website off; use the Plugin WP Maintenance Mode, original for the activation of the maintenance mode; but its easy for this requirement. As useful; the plugin send an 503 Service Unavailable header.

Set the following settings in the plugin

Code for the field text, the video markup:

<iframe src="http://player.vimeo.com/video/31100268?byline=0&portrait=0" width="400" height="225" frameborder="0" webkitAllowFullScreen mozallowfullscreen allowFullScreen></iframe>
<p><a href="http://vimeo.com/31100268">PROTECT IP / SOPA Breaks The Internet</a> from <a href="http://vimeo.com/fightforthefuture">Fight for the Future</a>.</p>

Here is the result for not signed in visitors:

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!

Much is the same, but not all, and in this small article I would like to briefly explain how you set settings in the database when you activate a Plugin.

The best case for this is a Function of WordPress, which is triggered when activating a plugin register_activation_hook(). This Function will be called in init or constructor of the Plugin. In the called Function are the functions to store the settings of WordPress in the table options - add_option(). In Multisite there is also a function for it - add_site_option().

Now you have to separate, if the Plugin is activated within the Network, in the management of Multisite installation, or if it is only used in one of the blogs in the network or a single installation. There are currently no functions, but a value that is passed. The following example illustrates it:

register_activation_hook( __FILE__, 'fb_add_config' );
function fb_add_config() {

	$data = array(
		'active' => 0,
		'radio'  => 0,
		'link'   => 1,
		'theme'  => 1,
		'role'   => 'administrator',
		'unit'   => 1,
	);
	// if is active in network of multisite
	if ( is_multisite() && isset($_GET['networkwide']) && 1 == $_GET['networkwide'] ) {
		add_site_option( 'my_settings_id', $data );
	} else {
		add_option( 'my_settings_id', $data );
	}
}

The query of the value in the global GET can be integrated in the long time ago mentioned solution for Multisite and settings.

To solve other queries in a Multisite environment and to remove the setup or integrate menus in the admin area, the function is_plugin_active_for_network() is useful.

if ( is_multisite() && is_plugin_active_for_network( plugin_basename( __FILE__ ) ) )
	$values = get_site_option( 'my_settings_id' );
else
	$values = get_option( 'my_settings_id' );

Fortunately WordPress defines two constants which can help you to simplify things nonetheless: WP_PLUGIN_DIR and WP_PLUGIN_URL. These constants point to the plugin directory of the respective WordPress installation. They are defined since WordPress 2.6 and supporting older versions is most likely unnecessary
.
To make your plugins accessible to all your installed WordPress versions you simply move them to a central directory and define the constants accordingly:

define( 'WP_PLUGIN_DIR', '/var/www/plugins' ); // or with XAMPP C:/xampp/htdocs/plugins
define( 'WP_PLUGIN_URL', 'http://localhost/plugins' );

In this example the plugins reside in the directory 'plugins' in the root directory of the webserver. If you now define the above constants in every WordPress installation you have easy access to them to test your code with every version.

(Thanks to John Blackbourn on the wp-hackers list for having the idea.)

Hint for Multisite-Users

Also usable for WordPress Multisite

define( 'WPMU_PLUGIN_DIR', '/var/www/multisite-plugins' );
define( 'WPMU_PLUGIN_URL', 'http://localhost/multisite-plugins' );

The following small Plugin may extend to different roles or authorization objects, so that you can upload, depending on the role, different types of files in the system - current_user_can().

Anyone interested in the currently allowed types, you can return the array of the first function or look into the function get_allowed_mime_types() in wp-includes/functions.php.

<?php
/**
 * Plugin Name: Restrict mime types
 * Plugin URI:  http://wpengineer.com/?p=2369
 * Description: Restrict list of allowed mime types and file extensions.
 * Version:     1.0.0
 * License:     GPLv3
 * Author:      Frank Bültge
 * Author URI:  http://bueltge.de/
 */

 // 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 upload_mimes.
// We don't do anything then.
if ( ! function_exists( 'fb_restrict_mime_types' ) ) {

	add_filter( 'upload_mimes', 'fb_restrict_mime_types' );
	/**
	 * Retrun allowed mime types
	 *
	 * @see     function get_allowed_mime_types in wp-includes/functions.php
	 * @param   array Array of mime types
	 * @return  array Array of mime types keyed by the file extension regex corresponding to those types.
	 */
	function fb_restrict_mime_types( $mime_types ) {

		$mime_types = array(
			'pdf' => 'application/pdf',
			'doc|docx' => 'application/msword',
		);

		return $mime_types;
	}
}

// If the function exists this file is called as post-upload-ui.
// We don't do anything then.
if ( ! function_exists( 'fb_restrict_mime_types_hint' ) ) {
	// add to wp
	add_action( 'post-upload-ui', 'fb_restrict_mime_types_hint' );
	/**
	 * Get an Hint about the allowed mime types
	 *
	 * @return  void
	 */
	function fb_restrict_mime_types_hint() {

		echo '<br />';
		_e( 'Accepted MIME types: PDF, DOC/DOCX' );
	}
}

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>';
	}

}

// example on admin init, control about register_activation_hook()
add_action( 'admin_init', 'fb_activate_plugins' );
// the exmple function
function fb_activate_plugins() {

	if ( ! current_user_can('activate_plugins') )
		wp_die(__('You do not have sufficient permissions to activate plugins for this site.'));
	$plugins = FALSE;
	$plugins = get_option('active_plugins'); // get active plugins

	if ( $plugins ) {
		// plugins to active
		$pugins_to_active = array(
			'hello.php', // Hello Dolly
			'adminimize/adminimize.php', // Adminimize
			'akismet/akismet.php' // Akismet
		);

		foreach ( $pugins_to_active as $plugin ) {
			if ( ! in_array( $plugin, $plugins ) ) {
				array_push( $plugins, $plugin );
				update_option( 'active_plugins', $plugins );
			}
		}

	} // end if $plugins

}

The following function and its hook provides a direct output of the string of the Plugin file on the Plugin page in your backend, so please use it only for a quick finding.

add_filter( 'plugin_row_meta', 'fb_get_plugin_string', 10, 4 );
function fb_get_plugin_string( $plugin_meta, $plugin_file, $plugin_data, $status ) {
	// echo plugin file string
	echo '<code>' . $plugin_file . '</code><br>';
	return $plugin_meta;
}

No problem. There’s an hook for that. It’s a filter called … wait for it … comments_template. We can change the path to the comments template here – if haven’t figured that out already. Let’s build a small plugin.

So, what do we do? We hook into comments_template(); and change the path. Our new path should point to an existing file without any HTML output. In this case, we use just our plugin file, because we know it exists and we control the output.

As you may have noticed our plugin file is included two times: First as a plugin, later as a replacement for comments.php. The function_exists() check prevents any You cannot redeclare … errors.

Putting this all together …

<?php # -*- coding: utf-8 -*-
/**
Plugin Name: Disable Comments On Pages
Version:     1.0
Author:      Thomas Scholz
Author URI:  http://toscho.de
License:     GPL
*/
// 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( 't5_disable_comments_on_pages' ) ) {
	/**
	 * Replaces the path of the original comments template with this
	 * file's path on pages.
	 *
	 * @param  string $file Original comments template file path.
	 * @return string
	 */
	function t5_disable_comments_on_pages( $file ) {
		return is_page() ? __FILE__ : $file;
	}

	add_filter( 'comments_template', 't5_disable_comments_on_pages', 11 );
}

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;
}