There will be times where you want to redirect visitors to a different part of your website when they visit a particular page or post. Reasons for this can be that you renamed a post and its URL, a page was removed or you want a different page to rank.

Redirects in a nutshell

The name ‘redirect’ pretty much says it all: It sends visitors traveling to a specific page to an alternative one. But what does this 301 mean and how does it differ from a 302 redirect? Both send your users to a different page. The only subtle (yet very important) difference is that a 301 will permanently send visitors and search engines to the new destination. 302 redirects indicate that you only temporarily want visitors to be sent to a different page.

Creating a 301 redirect on the server

One of the most basic methods of adding a 301 redirect, is by editing your .htaccess file on the server. This method is only available on Apache servers. Nginx has their own way of defining redirects in the server configuration and requires extensive knowledge of system administration.

These configurations can get quite unmaintainable over time, especially if you’re an avid blogger or you’re trying to improve the SEO of your posts. On top of that, you would have to log in on your server over FTP, edit the files and re-upload them every time you add a new redirect. That’s why, generally speaking, using this method is not considered the way to go.

Creating a 301 redirect with PHP

As a WordPress developer, you have two options: Either you make a redirect by altering the headers of a file in the code -or- you make use of WordPress’ built-in
wp_redirect function.

An example of plain PHP could be as follows:

<?php
// MyExampleFile.php
header("HTTP/1.1 301 Moved Permanently"); 
header("Location: http://www.my-blog.com/a-new-destination"); 
?>

And this is how you’d do the same, but now by using WordPress’ built-in function:

wp_redirect( get_permalink( http://www.my-blog.com/a-new-destination ), 301 );

If you forget to add the 301, both WordPress and PHP will both assume that it’s a 302 redirect, which isn’t always the case.

This method is a bit easier than editing files on the server, but can also become cumbersome once the amount of redirects increases.

Optimize your site for search & social media and keep it optimized with Yoast SEO Premium »

Yoast SEO for WordPress pluginBuy now » Info

Creating a 301 redirect with Yoast SEO

Our Yoast SEO Premium plugin offers you a helping hand when it comes to creating these redirects. Our built-in Redirect manager assists you whenever you change the URL of a post, page or any of the taxonomies that may result in a possible 404 if you don’t properly redirect visitors.

In addition, we also offer you an interface to edit or remove these redirects at a later point in time. The plugin also tells you when you’re about to create a redirect that will result in a redirect loop. This looping is something you want to avoid at all costs.

Read more: ‘How to properly delete pages from your site’ »

This site offers natural healing techniques and coaching based on traditional ayurvedic medicine.

Urban Legend web was contracted to create the front-end and back-end using a WordPress framework.

For the front-end, a child of the ‘cardinal’ theme was used to provide a basis for the PHP, HTML, CSS, and Javascript used for the theme files, layout, style, and user interaction respectively.

For the backend, theme files were edited in PHP to provide user options for content management and editing.

Davis Ogilvie - http://do.co.nz

For this project I was under contract to a Christchurch agency, PublicaDDM.
My role was working within the WordPress framework to set up the frontend theme, as per supplied files. That involved creating and editing CSS, HTML, and Javascript to meet the project requirement. The layout is responsive. My role also involved setting up the backend content management system, using PHP.

Been a while since I wrote something. Let’s talk about some of the new stuff available in the Customizer.

Forget about some of part two

First, back in part two, I had a bit about Surfacing the Customizer. That bit is outdated now, WordPress does this for you in later versions. So, yeah, skip that.

Shiny new thing: Panels

Okay, so Panels aren’t that new. They were added in WordPress 4.0. Basically, they’re sliding containers for sections. Having trouble fitting all your settings on the screen? Group the various sections up into Panels. Panels show up as an item in the main list, and when you click the arrow next to them, the whole list glides off screen to show only those sections.

So, now we have four things: Panels, Sections, Controls, and Settings.

  • Panels group Sections together
  • Sections contain Controls
  • Controls are what the user changes
  • Settings define what the Controls change

Creating a panel is easy:

$wp_customize->add_panel( 'some_panel', array(
	'title' => 'Panel 1',
	'description' => 'This is a description of this panel',
	'priority' => 10,
) );

Adding a section to that panel is just as easy:

$wp_customize->add_section( 'themedemo_panel_settings', array(
	'title' => 'More Stuff',
	'priority' => 10,
	'panel'	=> 'some_panel',
) );

All that’s new is a panel setting to tell the section to go into that panel. Simple.

Active Callbacks

One of the problems with the Customizer was that it displayed settings and showed them changing on the site to your right, but the site being displayed is the actual site. Meaning that you can navigate on it. Sometimes, the controls being shown don’t necessarily apply to the actual site that you’re seeing.

Example: If you have a control to change the color of something in the sidebar, but then are looking at a page which has no sidebar, then you have no visual feedback to tell you what the change looks like.

To fix this, “active callbacks” are used.

The active_callback is simply a new parameter that you can pass into Panels, Sections, or Controls. It can contain the name of a function, and that function will be called when the page changes. The function should return true or false (or equivalent) to indicate whether or not the element of the customizer should be shown for that page.

So, if you have a whole Panel that only make sense when the user is looking at Front Page of the site (and not an individual post), then you can do this:

$wp_customize->add_panel( 'front_page_panel', array(
	'title' => 'Front Page Stuff',
	'description' => 'Stuff that you can change about the Front Page',
	'priority' => 10,
	'active_callback' => 'is_front_page',
) );

And voila, when the user is not looking at the front page, the panel simply disappears.

You can use any of the normal WordPress Template Tags for this, or write your own function if you want to be more specific about it.

If you do need to write your own callback function, note that the function receives the object in question when it’s called. So, if you attach an active_callback to a Panel, your function will get a argument of the WP_Customize_Panel object in question passed to it. Sections get WP_Customize_Section and such. You can use the information in these to decide whether the panel (or whatever) should be shown for that page.

So, how do we use that object? Well, you can use this to make whether certain controls show or not dependent on the values of other settings. All the various items you can use this on have a link back to the main WP_Customize_Manager. That class has a get_setting function, which you can use to determine what to do.

So, let’s make a control that causes other controls to appear, dependent on a setting.

First, let’s make a simple radio selection control:

$wp_customize->add_setting( 'demo_radio_control', array(
	'default'        => 'a',
) );

$wp_customize->add_control( 'demo_radio_control', array(
    'label'      => 'radio_control',
    'section'    => 'themedemo_panel_settings',
    'settings'   => 'demo_radio_control',
    'type'       => 'radio',
    'choices'    => array(
	'a' => 'Choice A',
	'b' => 'Choice B',
	),
) );

Now, we need to make two other controls, one for each choice. You can actually make as many as you like, we’ll keep it simple.

First, the control for choice A. Let’s make it a simple text control.

$wp_customize->add_setting( 'choice_a_text', array(
	'default' => '',
) );

$wp_customize->add_control( 'choice_a_text', array(
    'label'      => 'Choice A: ',
    'section'    => 'themedemo_panel_settings',
    'type'       => 'text',
    'active_callback' => 'choice_a_callback',
) );

We’ll need that callback function to detect if choice A is selected in the radio control, and return true if it is, and false otherwise. Like so:

function choice_a_callback( $control ) {
	if ( $control->manager->get_setting('demo_radio_control')->value() == 'a' ) {
		return true;
	} else {
		return false;
	}
}

You can simplify that if you like, I spelled it out with an if statement so as to be clear as to what is happening.

panel1

Now for choice B, let’s make it display a color control instead:

$wp_customize->add_setting( 'choice_b_color', array(
	'default' => '#123456',
) );

$wp_customize->add_control( new WP_Customize_Color_Control( $wp_customize, 'choice_b_color', array(
	'label'   => 'Choice B',
	'section' => 'themedemo_panel_settings',
	'settings'   => 'choice_b_color',
	'active_callback' => 'choice_b_callback',
) ) );

And its callback:

function choice_b_callback( $control ) {
	if ( $control->manager->get_setting('demo_radio_control')->value() == 'b' ) {
		return true;
	} else {
		return false;
	}
}

panel1-b
Now, note that the callbacks are very similar. Seems like repeated code, doesn’t it? Well, it is, but remember that the $control here is the whole WP_Customize_Control object. We can use the same callback and simply check which control is calling it here instead.

function choice_callback( $control ) {
	$radio_setting = $control->manager->get_setting('demo_radio_control')->value();
	$control_id = $control->id;
	
	if ( $control_id == 'choice_a_text'  && $radio_setting == 'a' ) return true;
	if ( $control_id == 'choice_b_color' && $radio_setting == 'b' ) return true;
	
	return false;
}

So, instead of using two different callbacks, we just point our controls to this callback, which figures out what should show up for which setting. I’m sure you can simplify this further, depending on your particular needs.

One more thing: Customizing the Customizer

Not everybody likes the style of the Customizer. Maybe it clashes with your theme. Maybe you just want to tweak it a bit. Maybe you dislike that gray background color, and a more soothing blue would go better for your theme.

add_action( 'customize_controls_enqueue_scripts', 'themedemo_customizer_style');
function themedemo_customizer_style() {
	wp_add_inline_style( 'customize-controls', '.wp-full-overlay-sidebar { background: #abcdef }');
}

Or maybe you don’t think the Customizer area is wide enough… be careful with this one though, consider mobile users as well.

add_action( 'customize_controls_enqueue_scripts', 'themedemo_customizer_style');
function themedemo_customizer_style() {
	wp_add_inline_style( 'customize-controls', '.wp-full-overlay-sidebar { width: 400px } .wp-full-overlay.expanded { margin-left: 400px } ');
}

You can enqueue whole extra CSS files instead, if you like. Or, if you have special needs for javascript in some of your controls, and there’s libraries necessary to implement them, then you can enqueue those libraries here as well.

 


So in my last post about Internationalization, I covered some non-obvious things that you should consider when adding translation capabilities to your code.

Today, let’s add to that by covering some non-obvious translation functions. You’re probably not using these, since they don’t get talked about as much. But there’s probably places where you should be using them, so knowing about them is the first step. And knowing is half the battle.

Basic functions, again

Last time I talked about these functions:

  • __()
  • _e()
  • _x()
  • _ex()
  • _n()

Let’s cover the ones I didn’t talk about.

Escaping output

In practice, you tend to use these mostly when outputting things onto the main page or in the admin. But, one thing you also use a lot when outputting text is the standard escaping functions. These are things like esc_html(), which outputs text in a way that makes it “safe” to go onto a webpage, without being interpreted as HTML. If the text comes from user input, then this is a good idea.

Now, if you think about it, then the text you have may be translated in some other file, which you don’t control either. So escaping that text might be a good idea too. If somebody snuck bad code into a translation file, a user might get bad things displayed without being able to easily find it.

So you could write something like echo esc_html(__('text','text-domain')), but that’s a bit wordy. Let’s talk about some shortcuts.

The esc_html__() function is the equivalent of esc_html(__(...)). It does the escaped html and the double-underscore translation all in one go. Similarly, the esc_html_e() function does the same thing, but it echoes the result, just like the _e() function would. And there’s also esc_html_x(), which is the equivalent of combining esc_html() and _x().

Along with those three are the three identical equivalents for attributes: esc_attr__(), esc_attr_e(), and esc_attr_x(). As the name implies, these combine the translation functions with esc_attr(), which is the escape function specifically intended when you’re outputting text into html attributes.

Also note there’s no shortcut for the equivalent of _ex(). It’s just not used that much, or at least not enough to need something special for it. Use an echo esc_html_x() instead.

There are no shortcuts for the other escaping functions as yet, but these can save a few keystrokes and make your code that much more readable.

The Numerical No-op

So we’ve got some shortcuts for escaping with those three functions, but where’s the love for _n()?

One of the problems with _n() is that it tends to require the strings to be in the same place that the PHP variable is. For all the other functions, you could have a big file of strings in an array, and then reference those strings by name or something elsewhere because they don’t require any PHP variables. Nothing about them is computed at the time of the output.

But not so with _n(), that $number to decide which string to use means that the strings have to be right there, they can’t be translated separately and referenced.

This is where _n_noop() comes in. The _n_noop() function basically takes the singular and plural strings for something, along with the text domain, and stores them in an array so that they can be referenced later by a function named translate_nooped_plural().

Perhaps an example is in order. Let’s go back to the tacos:

$string = sprintf( _n('You have %d taco.', 'You have %d tacos.', $number, 'plugin-domain'), $number );

What if we wanted those strings somewhere else? Like in a big file with all of our strings. Here’s a way to separate the strings from the _n() call:

$taco_plural = _n_noop('You have %d taco.', 'You have %d tacos.', 'plugin-domain');
$string = sprintf( translate_nooped_plural( $taco_plural, $number) , $number );

Now, that $taco_plural can be defined anywhere. Note that it contains no references to PHP variables. It’s basically static and unchanging. This allows us to separate it, then reference it elsewhere for the actual translation. The translate_nooped_plural() function performs the same job as _n() does, choosing which string to use based on the $number of tacos. The sprintf then pushes the $number into the chosen string, replacing the %d with the number.

Thus, that lets us extract the translatable strings out and put them anywhere we choose.

Also of note: The _nx_noop() function is a cross between _n_noop() and _x(). It takes a context for the translators as the third argument, and the domain becomes the fourth argument. Useful if you need to explain to the translators the context surrounding the pluralization choice.

Numbers and Dates

The number_format_i18n() function is functionally equivalent to the PHP number_format function. It lets you format numbers with commas at the thousands mark and so forth, except that it also takes localization into account. Not everybody uses commas for thousands and periods for decimals. This function will do the translation appropriately for that aspect.

The date_i18n() function is functionally equivalent to the PHP date function. It will handle all the same string formatting parameters as date() will, but it will cause output to be translated for month names, day-of-week names, and so forth. Of note is that it doesn’t change the format requested. If some places put days before months, for example, it won’t handle that. But it will output the month name in the native language (if the translation pack has the right month name in it). So you may want to run the date formatting string through __() as well, to let translators adjust the date format accordingly.

Wrap up

And that’s pretty much all the rest of the translation functions that I didn’t cover before. I may have forgotten a few useful ones here or there. Feel free to comment about anything I missed, or what you see most often, especially if you’re doing translations yourself.

WordPress 3.2 is going to be released very soon, and we want you to be ready! Take note: the minimum requirements are changing.

PHP and MySQL

As of 3.2, you’ll need to be running PHP 5.2.4 and MySQL 5.0. As we mentioned almost a year ago when we announced that this change was coming, the percentage of people running older versions of PHP and MySQL is relatively low. With more than 45 million people using WordPress, though, even a small percentage can mean a lot of people! Don’t caught with your pants dashboard down — make sure you’re running compatible versions of PHP and MySQL before you update tomorrow when WordPress 3.2 is released.

Log in to your hosting account, and check to make sure you have at least  PHP 5.2.4 and MySQL 5.0. Most of the major hosts already default to these or newer versions, but there are some exceptions. Check to see which versions you are running, and if you’re still on an older version, it should be as simple as changing a dropdown menu and clicking Save to get up to date.

If you don’t know how to find this information in your hosting account or you don’t even know how to access your hosting control panel because someone else manages that for you, don’t fret. You can find out if you’re ready for 3.2 with the Health Check plugin. In your dashboard, go to Plugins → Add New and search for “health check” (it should be the first result). Install it, activate it, and it will tell you if you need to update anything.

If you need more help, contact your host’s customer service and use this email template to ask them to help you.

Hi there. I host my domain [example.com] with you, and I run WordPress on my site. The minimum requirements are changing to PHP 5.2.4 and MySQL 5.0, and I would appreciate your help in confirming that my site’s setup meets these requirements. If I’m currently running an older version of PHP or MySQL, could you update it for me, or tell me how to do it? Thanks so much!

If your host replies that they can’t update to these versions, it might be time to look for a new host.

IE6 and Outdated Browsers

With 3.2, we’re also dropping support for Internet Explorer 6, a 10-years-old outdated browser that even Microsoft is ready to leave behind. From now on, if you access your WordPress dashboard from an outdated browser, we’ll let you know. Why? Because as web technology improves, so does WordPress, as we build features to take advantage of these improvements. If you’re using an out-of-date browser, chances are you’re missing out.

If your browser is out of date, you’ll see a friendly orangey-yellow box in your dashboard letting you know you a newer version is available (which you can dismiss, of course). If you’re using IE6, though, the box will be red, and your dashboard will not function properly. If you’re stuck on IE6 because the computer you use is maintained by a business, library, school, or the like, and you are not able to download a newer browser, here’s a sample email you can use to ask your boss/administrator/IT guys to update the browser.

Hi there. The computer I use at [where you use the computer] is equipped with an out-of-date web browser. Internet Explorer 6 was created 10 years ago, before modern web standards, and does not support modern web applications. More and more sites and applications are dropping support for IE6, including the new version of WordPress. Even Microsoft, the makers of IE6, are counting down until IE6 goes the way of the dinosaur (see http://www.ie6countdown.com/ for more information). Can you please install an updated version of IE or any modern browser (see http://browsehappy.com for more information) on the available computers? Thank you very much.

Welcome to the future!

 

 

While looking at my backlinks today, I noticed a site in French had linked to my post about making photo galleries. He mentioned that the Google Translate wasn’t great. I took a look, and while I don’t know how good the text translation was, I did notice that Google strangely tried to translate the code as well, thus screwing it all up.

A quick search revealed that all one had to do was to add the “notranslate” class to any wrapping object to prevent its contents from being translated.

Now, I use the Syntax Highligher Evolved plugin to display code on my site (although I use an older version because I like the look and functionality of it better than the latest version). So I edited the plugin and found where it inserts the PRE tag, and added the notranslate class to it. And voila, now my code doesn’t get translated anymore.

Just a helpful tip for anybody who posts code on their sites.

This site carries financial news, including market data, from the US, and around the world.

Urban Legend web was contracted to update server-side PHP code, and the timing of automatic feeds, to ensure data stability.

We also made some small presentational changes to the table data.